Alles, was Sie über Perfect Forward Secrecy wissen müssen

Veröffentlicht: 27. September 2023. Aktualisiert: August 2026. Geprüft vom Kryptografie-Beratungsteam von Encryption Consulting.

Die meisten Erklärungen zu Perfect Forward Secrecy (PFS) beschränken sich auf die Definition: Temporäre Schlüssel werden nach Gebrauch verworfen, vergangene Sitzungen bleiben sicher. Das stimmt zwar, ist aber nicht der entscheidende Punkt, wenn es um die Konfiguration eines Produktionsservers im Jahr 2026 geht. Die eigentlichen Fragen lauten: Welcher Schlüsselaustausch ist erforderlich? Welche Verschlüsselungskurve ist die richtige? Welche Auswirkungen hat dies auf die Performance und Client-Kompatibilität? Und wovor bietet PFS tatsächlich keinen Schutz? Dieser Beitrag beantwortet diese Fragen direkt. Als Grundlage dienen die aktuelle TLS-1.3-Spezifikation ( RFC 8446 ) und die aktuellen NIST-Kurvenempfehlungen. Anstelle einer allgemeinen Übersicht gibt er unsere konkrete Empfehlung. Die Grundlagen der Benennung und Struktur von Cipher Suites finden Sie in unserem Begleitbeitrag „ Einführung in Cipher Suites “. Dieser Beitrag konzentriert sich auf die einzige Eigenschaft dieser Suites, die Forward Secrecy, die darüber entscheidet, ob Ihr vergangener Datenverkehr vertraulich bleibt.

Was ist perfekte Vorwärtsgeheimhaltung und vor welcher Bedrohung schützt sie tatsächlich?

Perfect Forward Secrecy (PFS), auch Forward Secrecy genannt, ist eine Eigenschaft eines Schlüsselaustauschprotokolls, die garantiert, dass die Kompromittierung eines langfristigen privaten Schlüssels zu einem späteren Zeitpunkt nicht zur Entschlüsselung des in der Vergangenheit aufgezeichneten Sitzungsverkehrs verwendet werden kann. Jede TLS-Sitzung handelt ihr eigenes ephemeres (kurzlebiges, einmalig verwendbares) Schlüsselpaar mittels Diffie-Hellman (DHE) oder Elliptic Curve Diffie-Hellman (ECDHE) aus, leitet daraus einen Sitzungsschlüssel ab und verwirft anschließend den ephemeren privaten Schlüssel. Das langfristige Zertifikatsschlüsselpaar des Servers wird ausschließlich zur Authentifizierung des Austauschs (Signatur) verwendet und niemals zur direkten Verschlüsselung der Sitzungsdaten.

PFS schützt vor zwei spezifischen und recht unterschiedlichen Szenarien:

1. Jetzt ernten, später entschlüsseln (HNDL).

   Ein Angreifer, der heute verschlüsselten Datenverkehr aufzeichnen kann, geht davon aus, dass er diesen später mithilfe einer zukünftigen Technologie (z. B. eines gestohlenen Schlüssels, eines kryptanalytischen Fortschritts oder eines kryptografisch relevanten Quantencomputers) entschlüsseln kann. Ohne PFS würde die Kompromittierung eines statischen Schlüssels in einigen Jahren rückwirkend alle jemals damit verschlüsselten Sitzungen offenlegen. Mit PFS hingegen bleibt der gespeicherte Datenverkehr unwiederbringlich verloren, da die sitzungsspezifischen Schlüssel nie gespeichert wurden und nachträglich nicht rekonstruiert werden können.

2. Verzögerte Schlüsselkompromittierung.

   Der private Schlüssel eines Servers wird erst später offengelegt, beispielsweise durch einen Sicherheitsverstoß, eine Fehlkonfiguration, Insider-Handlungen oder einen Fehler im Schlüsselmanagement, und nicht zum Zeitpunkt der Sitzung. PFS stellt sicher, dass die Offenlegung nur Sitzungen gefährdet, die nach der Kompromittierung ausgehandelt wurden (bis der Schlüssel rotiert und widerrufen wird), nicht aber den jahrelangen Datenverkehr davor.

