tls-auth vs tls-crypt: mitä kumpikin suojaa OpenVPN:ssä

Molemmat valinnat käyttävät jaettua avaintiedostoa ja molemmat tekevät kättelyliikenteen väärentämisestä vaikeampaa, minkä vuoksi niitä pidetään saman ominaisuuden kahtena nimenä. Ne eivät ole. Toinen allekirjoittaa ohjauspaketit, toinen myös salaa ne, eikä kummallakaan ole mitään tekemistä salauksen kanssa, joka suojaa hyötykuormaasi.

Tällä erolla on merkitystä, kun profiili ei saa yhteyttä, kun tietoturvakatselmus kysyy, mitä avain suojaa, ja kun joku olettaa lisätiedoston tekevän tunnelista salatun jollain määrittelemättömällä tavalla.

Mitä jaettu avain todella suojaa

Näiden valintojen käyttämä avain kuuluu ohjauskanavaan: vaihtoon, joka neuvottelee parametrit, todistaa identiteetit ja johtaa data-avaimet. Se on ennalta jaettu salaisuus, joka molemmilla päillä on oltava ennen kuin kättely voi jatkua. Koska se on ennen identiteettitarkistuksia, väärä avain pysäyttää keskustelun aiemmin kuin väärä salasana tekisi. Tämä järjestys selittää, miksi vikatila on niin hiljainen.

tls-auth käyttää tätä salaisuutta laskeakseen HMAC:n ohjauspaketeille. Paketti ilman kelvollista allekirjoitusta hylätään ennen kuin se saavuttaa kalliimman TLS-käsittelyn, minkä vuoksi valinta kuvataan usein ensimmäiseksi suodattimeksi eikä TLS:n korvikkeeksi.

tls-crypt menee pidemmälle salaamalla suojatun ohjausliikenteen sen todentamisen lisäksi. Varmenteiden sisältö, neuvotellut salausnimet ja muut kättelyn yksityiskohdat eivät ole enää verkossa näkyvissä, eikä avaimeton tarkkailija näe edes sitä, mitä TLS-versiota yritetään. Käyttöönotolle, joka pelkää VPN-tunnisteensa paljastumista, tämä ominaisuus on tärkein syy valita se. Se on silti ryhmäsalaisuus, ei käyttäjäkohtainen tunniste.

Kumpikaan mekanismi ei myönnä identiteettejä. Jaettu avain on ryhmäsalaisuus, ja jokainen, jolla se on, voi täyttää tarkistuksen tämän tason.

Missä kaksi valintaa eroavat

Havaittava ero on se, mitä tarkkailija näkee. tls-auth-valinnalla kättely on näkyvissä mutta ilman avainta todentamaton. tls-crypt-valinnalla kättely on läpinäkymätön kaikille, joilla ei ole avainta.

Myös kokoonpano eroaa. tls-auth-valintaa käytetään suuntauarvon kanssa, joten toinen puoli käyttää toista puolikasta avainmateriaalista ja toinen puoli toista. tls-crypt käyttää yhtä avainta molempiin suuntiin, joten suuntadirektiivi ei kuulu sen rakenteeseen.

Nykyaikaisissa julkaisuissa kaksi valintaa sulkevat toisensa pois. Profiilissa tulee olla toinen niistä, ei molempia, ja palvelimen ja asiakkaan on sovittava kumpi, yhteensopivalla avainmateriaalilla. Vanhan direktiivin pitäminen uuden vieressä on tavallinen siirtymän jäänne. Poista passiivinen, jotta seuraava lukija tietää, mikä kerros on todella voimassa.

Uudempi muunnos, tls-crypt-v2, sitoo jokaisen asiakkaan omaan käärittyyn avaimeensa, joten yhden asiakkaan peruuttaminen ei vaadi ryhmäavaimen uudelleenmyöntämistä. Se kannattaa tuntea, mutta se on eri valinta eikä kummankaan tässä kuvatun synonyymi.

Miksi eroavaisuus näyttää siltä, ettei mitään tapahdu

Kun jaettu materiaali ei täsmää, vastapuoli hylkää paketit kertomatta lähettäjälle miksi. Luettavaa todennusvirhettä ei ole, koska paketti ei koskaan saavuttanut kerrosta, joka olisi tuottanut sen.

Asiakas yrittää uudelleen, palvelin ei sano mitään ja oire näyttää verkko-ongelmalta. Sitten ihmiset käynnistävät palvelun uudelleen, kirjoittavat tilin salasanan uudelleen tai poistavat suojadirektiivin «testatakseen» sitä, mikä muuttaa käyttöönottoa sen sijaan, että diagnosoisi sen.

Lue palvelimen lokista ensimmäinen pakettitason valitus, älä viimeistä uudelleenyritysriviä. Varmista, että molemmilla puolilla on sama valinta ja identtinen avainmateriaali, ja että avaintiedostoa ei luotu uudelleen vain toisella puolella.

Direktiivin poistaminen ei ole turvallinen korjaus. Se poistaa suojakerroksen käytöstä jokaiselta asiakkaalta, ja sen jälkeen toimiva tunneli todistaa vain, että kyseinen kerros oli eroavaisuus.

Mitä on vielä määritettävä erikseen

Nämä valinnat eivät tarkista, kuka vastapuoli on. Varmenteiden validointi, luottamuksen ankkuri ja odotettu palvelinnimi ovat edelleen erillisiä vaatimuksia, eikä mistään niistä tule valinnaista jaetun avaimen vuoksi.

Ne eivät myöskään valitse datasalainta. Se on erillinen neuvottelu, jota molempien päiden datakanavan asetukset ohjaavat, ja tls-crypt-valinnalla suojattu tunneli voi silti käyttää salausta, jota et tarkoittanut.

Lopuksi jaettu avain itsessään vaatii käsittelyä. Kohtele sitä salaisuutena, jaa se hyväksyttyä kanavaa pitkin ja vaihda se, kun joku sen omistanut lähtee. Koska se on jaettu, sen paljastuminen on jokaisen sitä käyttävän päätepisteen paljastuminen.