OpenVPN EC vs ED: miksi nimet eivät ole vahvuusportaikko

Laita ec, ed, ecdh, ecdsa, auth ja TLS-salausluettelo rinnakkain yhteen profiiliin, niin tiedosto alkaa näyttää kuusiasentoiselta tehonvalitsimelta. Sitä se ei ole. Jokainen nimi vastaa eri kysymykseen, eivätkä kaksi profiilia, jotka eroavat yhdessä niistä, ole välttämättä toisiaan vahvempia tai heikompia. Nimien lajittelu sen mukaan, mitä työtä ne tekevät, kestää noin viisi minuuttia ja estää suurimman osan huonoista muokkauksista, joita ihmiset tekevät toimivaan kokoonpanoon.

Alla oleva lajittelu alkaa itse sekaannuksesta ja etenee sitten ulospäin niihin profiilin osiin, jotka todella päättävät, mikä suojaa liikennettäsi. Jokainen jakso ottaa vuorollaan yhden väärinkäsityksen ja näyttää, mihin nimeen todella liittyy.

Kaksi kirjainta, kaksi eri kysymystä

Eniten väittelyä aiheuttava pari on EC ja ED, ja väittely olettaa yleensä, että ne ovat kilpailevia vastauksia yhteen kysymykseen. Ne eivät ole edes samalla akselilla. EC kuvaa matematiikan perhettä: elliptisten käyrien salaus, jossa turvallisuus tulee diskreetin logaritmin vaikeudesta käyrällä eikä suuressa äärellisessä kunnassa.

ED kuvaa käyrän muotoa tuon perheen sisällä. Twisted Edwards -käyrät ovat esitys, joka on valittu nopeuden ja useiden toteutusvirheiden kestävyyden vuoksi, ja Ed25519 on nimi, jota ihmiset yleensä tarkoittavat. Käyrä ei ole elliptisten käyrien salauksen kilpailija; se on yksi tapa kirjoittaa elliptinen käyrä. ED:n lukeminen "uudempana, vahvempana EC:nä" on ensimmäinen väärä käännös, ja kaikki sen jälkeen on yleensä väärin samaan suuntaan.

Allekirjoittaminen ja vaihtaminen ovat eri töitä

Kun perhekysymys on ratkennut, jäljelle jäävät nimet jakautuvat kahteen sarakkeeseen, jotka eivät koskaan korvaa toisiaan. Toinen sarake allekirjoittaa, toinen sopii yhteisestä salaisuudesta.

Sekä EdDSA että ECDSA allekirjoittavat, mutta ne ovat eri skeemoja eri avainmuodoilla, joten toiselle myönnettyä varmennetta ei voi käyttää toisena. EdDSA on määritelty pienelle käyräjoukolle; P-256 ei ole yksi niistä, minkä vuoksi P-256-varmenne vahvistetaan ECDSA:lla eikä koskaan Ed25519:llä.

Vaihtosarakkeella ei ole EdDH-nimistä vastinetta. Efemeerinen sopimus Curve25519-avaimesta on X25519, ja se on ECDH tietyllä käyrällä, täsmälleen kuten P-256:n kanssa. Ed25519 tarkoittaa tiukasti allekirjoitusskeemaa, vaikka nimeä käytetään löyhästi vaihtamisesta, koska kaksi käyrää liittyvät toisiinsa: allekirjoittamiseen käytetty Edwards-muoto ja X25519:ään käytetty Montgomery-muoto kuvaavat samaa taustaryhmää.

Miksi EC-profiilissa ei ole dh-tiedostoa

dh-tiedosto sisältää etukäteen luodut parametrit äärellisen kunnan Diffie-Hellmanille, ja ne parametrit ovat olemassa, koska suuren alkuluvun ja generaattorin on tultava jostakin. Elliptisen käyrän vaihto ei tarvitse niitä: nimetty käyrä on parametrijoukko, ja molemmat osapuolet tuntevat sen jo. Juuri siksi EC-profiili voi jättää direktiivin pois.