Beide Szenarien sind aus demselben Grund relevant: Verschlüsselte Daten, die heute wertvoll sind, sind in der Regel auch in fünf oder zehn Jahren noch lesenswert. Finanzdaten, Gesundheitsdaten, Regierungskommunikation und langfristiges geistiges Eigentum zählen zu den Kategorien, die in HNDL-Bedrohungsmodellen am häufigsten genannt werden. Genau in diesen Kategorien führt eine Architektur ohne PFS dazu, dass ein zukünftiges Schlüsselleck rückwirkend einen Datenverlust über ein ganzes Jahrzehnt hinweg verursacht.

Wie funktioniert PFS eigentlich? ECDHE vs. DHE

Direkte Antwort: Sowohl ECDHE als auch DHE erzeugen pro Sitzung ein neues, kurzlebiges Schlüsselpaar und leiten daraus ein gemeinsames Geheimnis ab, das niemals auf der Festplatte oder im Langzeitspeicher abgelegt wird. Sie unterscheiden sich jedoch wesentlich in der Leistung, der Schlüssellänge und den gewählten Kurven- oder Gruppenparametern.

ECDHE (Elliptic Curve Diffie-Hellman Ephemeral)

ECDHE führt den Diffie-Hellman-Austausch über einer elliptischen Kurvengruppe anstelle eines endlichen Körpers durch. Da diskrete Logarithmusprobleme auf elliptischen Kurven pro Bit schwieriger sind als solche in endlichen Körpern, erreicht ECDHE ein gleichwertiges Sicherheitsniveau mit deutlich kleineren Schlüsseln. Dies bedeutet eine schnellere Schlüsselgenerierung und einen kürzeren Handshake. Aus diesem Grund ist ECDHE die Standardempfehlung für praktisch alle modernen TLS-Implementierungen. RFC 8446 fordert daher, dass TLS-1.3-Implementierungen die P-256-Kurve für den Schlüsselaustausch unterstützen, wobei X25519 eine weit verbreitete und leistungsstarke Alternative darstellt. Kurvenwahl für ECDHE im Jahr 2026:

• X25519 (Curve25519) ist schnell, von Grund auf zeitkonstant (resistent gegen gängige Timing-Seitenkanalangriffe) und die am weitesten verbreitete Kurve in modernen Browsern und TLS-Bibliotheken. Wir empfehlen sie standardmäßig für öffentlich zugängliche TLS-1.3-Endpunkte, bei denen die FIPS-Validierung der spezifischen Kurve keine vertragliche Anforderung darstellt. Anfang 2026 kündigte das NIST an, ECC-Verfahren wie X25519, die ausschließlich die x-Koordinate berücksichtigen, in eine zukünftige Revision von SP 800-56A aufzunehmen. Da X25519 in dieser Publikation jedoch noch nicht formell als Kurve anerkannt ist, sollten FIPS-konforme Systeme sie derzeit nicht verwenden.

• P-256 (secp256r1). Die NIST-Kurve mit der breitesten formalen Anerkennung (SP 800-56A, SP 800-186) und die gemäß RFC 8446 obligatorisch zu implementierende Kurve für den TLS-1.3-Schlüsselaustausch. Verwenden Sie sie, wenn FIPS-140-validierte Kryptografie eine Compliance-Anforderung ist oder wenn Sie garantierte Interoperabilität mit älteren oder behördlich vorgeschriebenen Client-Stacks benötigen.

• P-384 (secp384r1). Höhere Sicherheitsmarge, größere Schlüssel, messbar langsamer als P-256 oder X25519. Verwenden Sie es nur für Verbindungen, die eine Vertrauensbasis von P-384 oder höher erfordern, oder für Umgebungen mit expliziten Anforderungen an hohe Sicherheit, anstatt es standardmäßig einzusetzen.

DHE (Diffie-Hellman Ephemeral)

