2026-08-04 · RESEARCH · Das Offensive Technology Team

Deaktiviert FIPS 140-3 Post-Quanten-TLS? Es stuft Sie stillschweigend herunter

Die kurze Antwort auf „Deaktiviert FIPS Post-Quanten-TLS?“ lautet: Es liefert kein konformes Post-Quanten-TLS, und es kann es stillschweigend deaktivieren. In unserem eigenen Labor zeigten zwei große Stacks auf der Leitung gegensätzliches Verhalten, sobald wir sie in den FIPS-Modus versetzten, und keiner von beiden bot standardmäßig die FIPS-konforme Post-Quanten-Gruppe an. Go 1.24 unter GODEBUG=fips140=on und =only, entfernte jede Post-Quanten-Gruppe aus seinem ClientHello und handelte stillschweigend klassisches P-256 aus, sodass eine Verbindung, die „erfolgreich“ war, keinerlei quantenresistenten Schlüsselaustausch enthielt. Der FIPS-Provider von OpenSSL 3.5.2 tat das Gegenteil: Er bot weiterhin X25519MLKEM768, den Hybriden, dessen X25519-Hälfte nicht FIPS-konform ist, an und handelte ihn aus. Sein FIPS-Provider steuert diese Hälfte über einen Approval-Indikator, anstatt sie zu blockieren. FIPS 140-3 Post-Quanten-TLS endet also in einem von zwei Fehlerzuständen: Schaltet man FIPS ein, schaltet sich entweder der Post-Quanten-Schutz ab (Go) oder eine nicht konforme Gruppe bleibt aktiv (OpenSSL). Der Schutz vor „Harvest-Now-Decrypt-Later“ wird ausgerechnet bei den regulierten Organisationen, die FIPS einsetzen müssen, stillschweigend falsch konfiguriert.

Was wir herausfanden, als wir den FIPS-Schalter umlegten

Wir haben zwei Clients und zwei Server aufgebaut, ein Paar auf Go 1.24 und ein Paar auf OpenSSL 3.5.2, und deren TLS-1.3-Handshakes auf der Leitung bei deaktiviertem und anschließend aktiviertem FIPS-Modus analysiert. TLS 1.3 überträgt die supported_groups und key_share-Erweiterungen im Klartext, sodass das ClientHello die absolute Wahrheit ist: Man kann exakt ablesen, welche Schlüsselaustausch-Gruppen ein Client akzeptiert und für welche er ein Share vorbereitet hat. Kein Raten anhand der Dokumentation einer Bibliothek, sondern schlicht die Bytes auf dem Socket.

Mit Go 1.24 im FIPS-Modus schrumpfte das ClientHello ausschließlich auf NIST-Kurven zusammen. Die Liste supported_groups war secp256r1, secp384r1, secp521r1 und sonst nichts: kein reines x25519, kein X25519MLKEM768 und bemerkenswerterweise nicht einmal das FIPS-konforme SecP256r1MLKEM768. Das key_share war secp256r1 und die ausgehandelte Gruppe war secp256r1, klassisches Elliptic-Curve-Diffie-Hellman ohne jegliche Post-Quanten-Komponente. Das Verhalten war identisch für fips140=on und das striktere fips140=only. Ein Go-Server im FIPS-Modus, dem von einem Nicht-FIPS-Peer eine Post-Quanten-Gruppe angeboten wurde, antwortete mit einem HelloRetryRequest und erzwang ein Herabstufen des Handshakes auf secp256r1. In jedem Fall wurde der Handshake erfolgreich abgeschlossen. Das ist der gefährliche Teil: Nichts schlug fehl, es gab keine Warnung, die Verbindung verlor einfach stillschweigend ihre Quantenresistenz.

Mit OpenSSL 3.5.2 ging der FIPS-Provider den entgegengesetzten Weg. Sein ClientHello im FIPS-Modus begann mit X25519MLKEM768 und enthielt ein passendes key_share, gefolgt von P-256, P-384, P-521 und den Endlichen-Körper-Gruppen. Im Vergleich zur Nicht-FIPS-Baseline waren die einzigen Gruppen, die der FIPS-Modus entfernte, die eigenständigen-Kurven x25519 und x448; der hybride X25519MLKEM768 blieb an der Spitze der Liste mit einem aktiven key_share und handelte diese Gruppe mit einem Peer aus, der sie unterstützte. Der OpenSSL-Server akzeptierte X25519MLKEM768 ebenfalls. OpenSSL bietet im FIPS-Modus also weiterhin eine Gruppe an, deren klassische Hälfte es alleine gar nicht zulassen würde.

Die Wahrheitstabelle auf der Leitung

