Voiko RSA-varmenteella käyttää dh none -asetusta OpenVPN:ssä?

Tässä on palvelinkokoonpano, jossa sanotaan dh none RSA-varmenteen vieressä, sekä sitkeä epäilys, että toisen niistä täytyy olla väärin. Mikään ei ole väärin. Varmenne allekirjoittaa ja todentaa; avaintenvaihto muodostaa jaetun salaisuuden. Ne ovat kaksi eri tehtävää samassa kättelyssä, ja TLS sallii RSA-varmenteen todentaa kättelyn, joka käyttää efemeristä elliptisen käyrän sopimusta.

Sekaannus saapuu yleensä migraatio-oppaan mukana. Se käskee korvata DH-parametritiedoston dh none-asetuksella, lukija huomaa, ettei varmenne ole elliptisen käyrän varmenne, ja nämä kaksi tosiasiaa tulkitaan ristiriidaksi.

Miksi kaksi asetusta näyttävät liittyvän toisiinsa

OpenVPN:n vanhempi kokoonpano vaati DH-parametritiedoston, koska äärellisen kunnan Diffie-Hellman tarvitsee verkkotunnuksen parametrit, joista molemmat osapuolet sopivat. dh-direktiivi osoitti siihen tiedostoon. Kun käyttöönotto siirtyy ECDH:hen, parametrit tulevatkin nimellystä käyrästä, eikä tiedostoa enää tarvita, mitä dh none ilmaisee.

Varmenteet ovat erillinen akseli. Ne kantavat julkisen avaimen ja allekirjoituksen, jotka todistavat palvelimen identiteetin, ja tämä avain voi olla RSA tai elliptinen käyrä riippumatta siitä, miten istuntoavain sovitaan. Kättely, joka käyttää ECDHE:tä avainsopimukseen ja RSA:ta todennukseen, on tavallinen ja laajalti käytössä.

Nimeäminen pahentaa päällekkäisyyttä. Elliptinen käyrä esiintyy sekä ECDHE- että ECDSA-sarjojen nimissä, joten on helppo olettaa, että minkä tahansa käyrän mainitsevan yhteyden täytyy sisältää käyrän varmenne. Näin ei ole.

TLS 1.2 -sarjan nimen lukeminen oikein

Otetaan ECDHE-RSA-AES256-GCM-SHA384. Ensimmäinen tunniste on avaintenvaihtoperhe: efemerinen elliptisen käyrän Diffie-Hellman. Toinen on todennusperhe: RSA. Loput kuvaavat tietueiden suojausta ja kättelyssä käytettyä hashia.

ECDHE-ECDSA-sarja käyttää samaa avaintenvaihtoperhettä eri todennusmenetelmällä, joten se tarvitsee elliptisen käyrän varmenteen. DHE-RSA-sarja käyttää äärellisen kunnan efemeristä Diffie-Hellmania RSA-todennuksella, ja se todella tarvitsee DH-parametrit.

Lue sarjan nimi vasemmalta oikealle ja osoita jokainen osa sen tehtävään. Kun tunnisteet on erotettu, kysymys muuttuu: «vastaako varmenteeni dh none -asetusta» muuttuu muotoon «sallivatko palvelimeni sarjan, jonka avaintenvaihto ei tarvitse DH-tiedostoa».

Mitä dh none itse asiassa poistaa käytöstä

dh none kertoo palvelimelle, ettei se lataa äärellisen kunnan DH-parametritiedostoa. Se ei poista käytöstä todennusta, varmenteiden validointia eikä TLS:ää itseään. Se kuitenkin vaatii, ettei neuvoteltu avaintenvaihto tarvitse näitä parametreja, mikä käytännössä tarkoittaa ECDHE-sarjaa tai TLS 1.3 -kättelyä.

Juuri tästä vaatimuksesta rikkoutuminen syntyy. Jos palvelimen TLS-salauspolitiikka on rajattu DHE-sarjoihin tai asiakas tarjoaa vain niitä, parametritiedoston poistaminen ei jätä käyttökelpoista avaintenvaihtomenetelmää ja kättely epäonnistuu. Virhe ilmaantuu yleensä ohjauskanavan kättelyssä ennen käyttäjän todennusta. Lue salausluettelo ennen kuin syytät puuttuvaa tiedostoa.

Elliptisen käyrän puolella käyrän valitsee palvelimen TLS-kokoonpano, ja OpenVPN tarjoaa vaihtoehdon sen valitsemiseen vanhemmissa haaroissa. TLS 1.3 hoitaa ryhmän neuvottelun protokollan sisällä eikä konsultoi DH-tiedostoa lainkaan.

dh none ei itsessään ole turvallisuuden heikennys. Vaihdon vahvuus riippuu silloin käyrästä ja sarjasta, joista tosiasiassa sovitaan, minkä vuoksi seuraava askel on katsoa, mitä osapuolet valitsivat, eikä puuttuvaa tiedostoa.

Neuvottelun vahvistaminen ennen muokkaamista

Lisää palvelimen ja asiakkaan yksityiskohtaisuutta ja lue ohjauskanavan rivi, jonka OpenVPN tulostaa yhteyden jälkeen. Se nimeää TLS-version ja neuvotellun salauksen sekä ilmoittaa vastapuolen varmenteen avaintyypin. Se yksi rivi vastaa kysymykseen, jota kokoonpanotiedosto vain vihjaa.

Jos se näyttää TLS 1.2:n ECDHE-RSA-sarjalla ja RSA-varmenteella, yhdistelmä on täsmälleen se, mitä dh none odottaa, eikä mitään ole korjattavaa. Jos se näyttää DHE-sarjan tai kättelyn epäonnistumisen ilman yhteistä salausta, korjaus on salauspolitiikassa tai asiakkaan ominaisuuksissa, ei varmenteessa.

Testaa vanhinta asiakasta, jota aiot tukea, koska nykyinen asiakas voi neuvotella TLS 1.3:n, kun taas vanhempi rajoittuu TLS 1.2 -sarjoihin. Jos vanhimmalla asiakkaalla ei ole päällekkäisyyttä, joko laajenna sallittuja sarjoja tai päivitä kyseinen päätepiste.

Älä kytke varmenteen vahvistusta pois päästäksesi kättelyn epäonnistumisesta. Epäonnistuminen kertoo, etteivät osapuolet päässeet sopimukseen avaintenvaihdosta, ja vahvistuksen poistaminen poistaa identiteettitakuun ratkaisematta sopimusta.

Tarkistuslista: onko varmenne RSA, onko ECDHE-sarja sallittu, näyttääkö loki kyseisen sarjan ja neuvotteleeko myös vanhin tuettu asiakas sen? Jos kaikki neljä ovat kyllä, dh none tekee tehtävänsä.