DHE führt denselben kurzlebigen Schlüsselaustausch über einer Gruppe in einem endlichen Körper anstelle einer elliptischen Kurve durch und benötigt einen großen Modulus, üblicherweise 2048 Bit oder mehr gemäß aktueller Richtlinien, um ein vergleichbares Sicherheitsniveau zu erreichen. Dieser größere Modulus macht die DHE-Schlüsselerzeugung und den Handshake selbst deutlich rechenintensiver als ECDHE bei gleicher Stärke. DHE fehlt daher vollständig in der Liste der TLS-1.3-Verschlüsselungssuiten (der TLS-1.3-Schlüsselaustausch erfolgt über ECDHE oder einen vorab vereinbarten Schlüssel, nicht über DHE in einem endlichen Körper). DHE findet sich weiterhin in TLS-1.2-Implementierungen und in einigen älteren oder regulatorisch bedingten Umgebungen. Unsere Empfehlung: Verwenden Sie DHE nicht für neue Implementierungen. Unterstützen Sie es, wenn überhaupt, nur als Kompatibilitäts-Fallback für TLS-1.2-Clients, die ECDHE nicht aushandeln können, und planen Sie, es zu entfernen, sobald diese Clients nicht mehr unterstützt werden.

So überprüfen und aktivieren Sie PFS auf Ihrem Server

Direkte Antwort: Stellen Sie sicher, dass Sie TLS 1.3 (oder TLS 1.2 mit ausschließlich ECDHE-Verschlüsselungssuiten) verwenden, entfernen Sie alle Verschlüsselungssuiten, die statischen RSA- oder statischen (EC)DH-Schlüsselaustausch durchführen, und überprüfen Sie den ausgehandelten Schlüsselaustausch mit einem Handshake-Inspektionstool. Konkret:

1. Bitte überprüfen Sie Ihre Protokollversion. TLS 1.3 verfügt über integrierte Vorwärtsgeheimhaltung und kann keinen nicht-ephemeren Schlüsselaustausch aushandeln. Daher ist die Aktivierung von TLS 1.3 und dessen Bevorzugung gegenüber TLS 1.2 der wichtigste Schritt. Falls TLS 1.2 weiterhin für ältere Clients unterstützt werden muss, ist eine explizite Richtlinie für Verschlüsselungssuiten erforderlich (nächster Schritt), da TLS 1.2 auch Verschlüsselungssuiten ohne Vorwärtsgeheimhaltung aushandeln kann, sofern diese nicht ausgeschlossen werden.

2. Entfernen Sie statische Schlüsselaustausch-Verschlüsselungssuiten. Jeder TLS 1.2-Verschlüsselungssuite-Name, der Klartext enthält RSA or DH ohne eine E (ephemerer) Qualifikator, zum Beispiel TLS_RSA_WITH_AES_256_CBC_SHA, führt einen statischen Schlüsselaustausch durch und verfügt über keine Vorwärtsgeheimhaltung. Nur ECDHE_* Suiten und DHE_* Suiten ausschließlich als dokumentierte, vorübergehende Ausweichlösung.

3. Legen Sie eine explizite Kurven-/Gruppenpräferenz fest. Konfigurieren Sie Ihre Liste der unterstützten Gruppen so, dass X25519 und P-256 bevorzugt werden (fügen Sie P-384 nur hinzu, wenn dies aufgrund spezifischer Compliance- oder Root-of-Trust-Anforderungen erforderlich ist), damit der Server nicht versehentlich auf eine schwächere oder langsamere Option zurückgreift.

4. Testen Sie die Live-Aushandlung, nicht nur die Konfigurationsdatei. Eine Konfigurationsdatei beschreibt die Absicht; nur ein Live-Handshake beweist, was ein Client tatsächlich aushandelt. Zwei konkrete Prüfungen:

   openssl s_client -connect yourdomain.com:443 -tls1_3 bestätigt den erfolgreichen Abschluss eines TLS 1.3-Handshakes, und die Sitzungsausgabe zeigt die ausgehandelte Gruppe an.

   openssl ciphers -v 'ECDHE' listet die ECDHE-Suites auf, die Ihr lokaler OpenSSL-Build unterstützt; dies ist nützlich, um zu bestätigen, was Ihre serverseitige Bibliothek leisten kann.

   Für einen umfassenderen, nicht authentifizierten Überblick darüber, was ein Server realen Clients anbietet, ist ein externer TLS-Scanner (Qualys SSL Labs oder ein ähnliches Tool) der schnellste Weg, die vollständige Liste der ausgehandelten Verschlüsselungsalgorithmen und Kurven von außerhalb Ihres Netzwerks einzusehen.

