OpenVPN EC protiv ED: zašto ovi nazivi nisu ljestvica jačine

Stavite ec, ed, ecdh, ecdsa, auth i TLS listu šifri jedne pored drugih u jedan profil i datoteka počinje izgledati kao točkić jačine sa šest položaja. Ali nije. Svaki naziv odgovara na drugo pitanje, a dva profila koja se razlikuju u jednom od njih nisu nužno jača ili slabija jedan od drugog. Slaganje naziva po poslu koji obavljaju traje oko pet minuta i sprječava većinu loših izmjena koje ljudi rade na konfiguraciji koja radi.

Slaganje ispod počinje od same zabune, a zatim ide prema van, ka dijelovima profila koji zapravo odlučuju šta štiti vaš saobraćaj. Svaki odjeljak uzima redom jedno pogrešno čitanje i pokazuje za šta je naziv uistinu vezan.

Dva slova, dva različita pitanja

Par koji izaziva najviše rasprave je EC i ED, a rasprava obično pretpostavlja da su oni rivalski odgovori na jedno pitanje. Nisu čak ni na istoj osi. EC opisuje porodicu matematike: kriptografiju eliptičnih krivih, gdje sigurnost dolazi iz težine diskretnog logaritma na krivulji, a ne u velikom konačnom polju.

ED opisuje oblik krive unutar te porodice. Twisted Edwards krive su prikaz odabran zbog brzine i otpornosti na nekoliko grešaka u implementaciji, a Ed25519 je naziv koji ljudi obično misle. Kriva nije konkurent kriptografiji eliptičnih krivih; ona je jedan od načina zapisivanja eliptične krive. Čitanje ED kao "novijeg, jačeg EC" prvi je pogrešan skretaj, i sve nakon njega obično je pogrešno u istom smjeru.

Potpisivanje i razmjena su odvojeni poslovi

Kad je pitanje porodice riješeno, preostali nazivi dijele se u dvije kolone koje nikada ne zamjenjuju jedna drugu. Jedna kolona potpisuje, druga se dogovara o zajedničkoj tajni.

I EdDSA i ECDSA potpisuju, ali to su različite sheme s različitim formatima ključeva, pa se certifikat izdat za jednu ne može koristiti kao ona druga. EdDSA je definiran za mali skup krivih; P-256 nije jedna od njih, zbog čega se certifikat P-256 provjerava s ECDSA i nikada s Ed25519.

Kolona razmjene nema ekvivalent po imenu EdDH. Efemerni dogovor na ključu Curve25519 je X25519, i to je ECDH s određenom krivom, isto kao s P-256. Ed25519 striktno označava shemu potpisa, iako se naziv labavo koristi za razmjenu jer su dvije krive povezane: Edwardsov oblik koji se koristi za potpisivanje i Montgomeryjev oblik koji se koristi za X25519 opisuju istu temeljnu grupu.

Zašto EC profil nema dh datoteku

Datoteka dh sadrži unaprijed generirane parametre za Diffie-Hellman u konačnom polju, a ti parametri postoje jer veliki prost broj i generator moraju odnekud doći. Razmjena na eliptičnoj krivulji ih ne treba: imenovana kriva je skup parametara i obje strane je već znaju. To je cijeli razlog zašto EC profil može izostaviti direktivu.

Dvije situacije i dalje stvaraju red dh u profilu koji inače izgleda moderno. Prva je drugi slušalac ili stariji partner koji zaista pregovara grupe u konačnom polju. Druga je preostali tekst kopiran iz predloška iz RSA ere i nikad uklonjen. Profil koji imenuje krivu za razmjenu i još učitava dh datoteku od 2048 bita nije sigurniji zato što je to učinio; on nosi neiskorišteni artefakt.

TLS 1.3 uklonio je razmjenu ključeva iz naziva

Uporedite TLS_AES_256_GCM_SHA384 s TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 i kraći naziv izgleda kao pogoršanje. To je preimenovanje, a razlog je strukturni: TLS 1.3 uklonio je statični RSA i Diffie-Hellman razmjenu ključeva u konačnom polju, pa je efemerna razmjena na eliptičnoj krivulji jedina preostala opcija bez PSK. Imenovati je u svakom paketu značilo bi ponoviti istu činjenicu dvanaest puta.

Tip certifikata nestao je iz naziva iz povezanog razloga. U 1.3 certifikat potvrđuje potpis rukovanja, a ne dogovor o ključu, pa više ne bira paket. Zato u konfiguraciji postoji zasebna lista šifri za 1.3: paketi su preimenovani i preuređeni, a ne oslabljeni.

Jednu posljedicu vrijedi reći otvoreno. ECDHE je algoritam razmjene ključeva i nikada šifra. Paket opisan kao "eliptični" govori nešto o tome kako su dvije strane došle do zajedničkog ključa, a ništa o tome šta zatim šifruje korisni teret.

auth potvrđuje pakete, ne korisni teret

Direktiva auth bira HMAC sažetak koji potvrđuje pakete, a njezina povijesna zadana vrijednost je SHA1. S ne-AEAD šifrom podataka, OpenVPN računa sažetak nad šifriranim tekstom i dodaje ga, raspored "šifruj pa MAC" koji manipulaciju dopunom čini nepraktičnom.

Mit je ovdje da podizanje auth na SHA512 jača tunel. To ne povećava jačinu šifriranja, a ako je dogovorena šifra podataka AEAD način kao AES-256-GCM, sažetak se uopće ne primjenjuje na pakete podataka. GCM oznaka ih već potvrđuje, a vrijednost auth ostaje za HMAC kontrolnog kanala i za svaku ne-AEAD šifru koja se još koristi.

Dakle direktiva je važna, ali važna je na užem mjestu nego što njezina pozicija u datoteci sugerira. Provjera koja je šifra zaista dogovorena kaže vam primjenjuje li se uopće.

Čitajte profil po koloni, ne po rangu

Tri pitanja čisto razdvajaju slojeve i na svako odgovara drugi dio dogovorene sesije. Koja šifra štiti korisni teret? Koja oznaka ili sažetak jamči za svaki paket i treba li šifra koja se koristi uopće takvu? Čiji je certifikat zatvorio rukovanje i je li kontrolni kanal dodatno zaštićen s tls-auth ili tls-crypt?

Ništa u oznaci EC ili ED ne rješava nijedno od tih tri, a ni naziv paketa sam po sebi ne rješava nijedno od njih. Dogovoreni rezultat jedini je dokaz, pa čitajte njega umjesto da jačinu izvodite iz rječnika:

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

Prva naredba kaže vam koju shemu potpisa vaš certifikat zaista koristi, a to je jedini pouzdan način da znate radite li s ECDSA ili Ed25519. Druga prikazuje red kontrolnog kanala koji je klijent zabilježio za sesiju, uključujući verziju TLS-a i paket na kojem se zaustavio. Ako izmjenu profila ne može opravdati jedan od tih dvaju izlaza, ona je vjerojatno promjena naziva, a ne svojstva.