Miksi openssl rand ei voi tehdä avainta, jota tls-crypt tarvitsee

OpenSSL on jo asennettu, isännällä on entropiaa, ja avaimen luominen sillä tuntuu ilmeiseltä oikotieltä. Tuloste on satunnainen ja salainen ja täysin käyttökelvoton, ja virhe saapuu ohjauskanavan virheenä eikä minään avainmuodon mainitsevana. Tämä harhaanjohtaminen on se kallis osa, koska se lähettää ihmiset tutkimaan salakirjoituksiaan. Se, mitä VPN lukee, on tietty tiedostorakenne, ei mielivaltainen tavupalkki, ja yhtä ominaisuuden muunnosta ei voi tuottaa palvelimen ulkopuolella lainkaan.

Mitä tiedoston levyllä oikeastaan täytyy olla

OpenVPN-ohjelman staattinen avaintiedosto on tekstiä. Se alkaa kommenttirivillä, joka ilmoittaa, mikä se on, kuljettaa heksadataa kiinteäleveyksisinä riveinä ja sisältää yhteensä 256 tavua avainmateriaalia. OpenVPN lukee sen ohjauskanavan jaettuna salaisuutena, ei varmenteena, ei salalauseena eikä minään, minkä TLS-kirjasto tunnistaisi.

Sama objektityyppi palvelee molempia ohjauskanavan ominaisuuksia. Tls-authin kanssa jokainen vastapuoli tarvitsee myös suunnan, jotta toisen puolen paketteja ei voi heijastaa takaisin sille. Tls-cryptin kanssa yksi jaettu salaisuus salaa ja todentaa ohjauskanavan molempiin suuntiin, mikä piilottaa kättelyn ja samalla suojaa sitä.

Mikään tästä ei ole salaista tietoa, eikä muoto ole pointti. Pointti on, että tiedoston on vastattava tarkalleen sitä, mitä lukija odottaa: otsake, rivin leveys, lopun rivinvaihto ja kokonaispituus. Tiedosto, joka on rivin verran pielessä, latautuu roskana tai epäonnistuu kokonaan. Kahden vastapuolen tavu tavulta vertaaminen on siis laillinen ensimmäinen testi, ja se on nopeampaa kuin kummankaan asetustiedoston lukeminen.

Tuetuin tapa tehdä sellainen

Luo tavallinen staattinen avain työkalulla, joka sen kuluttaa, ja viittaa siihen sitten molemmista päistä:

openvpn --genkey secret /etc/openvpn/tc-shared.key
tls-crypt /etc/openvpn/tc-shared.key

Valitsimen kirjoitusasu muuttui ajan myötä: vanhemmat 2.4-aikakauden asennukset käyttivät muotoa, jossa tiedostonimen edessä oli erillinen lippu, kun taas nykyiset koontiversiot hyväksyvät lyhyemmän. Kummassakin tapauksessa tuloksena oleva tiedosto on samaa objektityyppiä, joten tarkistus on, ovatko molemmat vastapuolet identtisiä tavuja.

Toinen sukupolvi lisää rakenteen, jota mikään ulkoinen generaattori ei voi keksiä. Palvelinavain luodaan kerran, ja jokainen asiakas saa siitä johdetun käärityn avaimen:

openvpn --genkey tls-crypt-v2-server /etc/openvpn/tc-v2-server.key
openvpn --genkey tls-crypt-v2-client /etc/openvpn/laptop1.key --tls-crypt-v2 /etc/openvpn/tc-v2-server.key

Se, mitä asiakas saa, ei ole palvelimen oma avain kahdennettuna. Se on kääritty objekti, joka kantaa metatietoja, jotka vain palvelin voi purkaa, ja juuri tuo kääriminen on syy siihen, miksi laitekohtainen tiedosto voidaan peruuttaa koskematta mihinkään muuhun laitteeseen. Pidä palvelinavain palvelimella ja kohtele sitä tämän laitekohtaisen luottamuksen juurena.

Missä käsin tehdyt tavut hajoavat

256 satunnaisen tavun tulostaminen heksana oikean otsakkeen alle antaisi teoriassa staattisen avaintiedoston, joka latautuu. Se on silti huono idea. Jokaisesta muotoiluyksityiskohdasta tulee tilaisuus tuottaa materiaalia, joka epäonnistuu latauksessa tai, pahempaa, jättää kaksi vastapuolta eri arvoihin, jotka paljastuvat vasta todentamisvirheenä.

V2-muunnoksen kanssa mikään vastaava ei ole mahdollista. Kääritty asiakasavain on olemassa vain palvelimen avainprosessin tulosteena, ja palvelin säilyttää materiaalin, joka tarvitaan sen purkamiseen. Satunnainen möykky hylätään tai yksinkertaisesti epäonnistuu salauksen purkamisessa, eikä kumpikaan viesti mainitse satunnaisuutta.

Versioyhteensopivuus on kaiken tämän päällä. Ensimmäinen sukupolvi tarvitsee julkaisun, joka tukee sitä molemmissa päissä, ja toinen tarvitsee jälleen uudemman julkaisun. Asiakas, joka on rakennettu ennen ominaisuuden olemassaoloa, ei voi suorittaa kättelyä loppuun palvelimen kanssa, joka hyväksyy vain käärittyä materiaalia, ja sen raportoima virhe osoittaa ohjauskanavaan eikä versioon.

Kierto ilman että kaikki jäävät ulkopuolelle

Yhden jaetun salaisuuden kiertäminen on koordinointiharjoitus, ei tekninen. Jokaisella asiakkaalla on oltava korvaava tiedosto käsissään ennen kuin palvelin vetää edellisen pois, ja mikä tahansa kone, jolla on vielä vanha arvo, epäonnistuu sinä hetkenä. Älä aloita tuota kiertoa kesken työpäivän.

V2-järjestelyssä kierto on laitekohtainen: myönnä uusi kääritty avain yhdelle koneelle ja poista vanha vain siltä koneelta. Se on pääasiallinen peruste siirtymiselle, kun jokainen asiakas on julkaisulla, joka tukee sitä.

Tiedostojen käyttöoikeudet kuuluvat samaan keskusteluun. Avaimen tulisi olla luettavissa vain siltä tililtä, joka ajaa palvelua, eikä sen tulisi sijaita samassa tietovarastossa kuin suojaamansa profiilit. OpenVPN 2.6 -viite dokumentoi luontimuodot ja avainmateriaaliosiot, mikä on parempi lähde kuin foorumiviestistä kopioitu komento.