5. Führen Sie nach jeder Zertifikats- oder Load-Balancer-Änderung einen erneuten Test durch. Verschlüsselungs- und Protokolleinstellungen werden bei einer Load-Balancer-Migration, der Integration einer WAF oder einer CDN-Konfigurationsänderung häufig auf die Standardeinstellungen des Herstellers zurückgesetzt. Behandeln Sie die Handshake-Prüfung in Schritt 4 als obligatorischen Bestandteil dieses Änderungsprozesses und nicht als einmaligen Prüfpunkt.

Speziell für nginx sind dies die folgenden Einstellungen: ssl_protocols (TLSv1.3 einschließen, TLSv1.2 nur, falls noch erforderlich), ssl_ciphers (eine explizite Liste ausschließlich für ECDHE als Fallback-Pfad für TLS 1.2), ssl_ecdh_curve (die geordnete Kurvenpräferenz, zum Beispiel X25519 gefolgt von P-256), und ssl_prefer_server_ciphers (Die Reihenfolge richtet sich nach Ihren Vorgaben, nicht nach denen des Clients.) Wir beschreiben diese Direktiven konzeptionell, anstatt einen ungeprüften Codeausschnitt Zeile für Zeile einzufügen, da die genaue Syntax je nach nginx- und OpenSSL-Version variiert und ein leicht fehlerhaftes Konfigurationsbeispiel schlimmer ist als gar kein Beispiel. Überprüfen Sie die Syntax der jeweiligen Direktive vor der Bereitstellung anhand Ihrer installierten nginx- und OpenSSL-Version und bestätigen Sie das Ergebnis anschließend mit den OpenSSL- und Scannerprüfungen aus Schritt 4.

Abwägungen zwischen Leistung und Interoperabilität

PFS ist nicht kostenlos, und die Annahme, dies sei nicht kostenlos, ist der Grund, warum manche Teams zu wenig in die korrekte Konfiguration investieren. Die Kosten sind zwar real, aber gering und für praktisch jede Arbeitslast überschaubar.

• Die Kosten für die Generierung temporärer Schlüssel müssen berechnet werden. Jede Sitzung generiert ein neues Schlüsselpaar anstatt eines gespeicherten Schlüssels wiederzuverwenden, was den CPU-Aufwand bei jedem Handshake erhöht. Auf moderner Hardware mit ECDHE und X25519 oder P-256 sind diese Kosten für die überwiegende Mehrheit der Implementierungen so gering, dass sie keine Rolle spielen. Sie werden erst bei sehr hohen Verbindungsaufbauraten (große Flotten kurzlebiger Verbindungen, API-Gateways mit hohem Durchsatz) zu einem relevanten Faktor in der Kapazitätsplanung. In diesen Fällen ist die Sitzungswiederaufnahme (TLS 1.3 PSK-basierte Wiederaufnahme) die Standardlösung, ohne PFS aufzugeben.

• Inkompatibilität mit älteren Clients. Sehr alte TLS-Stacks (ältere eingebettete Geräte, ungepatchte ältere Browser, einige veraltete API-Clients) unterstützen ECDHE möglicherweise gar nicht oder nur mit einer eingeschränkten Liste von Verschlüsselungsfunktionen. Die Erzwingung von ausschließlich ECDHE-Verschlüsselungssuiten kann die Verbindung für diese Minderheit von Clients unterbrechen. Dies ist ein bewusster und dokumentierter Kompromiss, kein Versehen: Der Sicherheitsvorteil von Forward Secrecy für die Mehrheit überwiegt die fortgesetzte Unterstützung von Clients, die aus anderen Gründen bereits ein Sicherheitsrisiko darstellen (schwache Protokollversionen, ungepatchte Schwachstellen).

• Der höhere Modulus von DHE ist ein weiterer Nachteil. Wenn DHE als Ausweichlösung beibehalten werden muss, führt der 2048-Bit- oder größere Modulus für endliche Körper zu messbar langsameren Handshakes als bei ECDHE. Dies ist ein weiterer Grund, DHE eher als eine zeitlich begrenzte, eingeschränkte Lösung denn als parallele Langzeitoption zu betrachten.

Schlüsselaustauschvergleich: ECDHE vs. DHE vs. statisches RSA

