OpenVPN EC vs ED: varför namnen inte är en styrkestege

Sätt ec, ed, ecdh, ecdsa, auth och en TLS-chifferlista sida vid sida i en profil, och filen börjar se ut som en styrkeregel med sex lägen. Men det är den inte. Varje namn svarar på en annan fråga, och två profiler som skiljer sig i ett av dem är inte nödvändigtvis starkare eller svagare än varandra. Att sortera namnen efter arbetet de utför tar ungefär fem minuter och förhindrar de flesta av de dåliga ändringar som folk gör i en fungerande konfiguration.

Sorteringen nedan börjar vid själva förvirringen och rör sig sedan utåt till de delar av en profil som faktiskt avgör vad som skyddar din trafik. Varje avsnitt tar en felläsning i taget och visar vad namnet egentligen hänger samman med.

Två bokstäver, två olika frågor

Paret som skapar mest debatt är EC och ED, och debatten antar vanligtvis att de är konkurrerande svar på en fråga. De ligger inte ens på samma axel. EC beskriver en matematisk familj: kryptografi med elliptiska kurvor, där säkerheten kommer från svårigheten med en diskret logaritm på en kurva snarare än i en stor ändlig kropp.

ED beskriver en kurvform inuti den familjen. Twisted Edwards-kurvor är en representation vald för hastighet och för motståndskraft mot flera implementeringsfel, och Ed25519 är namnet folk vanligtvis menar. Kurvan är inte en konkurrent till kryptografi med elliptiska kurvor; den är ett sätt att skriva en elliptisk kurva. Att läsa ED som "den nyare, starkare EC" är den första felaktiga svängen, och allt därefter är vanligtvis fel i samma riktning.

Signering och utbyte är separata uppgifter

När familjefrågan är avgjord delar sig de återstående namnen i två kolumner som aldrig ersätter varandra. Den ena kolumnen signerar, den andra enas om en delad hemlighet.

Både EdDSA och ECDSA signerar, men de är olika scheman med olika nyckelformat, så ett certifikat som utfärdats för det ena kan inte användas som det andra. EdDSA är definierat för en liten uppsättning kurvor; P-256 är inte en av dem, vilket är varför ett P-256-certifikat verifieras med ECDSA och aldrig med Ed25519.

Utbyteskolumnen har ingen motsvarighet som heter EdDH. Efemär överenskommelse på en Curve25519-nyckel är X25519, och det är ECDH med en viss kurva, precis som med P-256. Ed25519 betyder strikt signeringsschemat, även om namnet används löst för utbytet eftersom de två kurvorna är besläktade: Edwards-formen som används för signering och Montgomery-formen som används för X25519 beskriver samma underliggande grupp.

Varför en EC-profil inte har någon dh-fil

En dh-fil innehåller förgenererade parametrar för Diffie-Hellman i en ändlig kropp, och de parametrarna finns eftersom ett stort primtal och en generator måste komma någonstans ifrån. Ett utbyte på en elliptisk kurva behöver dem inte: den namngivna kurvan är parameteruppsättningen, och båda sidor känner redan till den. Det är hela anledningen till att en EC-profil kan utelämna direktivet.

Två situationer producerar fortfarande en dh-rad i en profil som annars ser modern ut. Den första är en extra lyssnare eller en äldre peer som faktiskt förhandlar grupper i en ändlig kropp. Den andra är kvarbliven text kopierad från en mall från RSA-eran och aldrig borttagen. En profil som namnger en kurva för utbytet och fortfarande läser in en 2048-bitars dh-fil är inte säkrare för att den gjorde det; den bär på en oanvänd artefakt.

TLS 1.3 tog bort nyckelutbytet från namnet

Jämför TLS_AES_256_GCM_SHA384 med TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 och det kortare namnet ser ut som en nedgradering. Det är en namnändring, och anledningen är strukturell: TLS 1.3 tog bort statisk RSA och Diffie-Hellman-nyckelutbyte i en ändlig kropp, så ett efemärt utbyte på en elliptisk kurva är det enda kvarvarande icke-PSK-alternativet. Att namnge det i varje svit skulle upprepa samma faktum ett dussin gånger.

Certifikattypen försvann från namnet av en besläktad anledning. I 1.3 autentiserar certifikatet handskakningens signatur, inte nyckelöverenskommelsen, så det väljer inte längre sviten. Det är också därför det finns en separat chifferlista för 1.3 i konfigurationen: sviterna döptes om och omorganiserades, inte försvagades.

En konsekvens är värd att sägas rakt ut. ECDHE är en nyckelutbytesalgoritm och aldrig ett chiffer. En svit som beskrivs som "elliptisk" säger något om hur de två parterna kom fram till en delad nyckel, och ingenting om vad som därefter krypterar nyttolasten.

auth autentiserar paket, inte nyttolasten

Direktivet auth väljer den HMAC-sammandragning som autentiserar paketen, och dess historiska standardvärde är SHA1. Med ett datachiffer som inte är AEAD beräknar OpenVPN sammandragningen över chiffertexten och lägger till den, ett kryptera-därefter-MAC-arrangemang som är det som gör manipulation av utfyllnaden opraktisk.

Myten här är att det härdar tunneln att höja auth till SHA512. Det ökar inte krypteringens styrka, och om det förhandlade datachiffret är ett AEAD-läge som AES-256-GCM tillämpas sammandragningen inte alls på datapaket. GCM-taggen autentiserar dem redan, och auth-värdet återstår för HMAC för kontrollkanalen och för varje chiffer utan AEAD som fortfarande används.

Så direktivet spelar roll, men det spelar roll på en smalare plats än dess placering i filen antyder. Att kontrollera vilket chiffer som faktiskt förhandlades säger dig om det ens gäller.

Läs profilen efter kolumn, inte efter rang

Tre frågor skiljer lagren rent, och var och en besvaras av en annan del av den förhandlade sessionen. Vilket chiffer skyddar nyttolasten? Vilken tagg eller sammandragning garanterar för varje paket, och behöver chiffret som används ens en sådan? Vems certifikat stängde handskakningen, och är kontrollkanalen dessutom skyddad av tls-auth eller tls-crypt?

Ingenting i EC- eller ED-etiketten avgör någon av de tre, och ett svitnamn ensamt avgör inte heller någon av dem. Det förhandlade resultatet är det enda beviset, så läs det i stället för att sluta dig till styrkan från ordförrådet:

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

Det första kommandot berättar vilket signeringsschema ditt certifikat faktiskt använder, och det är det enda tillförlitliga sättet att veta om du kör ECDSA eller Ed25519. Det andra visar den kontrollkanalrad som klienten loggade för sessionen, inklusive TLS-versionen och den svit den landade på. Om en profiländring inte kan motiveras av någon av dessa två utskrifter är det förmodligen en ändring av ett namn och inte av en egenskap.