OpenVPN EC vs ED: kvifor namna ikkje er ei styrketrapp

Set ec, ed, ecdh, ecdsa, auth og ei TLS-sifferliste side om side i éin profil, og fila byrjar å sjå ut som ein styrkedial med seks posisjonar. Men det er ho ikkje. Kvart namn svarar på eit anna spørsmål, og to profilar som skil seg i eitt av dei er ikkje nødvendigvis sterkare eller svakare enn kvarandre. Å sortere namna etter arbeidet dei gjer tek om lag fem minutt og hindrar dei fleste av dei dårlege endringane folk gjer i ein konfigurasjon som fungerer.

Sorteringa nedanfor byrjar ved sjølve forvirringa og flyttar seg deretter utover til delane av ein profil som faktisk avgjer kva som vernar trafikken din. Kvar seksjon tek éi feillesing om gongen og viser kva namnet eigentleg heng saman med.

To bokstavar, to ulike spørsmål

Paret som skaper mest diskusjon er EC og ED, og diskusjonen legg vanlegvis til grunn at dei er konkurrerande svar på eitt spørsmål. Dei er ikkje ein gong på same akse. EC skildrar ein matematisk familie: kryptografi med elliptiske kurver, der tryggleiken kjem frå vansken med ein diskret logaritme på ei kurve snarare enn i eit stort endeleg felt.

ED skildrar ei kurveform inne i den familien. Twisted Edwards-kurver er ein representasjon vald for hastigheit og for motstand mot fleire implementasjonsfeil, og Ed25519 er namnet folk vanlegvis meiner. Kurva er ikkje ein konkurrent til kryptografi med elliptiske kurver; ho er éin måte å skrive ei elliptisk kurve på. Å lese ED som "den nyare, sterkare EC" er den første feilsvingen, og alt etter det er vanlegvis feil i same retning.

Signering og utveksling er skilde oppgåver

Når familiespørsmålet er avklart, deler dei gjenverande namna seg i to kolonnar som aldri erstattar kvarandre. Den eine kolonnen signerer, den andre blir samde om ein felles løyndom.

Både EdDSA og ECDSA signerer, men dei er ulike skjema med ulike nøkkelformat, så eit sertifikat utstedt for det eine kan ikkje brukast som det andre. EdDSA er definert for eit lite sett kurver; P-256 er ikkje ei av dei, og difor blir eit P-256-sertifikat verifisert med ECDSA og aldri med Ed25519.

Utvekslingskolonnen har ingen ekvivalent som heiter EdDH. Efemær avtale på ein Curve25519-nøkkel er X25519, og det er ECDH med ei bestemd kurve, akkurat som med P-256. Ed25519 tyder strengt teke signeringsskjemaet, sjølv om namnet blir brukt laust om utvekslinga fordi dei to kurvene er i slekt: Edwards-forma som blir brukt til signering, og Montgomery-forma som blir brukt til X25519, skildrar den same underliggjande gruppa.

Kvifor ein EC-profil ikkje har noka dh-fil

Ei dh-fil inneheld førehandsgenererte parameterar for Diffie-Hellman i eit endeleg felt, og desse parameterane finst fordi eit stort primtal og ein generator må kome frå ein stad. Ei elliptisk-kurve-utveksling treng dei ikkje: den namngitte kurva er parametersettet, og begge sider kjenner det allereie. Det er heile grunnen til at ein EC-profil kan utelate direktivet.

To situasjonar produserer framleis ei dh-linje i ein profil som elles ser moderne ut. Den første er ein ekstra lyttar eller ein eldre peer som faktisk forhandlar grupper i eit endeleg felt. Den andre er resttekst kopiert frå ein mal frå RSA-tida og aldri fjerna. Ein profil som namngir ei kurve for utvekslinga og framleis lastar ei 2048-bits dh-fil, er ikkje tryggare av den grunn; han ber eit ubrukt artefakt.

TLS 1.3 fjerna nøkkelutvekslinga frå namnet

Samanlikn TLS_AES_256_GCM_SHA384 med TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384, og det kortare namnet ser ut som ein nedgradering. Det er ei omdøyiping, og årsaka er strukturell: TLS 1.3 fjerna statisk RSA og Diffie-Hellman-nøkkelutveksling i eit endeleg felt, så ei efemær elliptisk-kurve-utveksling er det einaste gjenverande ikkje-PSK-alternativet. Å namngi ho i kvar suite ville gjenta den same kjensgjerninga eit dusin gonger.

Sertifikattypen forsvann frå namnet av ei skyldt årsak. I 1.3 autentiserer sertifikatet signaturen til handtrykket, ikkje nøkkelavtala, så det vel ikkje lenger suiten. Difor finst det ei eiga sifferliste for 1.3 i konfigurasjonen: suitane vart omdøypte og omorganiserte, ikkje svekka.

Éi følgje er verdt å seie rett ut. ECDHE er ein nøkkelutvekslingsalgoritme og aldri ein siffer. Ein suite som blir skildra som "elliptisk", seier noko om korleis dei to sidene kom fram til ein felles nøkkel, og ingenting om kva som deretter krypterer nyttelasta.

auth autentiserer pakkar, ikkje nyttelasta

Direktivet auth vel HMAC-samandraget som autentiserer pakkane, og den historiske standardverdien er SHA1. Med ein siffer for data som ikkje er AEAD, reknar OpenVPN ut samandraget over cipherteksten og legg det til, eit krypter-deretter-MAC-oppsett som er det som gjer manipulering av utfyllinga upraktisk.

Myten her er at det herdar tunnelen å heve auth til SHA512. Det aukar ikkje styrken i krypteringa, og om den forhandla datasiferen er ein AEAD-modus som AES-256-GCM, blir samandraget slett ikkje brukt på datapakkar. GCM-taggen autentiserer dei allereie, og auth-verdien er att for HMAC-en til kontrollkanalen og for kvar siffer utan AEAD som framleis blir brukt.

Så direktivet betyr noko, men det betyr noko på ein smalare stad enn plasseringa i fila tyder på. Å sjekke kva siffer som faktisk vart forhandla, fortel deg om det i det heile gjeld.

Les profilen etter kolonne, ikkje etter rang

Tre spørsmål skil laga reint, og kvart av dei blir svara av ein annan del av den forhandla økta. Kva siffer vernar nyttelasta? Kva tag eller samandrag garanterer for kvar pakke, og treng siferen som blir brukt i det heile ein slik? Kven sitt sertifikat lukka handtrykket, og er kontrollkanalen i tillegg verna av tls-auth eller tls-crypt?

Ingenting i EC- eller ED-merket avgjer nokon av dei tre, og eit suitenamn åleine avgjer heller ingen av dei. Det forhandla resultatet er det einaste beviset, så les det i staden for å utleie styrke frå 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 fortel deg kva signeringsskjema sertifikatet ditt faktisk brukar, og det er den einaste pålitelege måten å vite om du køyrer ECDSA eller Ed25519. Den andre viser kontrollkanallinja klienten loggføra for økta, inkludert TLS-versjonen og suiten han landa på. Om ei profilendring ikkje kan grunngivast med ein av desse to utskriftene, er det truleg ei endring av eit namn og ikkje av ein eigenskap.