Eigenschaft	ECDHE	DHE	Statischer RSA-Schlüsselaustausch
Vorwärtsgeheimnis	Ja	Ja	Nein
Relative Leistung	Schnellste	Langsamer (großer Modul)	Schnell, aber von Grund auf unsicher.
Unterstützt in TLS 1.3	Ja, erforderlich	Nein (entfernt)	Nein (entfernt)
Typische Parameter (2026)	X25519, P-256, P-384	2048-Bit- oder größere endliche Körpergruppe	Das langfristige RSA-Schlüsselpaar des Servers wird sitzungsübergreifend wiederverwendet.
Empfohlene Anwendung heute	Standardeinstellung für alle neuen Bereitstellungen	Nur dokumentierte Legacy-Fallback-Lösung	Keine; überall deaktivieren

Unternehmensentscheidungstabelle: Zuordnung von Konfiguration und Bereitstellung

Einsatzszenario	Empfohlene Konfiguration
Öffentlich zugänglicher Web- oder API-Endpunkt, breite Kundenbasis	TLS 1.3 bevorzugt, TLS 1.2 als Fallback auf ECDHE-Suites beschränkt; Kurvenpräferenz X25519, dann P-256; DHE- und statische RSA-Suites vollständig abschaffen
Interner Dienst-zu-Dienst-Verkehr oder mTLS zwischen eigenen Systemen	TLS 1.3 nur dann, wenn jeder Endpunkt unter Ihrer Kontrolle steht; P-256 oder P-384, wenn die Umgebung innerhalb der von NIST genehmigten Kurvengrenzen bleiben muss; kein Legacy-Fallback erforderlich
FIPS 140-validierte oder behördlich vorgeschriebene Umgebung	P-256 (verpflichtend umzusetzen, SP 800-56A/186 genehmigt) als Standardkurve; X25519 ist bis zur formellen Aufnahme in SP 800-56A noch nicht verwendbar; P-384, wenn ein höheres Sicherheitsniveau separat erforderlich ist.
Legacy- oder eingebettete Clients, die nicht über ECDHE verhandeln können	Isolieren Sie diesen Datenverkehr auf einen abgegrenzten, überwachten Ausweichpfad mit DHE (2048 Bit oder größer), anstatt die primäre Konfiguration zu schwächen; legen Sie ein explizites Abschaltdatum für diesen Pfad fest.
Dienste mit hohem Durchsatz und hoher Verbindungsrate (große API-Gateways, CDNs)	ECDHE mit X25519 oder P-256 plus TLS 1.3 Session Resumption (PSK-basiert) zur Amortisierung der Kosten für die Generierung temporärer Schlüssel, ohne die Vorwärtsgeheimhaltung aufzugeben

Einschränkungen: Wovor PFS nicht schützt

PFS wird häufig fälschlicherweise als allgemeine Sicherheitsgarantie angepriesen. Das ist es nicht. Es schützt lediglich eine Sache: die Vertraulichkeit des bisherigen Sitzungsverkehrs vor einer zukünftigen Kompromittierung des langfristigen Schlüsselmaterials. Folgendes wird nicht abgedeckt:

• Ein aktiver Man-in-the-Middle-Angriff in Echtzeit. PFS schützt aufgezeichneten Datenverkehr vor späterer Entschlüsselung; es unternimmt jedoch nichts, um einen Angreifer aufzuhalten, der eine Sitzung aktiv abfängt und manipuliert, während sie stattfindet, wenn er die Authentifizierung auf anderem Wege umgehen kann (zum Beispiel durch ein falsch ausgestelltes oder nicht ordnungsgemäß validiertes Zertifikat).

• Ein kompromittierter Endpunkt. Wenn der Client oder Server selbst während einer aktiven Sitzung kompromittiert wird, können Schadsoftware oder ein Angreifer mit lokalem Zugriff Klartext direkt lesen, vor oder nach der Verschlüsselung, unabhängig davon, wie der Sitzungsschlüssel ausgehandelt wurde.

• Offenlegung von Metadaten. PFS schützt Sitzungsinhalte; es verbirgt jedoch keine Verbindungsmetadaten wie Quell- und Ziel-IP-Adressen, Zeitangaben oder (außerhalb verschlüsselter Client-Hello-Bereitstellungen) den SNI-Hostnamen.