Kaksi tilannetta tuottaa yhä dh-rivin profiiliin, joka muuten näyttää nykyaikaiselta. Ensimmäinen on toinen kuuntelija tai vanhempi vastapuoli, joka todella neuvottelee äärellisen kunnan ryhmiä. Toinen on RSA-aikakauden mallista kopioitu ja koskaan poistamatta jäänyt jäänteteksti. Profiili, joka nimeää käyrän vaihtoa varten ja lataa silti 2048-bittisen dh-tiedoston, ei ole sen turvallisempi siksi, että teki niin; se kantaa käyttämätöntä artefaktia.

TLS 1.3 poisti avaintenvaihdon nimestä

Vertaa TLS_AES_256_GCM_SHA384-nimeä TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384-nimeen, niin lyhyempi näyttää heikennykseltä. Se on uudelleennimeäminen, ja syy on rakenteellinen: TLS 1.3 poisti staattisen RSA:n ja äärellisen kunnan Diffie-Hellman-avaintenvaihdon, joten efemeerinen elliptisen käyrän vaihto on ainoa jäljellä oleva ei-PSK-vaihtoehto. Sen nimeäminen jokaiseen sarjaan toistaisi saman tosiasian tusinan kertoja.

Varmenteen tyyppi katosi nimestä läheisestä syystä. Versiossa 1.3 varmenne todentaa kättelyn allekirjoituksen, ei avainsopimusta, joten se ei enää valitse sarjaa. Siksi kokoonpanossa on erillinen salausluettelo versiolle 1.3: sarjat nimettiin uudelleen ja järjestettiin uudelleen, ei heikennetty.

Yksi seuraus kannattaa sanoa suoraan. ECDHE on avaintenvaihtoalgoritmi eikä koskaan salaus. "Elliptiseksi" kuvattu sarja kertoo jotain siitä, miten kaksi vastapuolta päätyivät yhteiseen avaimeen, eikä mitään siitä, mikä sitten salaa hyötykuorman.

auth todentaa paketit, ei hyötykuormia

Direktiivi auth valitsee HMAC-tiivisteen, joka todentaa paketit, ja sen historiallinen oletusarvo on SHA1. Kun datasalaus ei ole AEAD, OpenVPN laskee tiivisteen salatekstistä ja liittää sen, salaa-sitten-MAC-järjestely, joka tekee täytteen muokkaamisesta epäkäytännöllistä.

Myytti tässä on, että auth-arvon nostaminen SHA512:een lujittaa tunnelia. Se ei nosta salauksen vahvuutta, ja jos neuvoteltu datasalaus on AEAD-tila kuten AES-256-GCM, tiivistettä ei sovelleta datapaketteihin lainkaan. GCM-tunniste todentaa ne jo, ja auth-arvo jää ohjauskanavan HMAC:lle ja kaikille yhä käytössä oleville ei-AEAD-salauksille.

Direktiivi on siis tärkeä, mutta tärkeä kapeammassa paikassa kuin sen sijainti tiedostossa antaa ymmärtää. Sen tarkistaminen, mikä salaus todella neuvoteltiin, kertoo, soveltuuko se lainkaan.

Lue profiilia sarakkeittain, ei arvojärjestyksessä

Kolme kysymystä erottavat kerrokset puhtaasti, ja kuhunkin vastaa eri osa neuvotellusta istunnosta. Mikä salaus suojaa hyötykuorman? Mikä tunniste tai tiiviste takaa jokaisen paketin, ja tarvitseeko käytössä oleva salaus sellaista lainkaan? Kuka varmenne sulki kättelyn, ja onko ohjauskanava lisäksi suojattu tls-auth- tai tls-crypt-direktiivillä?

Mikään EC- tai ED-merkinnässä ei ratkaise yhtäkään noista kolmesta, eikä sarjan nimi yksinään ratkaise myöskään yhtäkään niistä. Neuvoteltu tulos on ainoa todiste, joten lue se sen sijaan, että päättelet vahvuuden sanastosta:

openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.log

Ensimmäinen komento kertoo, mitä allekirjoitusskeemaa varmenne todella käyttää, ja se on ainoa luotettava tapa tietää, käytätkö ECDSA:ta vai Ed25519:ää. Toinen näyttää ohjauskanavan rivin, jonka asiakas kirjasi istunnosta, mukaan lukien TLS-version ja sarjan, johon päädyttiin. Jos profiilimuutosta ei voi perustella jommallakummalla näistä kahdesta tulosteesta, se on todennäköisesti muutos nimessä eikä ominaisuudessa.