Hier ist jeder von uns gemessene Fall mit den von jedem Stack angebotenen Gruppen, der ausgehandelten Gruppe und was das für Sie bedeutet. Die Go- und OpenSSL-Zeilen erzählen die eigentliche Geschichte: dieselbe Absicht („TLS FIPS-konform machen“), entgegengesetztes Ergebnis.

Liest man die letzten beiden Zeilen im Kontext aller darüber liegenden: Beide Post-Quanten-Hybriden führen im FIPS-Modus mit beiden Peers einen sauberen Handshake durch, einschließlich des vollständig zugelassenen SecP256r1MLKEM768. Die Stacks sind absolut in der Lage, das Richtige zu tun. Sie wählen es nur nicht automatisch für Sie aus: Go entfernt sie alle, OpenSSL nutzt standardmäßig den nicht zugelassenen Hybriden.

Wie wir es gemessen haben, damit auch Skeptiker den Zahlen vertrauen können

Der Datensatz stammt von uns selbst, wurde auf unseren eigenen Systemen erstellt und liegt nur in aggregierter Form vor. Wir haben alles in selbst erstellten Docker-Containern auf einer ephemeren Cloud-VM ausgeführt, die über Loopback miteinander kommunizierten. Es wurde kein Server Dritter berührt, kein externer Endpunkt kontaktiert und keinerlei personenbezogene Daten erhoben. Dies ist eine Laborumgebung, kein Scan fremder Infrastruktur.

Wir haben drei unabhängige Prüfungen verwendet, damit man keinem einzelnen Tool blind vertrauen muss:

• Die Leitung selbst. TLS 1.3 supported_groups und key_share werden im Klartext übertragen, sodass wir die exakten Gruppen-Codepunkte direkt aus dem Handshake ablesen konnten. X25519MLKEM768 ist 0x11ec, SecP256r1MLKEM768 ist 0x11eb, x25519 ist 0x001d und secp256r1 (P-256) ist 0x0017. Was ein Client anbot und was ausgehandelt wurde, stammte direkt aus diesen Bytes.
• Die Eigenauskunft von OpenSSL. Der OpenSSL-Client gibt zusätzlich die „Negotiated TLS1.3 group“ aus, was in jedem Fall mit unseren Messwerten auf der Leitung übereinstimmte.
• Nachweis, dass FIPS tatsächlich aktiv war. Unter der OpenSSL-FIPS-Konfiguration waren nur die Provider base und fips geladen, ohne default-Provider. Die eigenständige X25519-Schlüsselerzeugung schlug als nicht unterstützt mit einem Exit-Code ungleich null fehl, während dieselbe Operation unter dem default-Provider erfolgreich war und die ML-KEM-768-Schlüsselerzeugung unter FIPS gelang. Das Modul verhält sich damit exakt so, wie ein echtes FIPS-Modul sollte: X25519 ist isoliert nicht zugelassen und wird verweigert, ML-KEM aus FIPS 203 ist zugelassen und erlaubt.

Warum FIPS das tut: X25519 ist nicht zugelassen, ML-KEM schon

Der Mechanismus beruht auf einer Diskrepanz zwischen dem, was die Standards zulassen, und dem, was das Ökosystem standardmäßig verwendet. Gemäß den NIST-Regeln zur Schlüsselvereinbarung in SP 800-56A ist X25519 kein FIPS-konformes Verfahren, weshalb ein striktes Modul es isoliert verweigert. ML-KEM, standardisiert als FIPS 203, ist hingegen zugelassen. Der einzige weit verbreitete und spezifizierte Hybrid, der in beiden Hälften FIPS-konform ist, ist SecP256r1MLKEM768: NIST P-256, eine zugelassene Kurve, gekoppelt mit ML-KEM-768. Der konkurrierende Hybrid X25519MLKEM768 kombiniert zugelassenes ML-KEM-768 mit nicht zugelassenem X25519, weshalb eine Hälfte nicht auf der Freigabeliste steht.