• Eine schwache oder kompromittierte Zertifizierungsstelle. PFS setzt voraus, dass der Authentifizierungsschritt (das Zertifikat und seine Signatur) vertrauenswürdig ist. Wenn eine Zertifizierungsstelle kompromittiert oder ein Zertifikat gefälscht ausgestellt wurde, kann ein Angreifer den Server während des Live-Handshakes weiterhin imitieren.

• Ein zukünftiger großskaliger Quantencomputer kann dies eigenständig leisten. PFS überwindet HNDL gegenüber klassischen Kompromittierungsversuchen des heutigen Schlüsselmaterials. Es macht den kurzlebigen ECDHE/DHE-Austausch jedoch nicht allein quantenresistent; dazu ist die Migration zu einem Post-Quanten- oder Hybrid-Schlüsselaustausch erforderlich (beispielsweise ECDHE in Kombination mit einem ML-KEM-basierten Mechanismus). Dies ist ein separates, laufendes Standardisierungsprojekt, das auf der Vorwärtsgeheimhaltung aufbaut, nicht diese ersetzt.

Was würde Encryption Consulting empfehlen?

Behandeln Sie Forward Secrecy (PFS) nicht als einmalige Checkbox-Prüfung. In der Praxis scheitert es aus wenigen, wiederholbaren Gründen: Ein Load Balancer oder CDN führt bei einer Routineänderung eine veraltete Cipher Suite wieder ein, eine „Kompatibilitäts“-Cipher-Liste wird aus einem alten Runbook kopiert, ohne zu prüfen, ob sie noch statisches RSA enthält, oder ein Team geht fälschlicherweise davon aus, dass „Wir verwenden TLS 1.3“ ausreicht, ohne zu überprüfen, ob die TLS-1.2-Fallback-Pfade (die für ältere Clients weiterhin erreichbar sind) gleichermaßen abgesichert sind. Wir empfehlen, Forward Secrecy als kontinuierlich zu prüfende Eigenschaft zu betrachten und nicht als einmalig festzulegende Konfiguration: Integrieren Sie die oben beschriebenen OpenSSL- und External-Scanner-Prüfungen in Ihren Änderungsmanagement- und Zertifikatserneuerungsprozess, nicht in ein jährliches Audit. Wählen Sie für die Kurvenauswahl standardmäßig X25519 und P-256, sofern keine spezifischen FIPS- oder regulatorischen Vorgaben etwas anderes vorschreiben. Behandeln Sie DHE und statisches RSA als zu behebende Mängel und nicht als akzeptable Altlasten. Da PFS nur einen Teil des Bedrohungsmodells abdeckt, ist es unerlässlich, es mit anspruchsvolleren, langfristigen Maßnahmen zu kombinieren, in die die meisten Unternehmen zu wenig investieren: eine umfassende kryptografische Bestandsaufnahme, die aufzeigt, wo in Ihrer IT-Infrastruktur der Austausch ephemerer Schlüssel implementiert ist und wo nicht, sowie einen konkreten Plan für den Übergang zu Post-Quanten- und hybriden Schlüsselaustauschverfahren. Denn das Risiko, vor dem PFS heute schützt („Erfassen und später entschlüsseln“), ist genau das Risiko, das ein quantenfähiges Ziel letztendlich gegen alle Systeme ausnutzen wird, die noch ausschließlich auf klassischer Diffie-Hellman-Mathematik basieren. Genau diese Lücke schließen unsere Beratungsdienste für Verschlüsselung und unsere PQC-Readiness- Programme: Wir bieten Ihnen einen priorisierten, evidenzbasierten Fahrplan anstelle einer allgemeinen Checkliste mit Best Practices.

Fazit

Encryption Consulting LLC (EC) bietet Beratungsleistungen an , um Unternehmen bei der Bewertung ihrer aktuellen Verschlüsselungsstrategie, einschließlich TLS- und Schlüsselaustauschkonfiguration, zu unterstützen und eine priorisierte Roadmap anstelle einer allgemeinen Checkliste zu erstellen. Benötigt Ihr Team Unterstützung bei der Überprüfung der Konfiguration von Verschlüsselungssuiten auf einer großen Serverlandschaft, der Verifizierung der Forward Secrecy oder der Planung des Übergangs zu Post-Quantum- und Hybrid-Schlüsselaustauschverfahren? Unser Beratungsteam kann diese Bewertung direkt auf Ihre Umgebung zuschneiden.

