Kort svar
Perfect Forward Secrecy (PFS, også blot "forward secrecy") betyder at en kompromittering af serverens langtidsprivate nøgle ikke kan bruges til at dekryptere tidligere optaget trafik. Det opnås ved at hver forbindelse aftaler en unik, midlertidig (efemer) nøgle via Diffie-Hellman — typisk ECDHE — som kasseres bagefter og aldrig udledes af den private nøgle. I TLS 1.3 er forward secrecy obligatorisk; i TLS 1.2 skal det aktivt vælges.
Problemet uden forward secrecy
I den gamle, statiske RSA-key-exchange brugte klienten serverens offentlige nøgle til at kryptere den fælles hemmelighed. Det betyder at hele sessionens fortrolighed hviler på serverens private nøgle. Får en angriber fat i den nøgle — via et hack, en retskendelse eller en sårbarhed som Heartbleed — kan al tidligere optaget trafik dekrypteres bagudrettet. Dette kaldes et "harvest now, decrypt later"-angreb, og det er en reel trussel for langlivede private nøgler.
Hvordan efemer key exchange løser det
Med ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) genererer hver side et nyt, midlertidigt nøglepar for hver forbindelse. De udveksler de offentlige dele og beregner hver især den samme delte hemmelighed — uden at hemmeligheden nogensinde sendes, og uden at den afhænger af serverens langtidsnøgle. Når forbindelsen lukkes, kasseres de efemere nøgler. Serverens private nøgle bruges kun til at signere handshaken (bevise identitet), ikke til at beskytte hemmeligheden. Den fulde gennemgang af key exchange er i TLS handshake forklaret.
Statisk vs efemer key exchange
| Egenskab | Statisk RSA | ECDHE (efemer) |
|---|---|---|
| Nøgle pr. forbindelse | Samme private nøgle | Ny efemer nøgle |
| Forward secrecy | Nej | Ja |
| Lækket nøgle afslører gammel trafik | Ja | Nej |
Sådan sikrer du forward secrecy
Brug TLS 1.3 — alle dens cipher suites har forward secrecy som krav, så her er der intet at konfigurere. På TLS 1.2 skal du tillade ECDHE-ciphers og ikke de gamle statiske RSA-ciphers:
# nginx — kun ECDHE-baserede 1.2-ciphers (alle har forward secrecy) ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:\ ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305; ssl_prefer_server_ciphers off;
Cipher suites uden ECDHE (fx AES256-GCM-SHA384 uden præfiks) bruger statisk key exchange og har ikke forward secrecy. Hvad de enkelte dele af en cipher suite betyder forklarer vi i hvad er en cipher suite.
Verificér at en forbindelse har forward secrecy
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \ | grep -E "Protocol|Cipher"
Ser du TLSv1.3, har du altid forward secrecy. På 1.2 skal cipher-navnet indeholde ECDHE. Et navn uden ECDHE betyder at den specifikke forbindelse mangler forward secrecy.
Hvordan CertControl hjælper
Forward secrecy er let at miste ved en fejlkonfiguration — en enkelt server der stadig tilbyder statiske RSA-ciphers er nok. CertControl fremforhandler en rigtig handshake mod hvert endpoint, rapporterer den valgte cipher suite, og markerer endpoints der mangler forward secrecy, så I kan sikre det ensartet på tværs af hele jeres flade.
Ofte stillede spørgsmål
Hvad er "harvest now, decrypt later"?
Et angreb hvor man optager krypteret trafik i dag og gemmer den, i håbet om senere at få fat i nøglen — fx via et hack eller fremtidig regnekraft. Forward secrecy modvirker det, fordi hver session har en unik efemer nøgle der ikke kan udledes af den lækkede private nøgle.
Har TLS 1.3 altid forward secrecy?
Ja. Alle TLS 1.3-cipher suites kræver efemer key exchange, så enhver TLS 1.3-forbindelse har forward secrecy. Det var en bevidst designbeslutning at fjerne de statiske alternativer helt.
Hvad er forskellen på DHE og ECDHE?
Begge er efemere Diffie-Hellman og giver forward secrecy. ECDHE bruger elliptiske kurver, hvilket er hurtigere og kræver kortere nøgler for samme sikkerhed. ECDHE er i dag standardvalget.
Koster forward secrecy performance?
Marginalt, fordi der genereres et nyt nøglepar pr. forbindelse. Med ECDHE og moderne hardware er omkostningen ubetydelig og fuldt opvejet af sikkerhedsgevinsten. Session resumption mindsker det yderligere.
Hvordan ved jeg om min server mangler forward secrecy?
Hvis serveren tilbyder cipher suites uden ECDHE (eller DHE) i navnet, kan en forbindelse ende uden forward secrecy. Brug TLS 1.3 eller begræns 1.2 til kun ECDHE-ciphers for at garantere det.