Das Problem ist, dass Browser, Go und OpenSSL standardmäßig auf X25519MLKEM768 setzen und nicht auf das zugelassene SecP256r1MLKEM768, da X25519 außerhalb der FIPS-Welt schnell und weit verbreitet ist. Beide Hybriden sind im selben IETF-Entwurf für den ECDHE-MLKEM-Schlüsselaustausch spezifiziert. Ein FIPS-Schalter, der X25519 entfernt, entfernt daher auch den darauf aufbauenden Post-Quanten-Hybriden, es sei denn, der Stack behandelt den Hybriden als Sonderfall. Das ist exakt die Verzweigung, die wir gemessen haben. Go schränkt zu stark ein: Es verwirft jede Post-Quanten-Gruppe und fällt auf klassische Verfahren zurück. Das ist zwar sicher für die Compliance, wirft aber die Quantenresistenz über Bord. OpenSSL schränkt zu wenig ein: Es hält den nicht zugelassenen Hybriden aktiv und steuert ihn über einen FIPS-Approval-Indikator, anstatt ihn zu blockieren. Dieses Design wird unter openssl/openssl #27061 nachverfolgt. Keines der beiden Verhalten ist ein Fehler im herkömmlichen Sinne; beides sind vertretbare Entscheidungen der Bibliotheksentwickler, die ein nicht offensichtliches Ergebnis liefern, sobald man sich die Daten auf der Leitung ansieht. Das Go-Verhalten wird unter golang/go #78178 und #78298 diskutiert, und die Post-Quanten-Unterstützung von OpenSSL 3.5 wurde mit dem Release im April 2025 eingeführt.

Was zu tun ist, wenn Sie FIPS einsetzen und Schutz vor Harvest-Now-Decrypt-Later benötigen

Der eigentliche Zweck eines Post-Quanten-Hybriden besteht darin, Angreifer nach dem Muster „Harvest now, decrypt later“ abzuwehren, die Ihren TLS-Datenverkehr heute aufzeichnen und entschlüsseln, sobald ein Quantencomputer existiert. Ein FIPS-Schalter, der diesen Schutz stillschweigend entfernt, konterkariert den Zweck für genau die Organisationen, die am ehesten ins Visier geraten. Wenn Sie FIPS einsetzen, verlassen Sie sich nicht darauf, dass der Schalter das bereits regelt.

• Konfigurieren Sie SecP256r1MLKEM768 explizit. Es ist der FIPS-konforme Hybrid, bei dem beide Hälften zugelassen sind, und in unserem Labor führte er im FIPS-Modus mit beiden Peers saubere Handshakes durch. Weder Go 1.24 noch OpenSSL 3.5 bieten ihn jedoch standardmäßig an, weshalb Sie ihn selbst in Ihrer Gruppenliste angeben müssen.
• Auf der Leitung verifizieren, nicht dem Schalter vertrauen. Zeichnen Sie einen echten Handshake auf und lesen Sie die ausgehandelte Gruppe ab. „FIPS an“ verriet uns bei keinem der beiden Stacks etwas Nützliches über den tatsächlichen Schlüsselaustausch, die Bytes hingegen schon.
• In Go sollte man wissen, dass GODEBUG=fips140 X25519MLKEM768 entfernt. Wenn Sie den FIPS-Modus aktiviert und sonst nichts unternommen haben, handeln Ihre Go-Dienste klassisches P-256 ohne Post-Quanten-Schlüsselaustausch aus. Testen Sie Ihre tatsächlich ausgehandelte Gruppe, bevor Sie etwas anderes annehmen.
• Entscheiden Sie, welches Risiko Sie steuern. Wenn die strikte FIPS-Zulassung die maßgebliche Anforderung ist, stellt der OpenSSL-Standardhybrid eine Compliance-Lücke dar. Ist Quantenresistenz die Anforderung, ist der Go-Standard die Lücke. SecP256r1MLKEM768 ist die Konfiguration, die beiden gerecht wird.

Was dies nicht beweist

Ein Ergebnis ohne seine Grenzen ist reines Marketing, daher sind hier die Rahmenbedingungen dieser Untersuchung.

• Einzelne Bibliotheksversionen. Dies betrifft Go 1.24 und OpenSSL 3.5.2. Standardwerte, Provider-Richtlinien und Approval-Indikatoren können sich über Versionen hinweg ändern und tun dies auch, sodass sich neuere Releases anders verhalten können.
• Unsere Konfiguration. Wir haben spezifische, von uns eingerichtete FIPS-Konfigurationen gemessen. Ein anderes FIPS-Modul, ein anderes Build-Flag oder eine andere Policy-Datei könnte ein abweichendes Gruppenset anbieten.
• Standardeinstellungen, nicht die Leistungsfähigkeit. Beide Stacks können den zugelassenen Hybriden aushandeln, wenn man es ihnen vorgibt. Die Erkenntnis bezieht sich darauf, was sie standardmäßig („out of the box“) tun, nicht wozu sie in der Lage sind.
• Ein Transportprotokoll. Dies betrifft den TLS-1.3-Schlüsselaustausch. Es sagt nichts über Signaturen, Zertifikate oder andere Protokolle in Ihrem Stack aus.

Häufig gestellte Fragen

Deaktiviert das Aktivieren des FIPS-Modus Post-Quanten-TLS?

