OpenVPN EC vs ED: miért nem erősségi létra ez a két név

Tegye egymás mellé egy profilban az ec, ed, ecdh, ecdsa, auth elemeket és egy TLS-rejterszámítási listát, és a fájl máris úgy kezd kinézni, mint egy hatállású erősségkapcsoló. Pedig nem az. Minden név más kérdésre válaszol, és két profil, amely egyikükben különbözik, nem feltétlenül erősebb vagy gyengébb a másiknál. A nevek feladatok szerinti rendezése körülbelül öt percet vesz igénybe, és megakadályozza a legtöbb rossz módosítást, amelyet az emberek egy működő konfiguráción ejtenek.

Az alábbi rendezés magától a zavartól indul, majd kifelé halad a profil azon részei felé, amelyek valóban eldöntik, mi védi a forgalmát. Minden szakasz sorra vesz egy félreolvasást, és megmutatja, mihez kapcsolódik valójában a név.

Két betű, két különböző kérdés

A legtöbb vitát kiváltó pár az EC és az ED, és a vita általában azt feltételezi, hogy rivális válaszok egyetlen kérdésre. Még csak nem is ugyanazon a tengelyen vannak. Az EC a matematika egy családját írja le: az elliptikus görbés kriptográfiát, ahol a biztonság egy görbén vett diszkrét logaritmus nehézségéből származik, nem pedig egy nagy véges testben.

Az ED egy görbealakot ír le ezen a családon belül. A Twisted Edwards-görbék olyan reprezentáció, amelyet a sebesség és több implementációs hiba elleni ellenállás miatt választottak, és az Ed25519 az a név, amelyre az emberek általában gondolnak. A görbe nem versenytársa az elliptikus görbés kriptográfiának; ez az elliptikus görbe egyik írásmódja. Az ED-t „az újabb, erősebb EC”-ként olvasni az első rossz kanyar, és minden, ami utána jön, általában ugyanabban az irányban téves.

Az aláírás és a csere külön feladat

Amint a család kérdése eldőlt, a fennmaradó nevek két oszlopra válnak, amelyek soha nem helyettesítik egymást. Az egyik oszlop aláír, a másik megállapodik egy közös titokban.

Az EdDSA és az ECDSA is aláír, de különböző sémák különböző kulcsformátumokkal, ezért az egyikhez kiállított tanúsítvány nem használható a másikként. Az EdDSA kis számú görbére van definiálva; a P-256 nem tartozik közéjük, ezért a P-256 tanúsítvány ECDSA-val ellenőrizhető, és soha nem Ed25519-cel.

A csereoszlopnak nincs EdDH nevű megfelelője. A Curve25519 kulcson létrejövő efemer megegyezés az X25519, és ez ECDH egy adott görbével, pontosan úgy, mint a P-256 esetében. Az Ed25519 szigorúan az aláírási sémát jelenti, bár a nevet lazán használják a cserére, mert a két görbe rokon: az aláíráshoz használt Edwards-alak és az X25519-hez használt Montgomery-alak ugyanazt az alapcsoportot írja le.

Miért nincs dh fájl az EC-profilban

A dh fájl előre generált paramétereket tartalmaz véges testű Diffie-Hellmanhoz, és ezek a paraméterek azért léteznek, mert egy nagy prímszámnak és egy generátornak valahonnan jönnie kell. Az elliptikus görbés cserének nincs rájuk szüksége: a megnevezett görbe maga a paraméterkészlet, és mindkét fél már ismeri. Ez a teljes oka annak, hogy az EC-profil elhagyhatja az utasítást.

Két helyzet mégis dh sort hoz létre egy egyébként modernnek tűnő profilban. Az első egy második figyelő vagy egy régebbi partner, amely valóban véges testű csoportokról tárgyal. A második az RSA-korszak sablonjából átmásolt, soha el nem távolított maradék szöveg. Egy profil, amely görbét nevez meg a cseréhez, és mégis betölt egy 2048 bites dh fájlt, nem biztonságosabb attól, hogy ezt tette; egy használaton kívüli elemet cipel.

