OpenVPN EC vs ED: hvorfor navnene ikke er en styrkestige

Sæt ec, ed, ecdh, ecdsa, auth og en TLS-chifferliste side om side i én profil, og filen begynder at ligne et styrkehjulet med seks positioner. Det er den ikke. Hvert navn besvarer et forskelligt spørgsmål, og to profiler, der adskiller sig i et af dem, er ikke nødvendigvis stærkere eller svagere end hinanden. At sortere navnene efter det arbejde, de udfører, tager cirka fem minutter og forhindrer de fleste af de dårlige ændringer, folk laver i en fungerende konfiguration.

Sorteringen nedenfor starter ved selve forvirringen og arbejder sig derefter udad til de dele af profilen, som faktisk afgør, hvad der beskytter din trafik. Hvert afsnit tager en fejllæsning ad gangen og viser, hvad navnet egentlig hænger sammen med.

To bogstaver, to forskellige spørgsmål

Det par, der skaber mest diskussion, er EC og ED, og diskussionen antager som regel, at de er rivaliserende svar på ét spørgsmål. De er ikke engang på samme akse. EC beskriver en matematisk familie: kryptografi med elliptiske kurver, hvor sikkerheden kommer fra sværhedsgraden af en diskret logaritme på en kurve snarere end i et stort endeligt felt.

ED beskriver en kurveform inde i den familie. Twisted Edwards-kurver er en repræsentation valgt for hastighed og for modstandsdygtighed over for flere implementeringsfejl, og Ed25519 er det navn, folk normalt mener. Kurven er ikke en konkurrent til kryptografi med elliptiske kurver; den er én måde at skrive en elliptisk kurve på. At læse ED som "den nyere, stærkere EC" er det første forkerte sving, og alt efter det er som regel forkert i samme retning.

Signering og udveksling er adskilte opgaver

Når familiespørgsmålet er afgjort, deler de resterende navne sig i to kolonner, der aldrig erstatter hinanden. Den ene kolonne signerer, den anden aftaler en fælles hemmelighed.

Både EdDSA og ECDSA signerer, men de er forskellige skemaer med forskellige nøgleformater, så et certifikat udstedt til det ene kan ikke bruges som det andet. EdDSA er defineret for et lille sæt kurver; P-256 er ikke en af dem, og derfor verificeres et P-256-certifikat med ECDSA og aldrig med Ed25519.

Udvekslingskolonnen har ingen ækvivalent, der hedder EdDH. Efemær aftale på en Curve25519-nøgle er X25519, og det er ECDH med en bestemt kurve, præcis som med P-256. Ed25519 betyder strengt taget signeringsskemaet, selv om navnet bruges løst om udvekslingen, fordi de to kurver er beslægtede: Edwards-formen, der bruges til signering, og Montgomery-formen, der bruges til X25519, beskriver den samme underliggende gruppe.

Hvorfor en EC-profil ikke har nogen dh-fil

En dh-fil indeholder forudgenererede parametre til Diffie-Hellman i et endeligt felt, og de parametre findes, fordi et stort primtal og en generator skal komme et sted fra. En elliptisk-kurve-udveksling har ikke brug for dem: den navngivne kurve er parametersættet, og begge sider kender den allerede. Det er hele grunden til, at en EC-profil kan udelade direktivet.

To situationer producerer stadig en dh-linje i en profil, der ellers ser moderne ud. Den første er en ekstra lytter eller en ældre peer, der reelt forhandler grupper i et endeligt felt. Den anden er resttekst kopieret fra en skabelon fra RSA-tiden og aldrig fjernet. En profil, der navngiver en kurve til udvekslingen og stadig indlæser en 2048-bit dh-fil, er ikke mere sikker af at have gjort det; den bærer et ubrugt artefakt.

TLS 1.3 fjernede nøgleudvekslingen fra navnet

Sammenlign TLS_AES_256_GCM_SHA384 med TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384, og det kortere navn ser ud som en nedgradering. Det er en omdøbning, og årsagen er strukturel: TLS 1.3 fjernede statisk RSA og Diffie-Hellman-nøgleudveksling i et endeligt felt, så en efemær elliptisk-kurve-udveksling er den eneste tilbageværende ikke-PSK-mulighed. At navngive den i hver suite ville gentage den samme kendsgerning et dusin gange.

Certifikattypen forsvandt fra navnet af en beslægtet grund. I 1.3 autentificerer certifikatet håndtrykkets signatur, ikke nøgleaftalen, så det vælger ikke længere suiten. Det er også derfor, der findes en separat chifferliste til 1.3 i konfigurationen: suiterne blev omdøbt og reorganiseret, ikke svækket.

En konsekvens er værd at sige rent ud. ECDHE er en nøgleudvekslingsalgoritme og aldrig en chiffer. En suite beskrevet som "elliptisk" siger noget om, hvordan de to peers nåede frem til en fælles nøgle, og intet om, hvad der derefter krypterer nyttelasten.

auth autentificerer pakker, ikke nyttelaster

Direktivet auth vælger den HMAC-kontrolsum, der autentificerer pakker, og dets historiske standardværdi er SHA1. Med en chiffer til data, der ikke er AEAD, beregner OpenVPN kontrolsummen over ciphertexten og tilføjer den, et krypter-derefter-MAC-arrangement, som er det, der gør manipulation med udfyldning upraktisk.

Myten her er, at det hærder tunnelen at hæve auth til SHA512. Det øger ikke krypteringens styrke, og hvis den forhandlede datachiffer er en AEAD-tilstand som AES-256-GCM, anvendes kontrolsummen slet ikke på datapakker. GCM-tagget autentificerer dem allerede, og auth-værdien er tilbage til kontrolkanalens HMAC og til enhver chiffer uden AEAD, der stadig bruges.

Så direktivet betyder noget, men det betyder noget på et smallere sted, end dets placering i filen antyder. At kontrollere, hvilken chiffer der faktisk blev forhandlet, fortæller dig, om det overhovedet gælder.

Læs profilen efter kolonne, ikke efter rang

Tre spørgsmål adskiller lagene rent, og hvert af dem besvares af en anden del af den forhandlede session. Hvilken chiffer beskytter nyttelasten? Hvilket tag eller hvilken kontrolsum garanterer for hver pakke, og kræver den anvendte chiffer overhovedet en? Hvis certifikat lukkede håndtrykket, og er kontrolkanalen desuden beskyttet af tls-auth eller tls-crypt?

Intet i EC- eller ED-mærket afgør nogen af de tre, og et suitenavn alene afgør heller ingen af dem. Det forhandlede resultat er det eneste bevis, så læs det i stedet for at udlede styrke af 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 kommando fortæller dig, hvilket signeringsskema dit certifikat faktisk bruger, og det er den eneste pålidelige måde at vide, om du kører ECDSA eller Ed25519. Den anden viser den kontrolkanallinje, klienten loggede for sessionen, inklusive TLS-versionen og den suite, den landede på. Hvis en profilændring ikke kan begrundes med et af de to output, er det sandsynligvis en ændring af et navn snarere end af en egenskab.