Das kann passieren, und in unserem Labor war es so. Bei Go 1.24 unter GODEBUG=fips140=on oder fips140=only, verwarf das ClientHello jede Post-Quanten-Gruppe und die Verbindung handelte klassisches P-256 aus. Ein erfolgreicher Handshake bot somit keinerlei quantenresistenten Schlüsselaustausch. OpenSSL 3.5.2 tat das Gegenteil: Sein FIPS-Provider bot weiterhin X25519MLKEM768 an und handelte es aus, obwohl dessen X25519-Hälfte nicht FIPS-konform ist. Keiner der beiden Stacks bot standardmäßig die FIPS-konforme Post-Quanten-Gruppe an.

Ist X25519 FIPS-konform?

Nein. X25519 ist nach NIST SP 800-56A kein zugelassenes Schlüsselaustauschverfahren, weshalb ein striktes FIPS-Modul es als nicht zugelassen behandelt. Wir haben dies direkt bestätigt: Unter dem FIPS-Provider von OpenSSL 3.5.2 schlug die eigenständige X25519-Schlüsselerzeugung als nicht unterstützt mit einem Exit-Code ungleich null fehl, während dieselbe Operation unter dem default-Provider erfolgreich war.

Ist X25519MLKEM768 FIPS-konform?

Nicht uneingeschränkt. Es handelt sich um einen Hybriden: Die ML-KEM-768-Hälfte ist nach FIPS 203 zugelassen, aber die X25519-Hälfte ist für den Schlüsselaustausch nicht zugelassen. Der FIPS-Provider von OpenSSL blockiert den Hybriden nicht, sondern steuert ihn über einen FIPS-Approval-Indikator und bietet ihn weiterhin standardmäßig an und handelt ihn aus. Die Gruppe funktioniert unter FIPS, aber ihre klassische Hälfte steht nicht auf der Freigabeliste.

Welches ist die FIPS-konforme Post-Quanten-TLS-Gruppe?

Der weit verbreitete, FIPS-konforme Hybrid ist SecP256r1MLKEM768: NIST P-256, eine nach SP 800-56A zugelassene Kurve, kombiniert mit ML-KEM-768 aus FIPS 203. Beide Hälften sind zugelassen. In unserem Labor führte das Erzwingen von SecP256r1MLKEM768, während sich beide Peers im FIPS-Modus befanden, zu einem erfolgreichen Handshake. Allerdings bot weder Go 1.24 noch OpenSSL 3.5.2 diesen Hybrid standardmäßig an.

Warum ändert sich mein Go-TLS-Handshake unter GODEBUG=fips140?

Weil der FIPS-Modus von Go 1.24 die angebotenen Kurven auf das NIST-Set beschränkt. Unter fips140=on oder fips140=only, signalisierte das von uns erfasste ClientHello nur secp256r1, secp384r1 und secp521r1, ohne x25519 und ohne Post-Quanten-Hybrid, und handelte klassisches P-256 aus. Ein Go-Server im FIPS-Modus sendete ein HelloRetryRequest, um einen Peer auf secp256r1 herunterzustufen. Der Handshake ist weiterhin erfolgreich, sodass die Herabstufung stillschweigend erfolgt, sofern man die ausgehandelte Gruppe nicht explizit prüft.

Hebt FIPS den Schutz vor Harvest-Now-Decrypt-Later auf?

In den von uns getesteten Standardkonfigurationen ja, und zwar in der entscheidenden Hinsicht. Go im FIPS-Modus entfernte jeglichen Post-Quanten-Schlüsselaustausch und fiel auf klassische Kryptographie zurück. Das ist exakt der Datenverkehr, den ein Angreifer aufzeichnen und später entschlüsseln möchte. OpenSSL behielt den Post-Quanten-Schlüsselaustausch bei, jedoch über einen Hybriden, dessen klassische Hälfte nicht FIPS-konform ist, was eher ein Compliance- als ein kryptographisches Problem darstellt. In jedem Fall führte das Aktivieren von FIPS standardmäßig nicht zu einem konformen Post-Quanten-Schutz.

Weiterführende Lektüre

• Was Zertifikate beweisen. TLS-Sicherheitsgarantien direkt von der Leitung ablesen, anstatt der Aufschrift auf der Verpackung zu vertrauen.
• Wie viele Top-Domains schränken die Zertifikatsausstellung ein? Dieselbe passive, auf eigenen Daten basierende Methode, angewendet auf das öffentliche Zertifikats-Ökosystem.
• Sicherheit von Remote-MCP-Servern. Eine weitere Messung eines Standardwerts, den die meisten Teams schneller übernehmen, als sie ihn auditieren.