Was ist Forward Secrecy (Perfect Forward Secrecy)?

Forward Secrecy (auch Perfect Forward Secrecy / PFS genannt) ist eine Eigenschaft einer TLS-Verbindung, die garantiert: Selbst wenn der private Schluessel des Servers in der Zukunft kompromittiert wird, koennen vergangene verschluesselte Kommunikationen nicht entschluesselt werden.

Es funktioniert, indem fuer jede Verbindung ein einzigartiger, ephemerer Schluessel erzeugt wird. Nach dem Ende der Verbindung wird der ephemere Schluessel verworfen. Niemand — nicht einmal der Serverbetreiber — kann ihn wiederherstellen.

Warum Forward Secrecy wichtig ist

Ohne Forward Secrecy (RSA-Schluesselaustausch)

Angreifer zeichnet heute verschluesselten Traffic auf
     ↓
Jahre spaeter stiehlt der Angreifer den privaten RSA-Schluessel des Servers
     ↓
Angreifer entschluesselt GESAMTEN aufgezeichneten Traffic -- Passwoerter, Nachrichten, alles

Mit statischem RSA-Schluesselaustausch (TLS 1.2 ohne ECDHE) wird derselbe private Serverschluessel zum Entschluesseln jeder Sitzung verwendet. Wenn dieser Schluessel jemals gestohlen wird, ist jede vergangene Konversation offengelegt.

Mit Forward Secrecy (ECDHE-Schluesselaustausch)

Angreifer zeichnet heute verschluesselten Traffic auf
     ↓
Jahre spaeter stiehlt der Angreifer den privaten Schluessel des Servers
     ↓
Kann vergangenen Traffic nicht entschluesseln -- jede Sitzung verwendete einen einzigartigen
ephemeren Schluessel, der nach der Sitzung verworfen wurde

Jede Verbindung erzeugt ein frisches Diffie-Hellman-Schluesselpaar, berechnet einen einzigartigen Sitzungsschluessel und vernichtet den ephemeren Schluessel nach Abschluss. Der langfristige private Schluessel des Servers wird nur zur Authentifizierung (Identitaetsnachweis) verwendet, nicht zum Schluesselaustausch (Ableitung des Verschluesselungsschluessels).

Wie es technisch funktioniert

1. Client und Server erzeugen jeweils ein ephemeres ECDHE-Schluesselpaar (zufaellig, pro Verbindung)
2. Sie tauschen die oeffentlichen Haelften dieser ephemeren Schluessel aus
3. Beide berechnen das gleiche gemeinsame Geheimnis unter Verwendung ihres eigenen privaten ephemeren Schluessels + des oeffentlichen ephemeren Schluessels des anderen (das ist die Diffie-Hellman-Mathematik)
4. Das gemeinsame Geheimnis leitet den Sitzungsschluessel ab, der fuer die AES-Verschluesselung verwendet wird
5. Ephemere Schluessel werden verworfen, nachdem der Sitzungsschluessel abgeleitet wurde

Der private Zertifikatsschluessel des Servers wird nur zum Signieren der Handshake-Nachrichten verwendet — um zu beweisen, dass der Server echt ist. Er wird niemals zum Entschluesseln von Traffic verwendet.

Forward Secrecy in TLS-Versionen

TLS 1.3 hat dies geloest, indem es den RSA-Schluesselaustausch entfernt hat — alle TLS 1.3-Verbindungen haben standardmaessig Forward Secrecy. Keine Konfiguration erforderlich.

Wie Sie pruefen, ob Ihr Server Forward Secrecy hat

# Pruefen, welchen Schluesselaustausch Ihr Server verwendet
echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | grep -E "Server Temp Key|Protocol"

Achten Sie auf:

• Server Temp Key: ECDH, P-256 → ✅ Forward Secrecy (ECDHE)
• Server Temp Key: X25519 → ✅ Forward Secrecy
• Keine Server Temp Key-Zeile → ❌ RSA-Schluesselaustausch, kein Forward Secrecy

Forward Secrecy in TLS 1.2 sicherstellen

Nginx:

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;

Alle Cipher Suites beginnen mit ECDHE — ephemerer Schluesselaustausch.

Apache:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder off

Relevanz in der Praxis

Forward Secrecy schuetzt vor:

• Staatlicher Ueberwachung — Regierungen, die jetzt verschluesselten Traffic aufzeichnen und hoffen, ihn spaeter zu entschluesseln, wenn sie Schluessel erlangen (durch gerichtliche Anordnungen, Hacking oder Quantencomputing)
• Server-Kompromittierung — wenn ein Angreifer den privaten Schluessel Ihres Servers stiehlt, kann er den Server nur kuenftig imitieren, aber vergangenen Traffic nicht entschluesseln
• Schluessel-Leaks — versehentliche Offenlegung privater Schluessel (z. B. in Git committed, in einem Backup enthalten)

Deshalb empfiehlt Let’s Encrypt ECDSA-Zertifikate — sie passen natuerlich zum ECDHE-Schluesselaustausch fuer einen vollstaendig auf elliptischen Kurven basierenden Handshake.

Haeufig gestellte Fragen

Muss mein SSL-Zertifikat Forward Secrecy unterstuetzen?

Das Zertifikat selbst bestimmt nicht die Forward Secrecy — die Cipher Suite tut das. Jedes Zertifikat (RSA oder ECDSA) funktioniert mit ECDHE-Schluesselaustausch. Aber ECDSA-Zertifikate passen natuerlicher zu ECDHE (beide verwenden elliptische Kurven), was zu einem schnelleren Handshake fuehrt.

Ist Forward Secrecy standardmaessig aktiviert?

In TLS 1.3: immer — es ist obligatorisch. In TLS 1.2: abhaengig von Ihrer Serverkonfiguration. Moderne Standards (Nginx, Apache) bevorzugen ECDHE-Cipher-Suites, aber aeltere Konfigurationen erlauben moeglicherweise noch RSA-Schluesselaustausch.

Verlangsamt Forward Secrecy die Verbindung?

Vernachlaessigbar. ECDHE-Schluesselaustausch fuegt auf moderner Hardware ~1 ms zum Handshake hinzu. Der Sicherheitsvorteil ueberwiegt die Kosten bei weitem.

Was ist mit dem 0-RTT-Modus in TLS 1.3?

0-RTT (Zero Round Trip Resumption) ist ein Sonderfall. Die fruehen Daten, die in 0-RTT gesendet werden, haben keine Forward Secrecy gegen eine Server-Kompromittierung (der PSK, der fuer die Wiederaufnahme verwendet wird, wird aus den Schluesseln der vorherigen Sitzung abgeleitet). Deshalb sollte 0-RTT nur fuer sichere, idempotente Anfragen verwendet werden.