A TLS 1.3 kivette a kulcscserét a névből

Hasonlítsa össze a TLS_AES_256_GCM_SHA384 és a TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 nevet, és a rövidebb név visszalépésnek tűnik. Átnevezés történt, és az ok szerkezeti: a TLS 1.3 eltávolította a statikus RSA-t és a véges testű Diffie-Hellman kulcscserét, így az efemer elliptikus görbés csere az egyetlen megmaradt nem PSK-s lehetőség. Ha minden csomagban megneveznék, ugyanazt a tényt ismételnék tucatszor.

A tanúsítvány típusa rokon okból tűnt el a névből. Az 1.3-ban a tanúsítvány a kézfogás aláírását hitelesíti, nem a kulcsmegállapodást, ezért már nem választja ki a csomagot. Ezért van külön rejterszámítási lista az 1.3-hoz a konfigurációban: a csomagokat átnevezték és átszervezték, nem gyengítették.

Egy következményt érdemes nyíltan kimondani. Az ECDHE kulcscsere-algoritmus, és soha nem rejtjel. Az „elliptikusnak” nevezett csomag arról mond valamit, hogyan jutott a két fél közös kulcshoz, és semmit arról, mi titkosítja utána a hasznos terhelést.

Az auth csomagokat hitelesít, nem hasznos terhelést

Az auth utasítás azt a HMAC-lenyomatot választja ki, amely a csomagokat hitelesíti, történelmi alapértéke pedig a SHA1. Nem AEAD adatrejtjel esetén az OpenVPN a lenyomatot a rejtjelszövegen számítja ki és hozzáfűzi, ez a titkosítás-után-MAC elrendezés az, ami a kitöltéssel való manipulálást gyakorlatilag lehetetlenné teszi.

A mítosz itt az, hogy az auth SHA512-re emelése megszilárdítja az alagutat. Ez nem növeli a titkosítás erősségét, és ha az egyeztetett adatrejtjel AEAD-mód, például AES-256-GCM, akkor a lenyomat egyáltalán nem kerül alkalmazásra az adatcsomagokon. A GCM-címke már hitelesíti őket, és az auth érték a vezérlőcsatorna HMAC-jára marad, valamint minden olyan nem AEAD rejtjelre, amelyet még használnak.

Az utasítás tehát számít, de szűkebb helyen számít, mint amit a fájlban elfoglalt helye sugall. Annak ellenőrzése, hogy melyik rejtjelet egyeztették valójában, megmondja, hogy egyáltalán érvényes-e.

Oszloponként olvassa a profilt, ne rang szerint

Három kérdés választja el tisztán a rétegeket, és mindegyikre az egyeztetett munkamenet más része válaszol. Melyik rejtjel védi a hasznos terhelést? Melyik címke vagy lenyomat kezeskedik minden csomagért, és egyáltalán igényel-e ilyet a használt rejtjel? Kinek a tanúsítványa zárta le a kézfogást, és a vezérlőcsatorna védett-e emellett tls-auth vagy tls-crypt használatával?

Az EC vagy ED címkében semmi nem dönt el egyet sem a háromból, és egy csomagnév önmagában sem dönt el egyet sem közülük. Az egyeztetett eredmény az egyetlen bizonyíték, ezért azt olvassa, ne a szókincsből következtessen az erősségre:

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

Az első parancs megmondja, hogy a tanúsítványa valójában melyik aláírási sémát használja, és ez az egyetlen megbízható módja annak megismerésére, hogy ECDSA-t vagy Ed25519-et futtat-e. A második megmutatja azt a vezérlőcsatorna-sort, amelyet a kliens a munkamenethez naplózott, beleértve a TLS-verziót és azt a csomagot, amelynél megállapodott. Ha egy profil módosítása nem igazolható e két kimenet valamelyikével, az valószínűleg név és nem tulajdonság változása.