Häufig gestellte Fragen

Führt die Aktivierung von TLS 1.3 automatisch zu Perfect Forward Secrecy? Ja, für jede Verbindung, die TLS 1.3 aushandelt. RFC 8446 hat den statischen RSA- und (EC)DH-Schlüsselaustausch vollständig aus dem Protokoll entfernt, sodass ein TLS-1.3-Handshake immer ECDHE (oder einen PSK-basierten Modus) verwendet. Die Lücke, die die meisten Organisationen übersehen, ist ihr TLS-1.2-Fallback-Pfad, der weiterhin Nicht-Forward-Secrecy-Verschlüsselungssuiten aushandeln kann, sofern diese nicht explizit ausgeschlossen werden.

Welche Kurve sollten wir verwenden, X25519 oder P-256? Für die meisten öffentlich zugänglichen Installationen ohne spezifische FIPS-Vorgaben empfehlen wir standardmäßig X25519 aufgrund der besseren Performance und der höheren Widerstandsfähigkeit gegen Seitenkanalangriffe. Falls Ihre Umgebung FIPS-140-validierte Kryptografie erfordert oder die Parameter von SP 800-56A/186 strikt eingehalten werden müssen, verwenden Sie P-256, da X25519 zum jetzigen Zeitpunkt noch nicht offiziell in dieser NIST-Publikation enthalten ist.

Nutzen Messaging-Apps wie Signal und WhatsApp dasselbe PFS wie TLS? Sie basieren zwar auf demselben Prinzip – temporären Schlüsseln, die nach Gebrauch verworfen werden –, aber nicht auf demselben Mechanismus. Das Protokoll von Signal, das auch WhatsApp verwendet, nutzt einen Double-Ratchet-Algorithmus, der die Schlüssel pro Nachricht statt pro Sitzung rotiert. Dadurch wird eine noch stärkere Vorwärtsgeheimhaltung (und zusätzliche Sicherheit nach einem Kompromittierungsversuch) erreicht als mit einem einfachen TLS-Handshake.

Können wir RSA-Zertifikate beibehalten und gleichzeitig Perfect Forward Secrecy nutzen? Ja. Das RSA-Schlüsselpaar des Zertifikats dient der Authentifizierung (Signatur) des Handshakes, nicht der Verschlüsselung der Sitzungsdaten; diese Aufgabe übernimmt ECDHE. Eine ECDHE_RSA-Verschlüsselungssuite ermöglicht sowohl RSA-basierte Authentifizierung als auch vollständige Forward Secrecy in derselben Verbindung.

Schützt PFS vor Quantencomputern? Nicht allein. PFS schützt zwar vor einer zukünftigen Kompromittierung klassischer Schlüsselmaterialien, doch der ephemere ECDHE/DHE-Austausch selbst basiert weiterhin auf mathematischen Prinzipien, die ein ausreichend leistungsfähiger Quantencomputer voraussichtlich brechen wird. Die Daten, die heute für die Entschlüsselung gesammelt werden, sobald ein solcher Computer existiert, entsprechen genau dem Szenario, das die aktuellen Standardisierungsbemühungen für Post-Quanten- und Hybrid-Schlüsselaustauschverfahren antreibt; PFS ist eine notwendige Ergänzung, kein Ersatz für diese Migration.

Referenzen

• IETF, RFC 8446, Das Transport Layer Security (TLS) Protokoll Version 1.3
• IETF, RFC 9325 (BCP 195), Empfehlungen für die sichere Verwendung von TLS und DTLS
• IETF, RFC 7748, Elliptische Kurven für Sicherheitszwecke (X25519 und X448)
• NIST, SP 800-56A Revision 3, Empfehlung für paarweise Schlüsselaustauschverfahren unter Verwendung diskreter Logarithmus-Kryptographie
• NIST, Hinweis: NIST wird die Sonderveröffentlichung 800-56A aktualisieren und 800-56C überarbeiten (Januar 2026)