Kort svar
Diffie-Hellman er en metode hvor to parter hver vælger en hemmelig værdi, udveksler offentlige værdier afledt af dem, og uafhængigt regner sig frem til samme delte hemmelighed — uden nogensinde at sende selve hemmeligheden. En aflytter ser kun de offentlige værdier og kan ikke udlede den delte nøgle. ECDHE er den ephemerale, elliptisk-kurve-baserede variant, og fordi nøglen er ny for hver session, giver den forward secrecy.
Analogien med malingen
Den klassiske forklaring: Alice og Bob bliver enige om en fælles farve (offentlig). Hver blander hemmeligt sin egen farve i. De udveksler de blandede farver — en aflytter ser dem, men kan ikke "trække" de hemmelige farver ud igen. Til sidst blander hver sin egen hemmelige farve i den andens blanding, og begge ender med præcis samme endelige farve. Den farve er den delte nøgle, og aflytteren kan ikke gendanne den. Matematisk er "blanding" modulær eksponentiation (klassisk DH) eller punkt-multiplikation på en elliptisk kurve (ECDHE).
Hvorfor ephemeral er afgørende: forward secrecy
Det centrale bogstav er E i ECDHE — ephemeral. Det betyder at de hemmelige værdier kun bruges til én session og derefter kasseres. Konsekvensen er forward secrecy: selv hvis en angriber optager al din krypterede trafik i dag og senere stjæler serverens private nøgle, kan han stadig ikke dekryptere den optagede trafik. Hver sessions nøgle er væk for altid.
Sammenlign med den gamle statiske RSA-nøgleudveksling (uden DH), hvor sessionsnøglen blev krypteret med serverens langtidsnøgle. Lækkede den nøgle nogensinde, kunne al tidligere optaget trafik dekrypteres med tilbagevirkende kraft. Derfor fjernede TLS 1.3 statisk RSA-nøgleudveksling helt — forward secrecy er nu obligatorisk.
Genkend det i cipher suite-navnet
ECDHE-RSA-AES256-GCM-SHA384 └──┬──┘ └┬┘ │ └─ RSA = serveren autentificerer med sit RSA-certifikat └─────── ECDHE = key exchange er ephemeral ECDH → forward secrecy
Bemærk: ECDHE (key exchange) og RSA (authentication) er to uafhængige roller. RSA beviser serverens identitet; ECDHE laver den delte nøgle. En suite uden ECDHE/DHE — fx en ren RSA-nøgleudveksling — mangler forward secrecy. Se hele opbygningen i hvad er en cipher suite.
DHE vs ECDHE
| DHE (klassisk) | ECDHE (elliptisk kurve) | |
|---|---|---|
| Matematik | Modulær eksponentiation | Elliptiske kurver |
| Ydeevne | Langsommere | Hurtigere |
| Nøglestørrelse for ~128-bit | 3072-bit | 256-bit (P-256) |
| Forward secrecy | Ja | Ja |
| Anbefaling | Fallback | Foretrukket |
Den vigtige begrænsning: DH beskytter ikke mod man-in-the-middle
Diffie-Hellman alene beskytter mod en passiv aflytter, men ikke mod en aktiv angriber der sidder i midten. Hvis ingen beviser hvem de taler med, kan en angriber lave én DH-udveksling med klienten og en anden med serveren og dermed sidde imellem og læse alt. Det er præcis derfor authentication-delen af cipher suite (RSA eller ECDSA) er nødvendig: serverens certifikat beviser at den DH-værdi klienten modtager, faktisk kom fra den rigtige server og ikke fra en angriber. Key exchange og authentication løser to forskellige problemer, og du har brug for begge.
Hvorfor TLS 1.3-handshaken er hurtigere
I TLS 1.2 sker ECDHE-udvekslingen efter at klienten har set serverens valg, hvilket koster en ekstra rundtur. TLS 1.3 lader klienten gætte serverens foretrukne gruppe og sende sin ECDHE-værdi allerede i den første besked. Gætter den rigtigt — hvad den næsten altid gør, typisk X25519 — er nøgleudvekslingen færdig efter én rundtur i stedet for to. Det er en stor del af hvorfor TLS 1.3-forbindelser føles hurtigere, og det ændrer intet ved sikkerheden: nøglen er stadig ephemeral og giver stadig forward secrecy.
Bekræft at en server bruger ECDHE
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \ | grep -E "Cipher|Server Temp Key"
Server Temp Key: X25519 eller ECDH, P-256 bekræfter at forbindelsen brugte ephemeral ECDHE og dermed har forward secrecy. Bemærk: X25519 er en moderne, meget anvendt kurve specifikt til ECDHE-nøgleudveksling.
Sådan ser CertControl efter manglende forward secrecy
En server kan se sikker ud men stadig tilbyde en suite uden ECDHE som fallback — og så mister enhver klient der rammer den fallback forward secrecy. CertControl registrerer key exchange-metoden per endpoint og markerer servere der stadig accepterer ikke-ephemeral nøgleudveksling, så I kan lukke hullet. Forhandlingen sker i TLS-handshaken, og fejler den, hjælper vores guide til handshake-fejl.
Ofte stillede spørgsmål
Hvad er forward secrecy i praksis?
Det er garantien for at gammel optaget trafik forbliver hemmelig, selv hvis serverens private nøgle senere lækker. Hver session bruger en ny, midlertidig nøgle der kasseres bagefter, så der er ingen langtidsnøgle der kan låse fortiden op.
Hvad er forskellen på DH og DHE?
DHE er den ephemerale variant af Diffie-Hellman — en ny nøgle per session. Ren DH med statiske nøgler giver ikke forward secrecy. I praksis bør du altid bruge den ephemerale variant, og i TLS er det ECDHE.
Beviser ECDHE serverens identitet?
Nej. ECDHE laver kun den delte nøgle. Serverens identitet bevises separat af certifikatets signatur — RSA- eller ECDSA-delen af cipher suite. De to roller er adskilte.
Hvad er X25519?
X25519 er en moderne elliptisk kurve optimeret specifikt til ECDHE-nøgleudveksling. Den er hurtig, sikker og bredt udbredt i TLS 1.3, og den ses ofte i "Server Temp Key"-linjen.
Bruger TLS 1.3 altid forward secrecy?
Ja. TLS 1.3 fjernede statisk RSA-nøgleudveksling helt, så al key exchange er ephemeral (ECDHE eller DHE). Forward secrecy er dermed obligatorisk i enhver TLS 1.3-forbindelse.