Staattisen avaintiedoston bittimäärä ei ole OpenVPN-salauksen vahvuus

Skanneri tai kollega osoittaa OpenVPN:n staattisen avaintiedoston sisään painetun bittimäärän ja kysyy, miksi tunneli ei käytä sen kokoista salausta. Kysymys kuulostaa järkevältä, eikä vastaus ole luku: otsake laskee tallennettua avainmateriaalia, kun taas salaus kuluttaa vain sen osan, jonka sen avainkoko vaatii. Jos tuo summa tulkitaan vahvuusasetukseksi, syntyy muutoksia, jotka eivät muuta mitään. Muoto rakennettiin pitämään enemmän materiaalia kuin yksikään algoritmi käyttää.

Tässä sekoittuvat kaksi kysymystä: kuinka paljon avainmateriaalia tiedosto tallentaa ja kuinka vahva neuvoteltu salaus on. Vain jälkimmäinen kuvaa tunnelia.

Mitä otsakkeen luku oikeastaan laskee

Säiliö serialisoi salausmateriaalin ja HMAC-materiaalin erillisinä rakenteina, ja kaksisuuntainen muoto pitää kahta tällaista joukkoa, jotta kumpikin suunta voi kantaa omat avaimensa. Kirjoittava koodi johtaa painetun luvun serialisoitujen rakenteiden määrästä, niiden koosta ja kahdeksasta bitistä tavua kohden. Se on tallennuksen päälle tehtyä aritmetiikkaa, ei väite siitä, että yksi salaus kuluttaisi jokaisen tallennetun tavun. Otsake myös kiinnittää salausmateriaalin enimmäisvarauksen, jotta kirjastopäivitys ei voi hiljaa muuttaa muodon mittoja.

Vertaa sitä varmenneavaimeen, jossa bittimäärä todella kuvaa yhden objektin kokoa. 4,096-bittinen RSA-avain ja avaintiedosto, jonka otsake lukee 4,096 bittiä, ovat erilaisia artefakteja eri tehtävillä, ja niiden asettaminen kahdeksi asetukseksi samaan säätimeen johtaa huonoihin johtopäätöksiin.

Kaksi avainjoukkoa yhdessä tiedostossa

Kumpikin tiedoston puolisko tuottaa salaus- ja todennusmateriaalia, koska ennalta jaetun avaimen tila suojaa paketteja molempiin suuntiin näillä erillisillä paloilla. Aktiivinen salaus käyttää vain tavut, jotka sen avainkoko vaatii, ja tiiviste käyttää omaa tulostekokoaan, siksi käyttökelpoinen vahvuus tulee asetuksista eikä tiedoston pituudesta. Heksadesimaalisen lohkon pidentäminen ei pyydä määritettyä algoritmia kuluttamaan sitä enemmän. Kommenteen suuremman luvun kirjoittaminen muuttaa vielä vähemmän.

Jos todella haluat pidemmän avaimen, muutettava asetus on salaus tai tiiviste, ja generaattori tuottaa sen, mitä valitut algoritmit tarvitsevat.

Profiilin lukeminen kertoo, mikä tila sinulla on

Sama tiedostomuoto palvelee kahta melko erilaista tehtävää, ja vain profiili kertoo, kumpi sinulla on. Vanha secret-rivi tekee tiedostosta tunnelin ainoan avainmateriaalin, kun taas tls-auth tai tls-crypt tekee siitä ohjauskanavan suojauksen varmenneiden rinnalle. Kumpikaan käyttö ei muuta sitä asiakkaan varmenneyksityisavaimeksi, niin samanlaiselta lohko näyttää. Tunnista asetus ja versio ennen korvaajan luomista ja käytä dokumentoitua generaattoria sen sijaan, että lisäisit merkkejä.

Tämä ero ratkaisee myös vastauksen paljastumiseen. Vuotava tls-auth-avain ei paljasta istuntoavaimia, mutta antaa hyökkääjän syöttää ohjauskanavan liikennettä, joten se on silti vaihdettava. Vuotanut secret-avain on pahempi, koska se oli materiaali, joka suojasi itse dataa.

Mitä tietoturvakatselmuksen pitäisi kirjata

Kirjaa kolme asiaa erikseen: neuvoteltu datakanavan suojaus, ohjauskanavan suojaus ja se, miten vastapuolet todentavat itsensä. Rivi kuten data-ciphers AES-256-GCM kuvaa vain ensimmäisen, eikä siihen pysähtyvä raportti voi vastata, onko ohjauskanava suojattu lainkaan. Staattisen avaimen tiedosto kuuluu toiseen kategoriaan, kun sitä käytetään tls-auth- tai tls-crypt-asetuksen kanssa, eikä kumpaankaan, kun sitä ei käytetä. Katsastajat, jotka sekoittavat kategoriat, pyytävät suurempaa avaintiedostoa, kun he oikeasti haluavat vahvemman salauksen.

Jos tiedosto on paljastunut, kierrätä se ja jaa se uudelleen hyväksyttyä kanavaa pitkin. Merkkien lisääminen vaarantuneeseen salaisuuteen ei ole kierrätystä, ja se jättää paljastuneen materiaalin voimaan.

Pidä kierrätysmerkintä sen profiilin yhteydessä, johon se kuuluu. Seuraava katselmus kysyy mikä avain suojasi mitäkin jaksoa, eikä otsake vastaa siihen.