OpenVPN EC vs ED: hvorfor navnene ikke er en styrkestige

Sett ec, ed, ecdh, ecdsa, auth og en TLS-sifferliste side om side i én profil, og filen begynner å se ut som en styrkedial med seks posisjoner. Men det er den ikke. Hvert navn svarer på et annet spørsmål, og to profiler som skiller seg i ett av dem er ikke nødvendigvis sterkere eller svakere enn hverandre. Å sortere navnene etter arbeidet de gjør tar omtrent fem minutter og hindrer de fleste av de dårlige endringene folk gjør i en konfigurasjon som fungerer.

Sorteringen nedenfor starter ved selve forvirringen og beveger seg deretter utover til delene av en profil som faktisk avgjør hva som beskytter trafikken din. Hver seksjon tar én feillesning om gangen og viser hva navnet egentlig henger sammen med.

To bokstaver, to forskjellige spørsmål

Paret som skaper mest diskusjon er EC og ED, og diskusjonen antar vanligvis at de er konkurrerende svar på ett spørsmål. De er ikke engang på samme akse. EC beskriver en matematisk familie: kryptografi med elliptiske kurver, der sikkerheten kommer fra vanskeligheten med en diskret logaritme på en kurve snarere enn i et stort endelig felt.

ED beskriver en kurveform inne i den familien. Twisted Edwards-kurver er en representasjon valgt for hastighet og for motstand mot flere implementeringsfeil, og Ed25519 er navnet folk vanligvis mener. Kurven er ikke en konkurrent til kryptografi med elliptiske kurver; den er én måte å skrive en elliptisk kurve på. Å lese ED som "den nyere, sterkere EC" er den første feilsvingen, og alt etter det er vanligvis feil i samme retning.

Signering og utveksling er atskilte oppgaver

Når familiespørsmålet er avklart, deler de gjenværende navnene seg i to kolonner som aldri erstatter hverandre. Den ene kolonnen signerer, den andre blir enige om en felles hemmelighet.

Både EdDSA og ECDSA signerer, men de er forskjellige skjemaer med forskjellige nøkkelformater, så et sertifikat utstedt for det ene kan ikke brukes som det andre. EdDSA er definert for et lite sett kurver; P-256 er ikke en av dem, og derfor verifiseres et P-256-sertifikat med ECDSA og aldri med Ed25519.

Utvekslingskolonnen har ingen ekvivalent som heter EdDH. Efemær avtale på en Curve25519-nøkkel er X25519, og det er ECDH med en bestemt kurve, akkurat som med P-256. Ed25519 betyr strengt tatt signeringsskjemaet, selv om navnet brukes løst om utvekslingen fordi de to kurvene er beslektet: Edwards-formen som brukes til signering, og Montgomery-formen som brukes til X25519, beskriver den samme underliggende gruppen.

Hvorfor en EC-profil ikke har noen dh-fil

En dh-fil inneholder forhåndsgenererte parametere for Diffie-Hellman i et endelig felt, og disse parameterne finnes fordi et stort primtall og en generator må komme fra et sted. En elliptisk-kurve-utveksling trenger dem ikke: den navngitte kurven er parametersettet, og begge sider kjenner det allerede. Det er hele grunnen til at en EC-profil kan utelate direktivet.

To situasjoner produserer fortsatt en dh-linje i en profil som ellers ser moderne ut. Den første er en ekstra lytter eller en eldre peer som faktisk forhandler grupper i et endelig felt. Den andre er resttekst kopiert fra en mal fra RSA-tiden og aldri fjernet. En profil som navngir en kurve for utvekslingen og fortsatt laster en 2048-bits dh-fil, er ikke sikrere av den grunn; den bærer et ubrukt artefakt.

TLS 1.3 fjernet nøkkelutvekslingen fra navnet

Sammenlign TLS_AES_256_GCM_SHA384 med TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384, og det kortere navnet ser ut som en nedgradering. Det er en omdøping, og årsaken er strukturell: TLS 1.3 fjernet statisk RSA og Diffie-Hellman-nøkkelutveksling i et endelig felt, så en efemær elliptisk-kurve-utveksling er det eneste gjenværende ikke-PSK-alternativet. Å navngi den i hver suite ville gjenta den samme kjensgjerningen et dusin ganger.

Sertifikattypen forsvant fra navnet av en beslektet grunn. I 1.3 autentiserer sertifikatet håndtrykkets signatur, ikke nøkkelavtalen, så det velger ikke lenger suiten. Derfor finnes det en egen sifferliste for 1.3 i konfigurasjonen: suitene ble omdøpt og omorganisert, ikke svekket.

Én konsekvens er verdt å si rett ut. ECDHE er en nøkkelutvekslingsalgoritme og aldri en siffer. En suite som beskrives som "elliptisk", sier noe om hvordan de to partene kom frem til en felles nøkkel, og ingenting om hva som deretter krypterer nyttelasten.

auth autentiserer pakker, ikke nyttelasten

Direktivet auth velger HMAC-sammendraget som autentiserer pakkene, og dets historiske standardverdi er SHA1. Med en siffer for data som ikke er AEAD, beregner OpenVPN sammendraget over ciphertexten og legger det til, et krypter-deretter-MAC-oppsett som er det som gjør manipulering av utfyllingen upraktisk.

Myten her er at det herder tunnelen å heve auth til SHA512. Det øker ikke styrken i krypteringen, og hvis den forhandlede datasiferen er en AEAD-modus som AES-256-GCM, brukes ikke sammendraget i det hele tatt på datapakker. GCM-taggen autentiserer dem allerede, og auth-verdien er igjen for HMAC-en til kontrollkanalen og for enhver siffer uten AEAD som fortsatt brukes.

Så direktivet betyr noe, men det betyr noe på et smalere sted enn plasseringen i filen antyder. Å sjekke hvilken siffer som faktisk ble forhandlet, forteller deg om det i det hele tatt gjelder.

Les profilen etter kolonne, ikke etter rang

Tre spørsmål skiller lagene rent, og hvert av dem besvares av en annen del av den forhandlede økten. Hvilken siffer beskytter nyttelasten? Hvilken tag eller hvilket sammendrag garanterer for hver pakke, og trenger siferen som brukes i det hele tatt en slik? Hvem sitt sertifikat lukket håndtrykket, og er kontrollkanalen i tillegg beskyttet av tls-auth eller tls-crypt?

Ingenting i EC- eller ED-merket avgjør noen av de tre, og et suitenavn alene avgjør heller ingen av dem. Det forhandlede resultatet er det eneste beviset, så les det i stedet for å utlede styrke fra ordforrådet:

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

Den første kommandoen forteller deg hvilket signeringsskjema sertifikatet ditt faktisk bruker, og det er den eneste pålitelige måten å vite om du kjører ECDSA eller Ed25519. Den andre viser kontrollkanallinjen klienten loggførte for økten, inkludert TLS-versjonen og suiten den landet på. Hvis en profilendring ikke kan begrunnes med en av disse to utskriftene, er det sannsynligvis en endring av et navn og ikke av en egenskap.