2026-08-04 · RECHERCHE · L'équipe Offensive Technology

Le FIPS 140-3 désactive-t-il le TLS post-quantique ? Il vous rétrograde silencieusement

La réponse courte à « FIPS désactive-t-il le TLS post-quantique » est : il ne vous fournit pas un TLS post-quantique conforme, et il peut le désactiver discrètement. Dans notre propre laboratoire, sur le réseau, deux piles majeures ont réagi de manière opposée une fois basculées en mode FIPS, et aucune ne proposait par défaut le groupe post-quantique approuvé FIPS. Go 1.24, sous GODEBUG=fips140=on et =only, a retiré tous les groupes post-quantiques de son ClientHello et a négocié silencieusement un P-256 classique. Une connexion ayant « réussi » ne présentait donc aucun échange de clés résistant au quantique. Le fournisseur FIPS d'OpenSSL 3.5.2 a fait exactement l'inverse : il continuait de proposer et de négocier X25519MLKEM768, l'hybride dont la moitié X25519 n'est pas approuvée par FIPS. Son fournisseur FIPS gère cette moitié via un indicateur d'approbation au lieu de la bloquer. Ainsi, le TLS post-quantique sous FIPS 140-3 tombe dans l'un de deux modes de défaillance : le passage en mode FIPS désactive la protection post-quantique (Go) ou maintient un groupe non conforme (OpenSSL). La protection contre les attaques de type « capturer maintenant, déchiffrer plus tard » est silencieusement déconfigurée pour les organisations réglementées qui ont précisément l'obligation d'utiliser FIPS.

Ce que nous avons constaté en activant le mode FIPS

Nous avons monté deux clients et deux serveurs, une paire sous Go 1.24 et une sous OpenSSL 3.5.2, puis observé leurs poignées de main TLS 1.3 sur le réseau avec le mode FIPS désactivé, puis activé. TLS 1.3 envoie les extensions supported_groups et key_share en clair, ce qui fait du ClientHello la source de vérité : vous pouvez lire précisément quels groupes d'échange de clés un client accepte et pour lequel il a préparé une part de clé. Pas de spéculation basée sur la documentation d'une bibliothèque, uniquement les octets transmis sur la socket.

Avec Go 1.24 en mode FIPS, le ClientHello s'est réduit aux seules courbes du NIST. La liste supported_groups contenait secp256r1, secp384r1, secp521r1 et rien d'autre : aucun x25519 nu, aucun X25519MLKEM768, et notamment même pas le groupe approuvé FIPS SecP256r1MLKEM768. Le key_share était secp256r1 et le groupe négocié secp256r1, un échange Diffie-Hellman sur courbes elliptiques classique sans aucun composant post-quantique. Le comportement était identique pour fips140=on et le mode plus strict fips140=only. Un serveur Go en mode FIPS, recevant une offre de groupe post-quantique par un pair non FIPS, a répondu par un HelloRetryRequest et forcé la poignée de main à se dégrader vers secp256r1. Dans tous les cas, la poignée de main s'est terminée avec succès. C'est bien là le danger : aucun échec, aucun avertissement, la connexion a simplement perdu sa résistance au quantique en toute discrétion.

Avec OpenSSL 3.5.2, le fournisseur FIPS a pris la direction opposée. Son ClientHello en mode FIPS débutait par X25519MLKEM768 et incluait un key_share correspondant, suivi de P-256, P-384, P-521 et des groupes à corps finis. Par rapport à sa configuration de référence hors FIPS, les seuls groupes retirés par le mode FIPS étaient les courbes autonomes x25519 et x448. L'hybride hybride X25519MLKEM768 est resté en tête de liste avec un key_share actif, et a négocié ce groupe face à un pair le prenant en charge. Le serveur OpenSSL a également accepté X25519MLKEM768. Ainsi, OpenSSL en mode FIPS continue de proposer un groupe dont la moitié classique ne peut pas être utilisée seule.

La table de vérité, sur le réseau

Voici chaque cas mesuré, avec les groupes proposés par chaque pile, le groupe négocié et l'impact direct. Les lignes Go et OpenSSL illustrent le problème : une même intention, « rendre TLS conforme FIPS », pour un résultat opposé.

Comparez les deux dernières lignes au reste du tableau. Les deux hybrides post-quantiques réalisent leur poignée de main sans erreur avec les deux pairs en mode FIPS, y compris SecP256r1MLKEM768 qui est pleinement approuvé. Les piles sont capables de fonctionner correctement. Elles ne le font simplement pas par défaut : Go supprime l'ensemble des hybrides, tandis qu'OpenSSL sélectionne l'option non approuvée.

Comment nous l'avons mesuré, pour les plus sceptiques

Le jeu de données est le nôtre, généré sur nos propres systèmes, sous forme agrégée uniquement. Tout a été exécuté dans des conteneurs Docker créés par nos soins, sur une VM cloud éphémère, communiquant entre eux via l'interface loopback. Aucun serveur tiers n'a été sollicité, aucun point d'accès externe contacté, et aucune donnée personnelle collectée. Il s'agit d'un environnement de laboratoire, pas d'un scan d'infrastructure tierce.

Nous avons employé trois vérifications indépendantes pour ne pas nous appuyer aveuglément sur un seul outil :

• Le réseau lui-même. Les extensions supported_groups et key_share de TLS 1.3 étant en clair, nous avons extrait les points de code exacts des groupes depuis la poignée de main. X25519MLKEM768 correspond à 0x11ec, SecP256r1MLKEM768 à 0x11eb, x25519 à 0x001d et secp256r1 (P-256) à 0x0017. Les offres du client et les groupes négociés proviennent directement de ces octets.
• Le rapport interne d'OpenSSL. Le client OpenSSL affiche également le « Negotiated TLS1.3 group », qui concordait à chaque fois avec nos relevés réseau.
• La preuve que le mode FIPS était réellement actif. Sous la configuration FIPS d'OpenSSL, seuls les fournisseurs base et fips étaient chargés, sans fournisseur default. La génération autonome de clés X25519 a échoué avec un code de sortie non nul pour cause de non-prise en charge, tandis que la même opération réussissait sous le fournisseur default, et que la génération de clés ML-KEM-768 réussissait sous FIPS. Le module se comporte exactement comme un module FIPS conforme : X25519 seul est non approuvé et refusé, ML-KEM de la norme FIPS 203 est approuvé et autorisé.

Pourquoi FIPS agit ainsi : X25519 n'est pas approuvé, ML-KEM l'est

Le problème provient d'un décalage entre les exigences des normes et les choix par défaut de l'écosystème. Selon les règles d'accord de clés du NIST dans la SP 800-56A, X25519 n'est pas un schéma approuvé par FIPS, ce qui explique pourquoi un module strict le refuse lorsqu'il est utilisé seul. ML-KEM, standardisé sous la norme FIPS 203, est quant à lui approuvé. Le seul hybride largement spécifié qui soit conforme FIPS sur ses deux composants est SecP256r1MLKEM768 : la courbe approuvée NIST P-256, couplée à ML-KEM-768. L'hybride concurrent X25519MLKEM768 associe ML-KEM-768 (approuvé) à X25519 (non approuvé), rendant la moitié du schéma non conforme.

Le problème réside dans le fait que les navigateurs, Go et OpenSSL utilisent tous X25519MLKEM768 par défaut au lieu du groupe approuvé SecP256r1MLKEM768, car X25519 est rapide et omniprésent en dehors du monde FIPS. Les deux hybrides sont spécifiés dans le même draft IETF pour l'échange de clés ECDHE-MLKEM. Ainsi, le passage en mode FIPS qui supprime X25519 retire également l'hybride post-quantique qui s'appuie dessus, sauf si la pile gère cet hybride comme un cas particulier. C'est exactement la divergence que nous avons mesurée. Go restreint à l'excès : il supprime tous les groupes post-quantiques et revient au classique, ce qui garantit la conformité mais abandonne toute résistance au quantique. OpenSSL ne restreint pas assez : il conserve l'hybride non approuvé actif en le contrôlant via un indicateur d'approbation FIPS au lieu de le bloquer, un comportement suivi dans openssl/openssl #27061. Aucun de ces comportements n'est un bug au sens classique ; ce sont des choix d'architecture défendables qui produisent un résultat inattendu lorsqu'on analyse le réseau. Le comportement de Go est abordé dans golang/go #78178 et #78298, et le support post-quantique d'OpenSSL 3.5 est arrivé lors de sa publication d'avril 2025.

Que faire si vous utilisez FIPS et souhaitez parer les attaques de type « capturer maintenant, déchiffrer plus tard »

Tout l'intérêt d'un hybride post-quantique est de contrer un attaquant pratiquant le « capturer maintenant, déchiffrer plus tard », qui enregistre votre trafic TLS aujourd'hui pour le déchiffrer dès qu'un ordinateur quantique sera disponible. Une bascule FIPS qui supprime silencieusement cette protection va à l'encontre du but recherché pour les organisations les plus ciblées. Si vous utilisez FIPS, ne partez pas du principe que l'option a géré le problème.

• Configurez explicitement SecP256r1MLKEM768. Il s'agit de l'hybride conforme aux exigences FIPS, avec ses deux composants approuvés, et dans notre laboratoire, la poignée de main s'est déroulée sans erreur avec les deux pairs en mode FIPS. Cependant, ni Go 1.24 ni OpenSSL 3.5 ne le proposent par défaut, vous devez donc le déclarer manuellement dans votre liste de groupes.
• Vérifiez sur le réseau, ne vous fiez pas au simple paramètre. Capturez une véritable poignée de main et lisez le groupe négocié. L'activation du mode FIPS ne donnait aucune information utile sur l'échange de clés réel dans l'une ou l'autre des piles ; seuls les octets l'ont révélé.
• Avec Go, sachez que GODEBUG=fips140 supprime X25519MLKEM768. Si vous avez activé le mode FIPS sans autre configuration, vos services Go négocient un P-256 classique sans aucun échange de clés post-quantique. Testez votre groupe négocié réel avant de tirer des conclusions.
• Déterminez quel risque vous gérez. Si l'approbation FIPS stricte est la contrainte prioritaire, l'hybride par défaut d'OpenSSL constitue un écart de conformité. Si la résistance au quantique est l'exigence centrale, le choix par défaut de Go pose problème. SecP256r1MLKEM768 est la configuration qui répond aux deux besoins.

Ce que cela ne prouve pas

Un résultat présenté sans ses limites relève du marketing. Voici donc le périmètre de cette étude.

• Versions spécifiques des bibliothèques. Ces tests concernent Go 1.24 et OpenSSL 3.5.2. Les paramètres par défaut, les politiques de fournisseurs et les indicateurs d'approbation évoluent au fil des versions, de sorte qu'une version plus récente peut se comporter différemment.
• Notre configuration. Nous avons mesuré des configurations FIPS spécifiques mises en place par nos soins. Un autre module FIPS, une option de compilation ou un fichier de politique différent pourrait proposer un jeu de groupes distinct.
• Paramètres par défaut, pas capacités. Les deux piles savent négocier l'hybride approuvé si on le leur demande. Ce constat porte sur leur comportement natif par défaut, et non sur leurs capacités théoriques.
• Un seul protocole de transport. Il s'agit de l'échange de clés TLS 1.3. Cela ne donne aucune indication sur les signatures, certificats ou autres protocoles de votre infrastructure.

Foire aux questions

L'activation du mode FIPS désactive-t-elle le TLS post-quantique ?

C'est possible, et ce fut le cas dans notre laboratoire. Avec Go 1.24 sous GODEBUG=fips140=on ou fips140=only, le ClientHello a abandonné tous les groupes post-quantiques et la connexion a négocié un P-256 classique. Une poignée de main ayant réussi ne comportait donc aucun échange de clés résistant au quantique. OpenSSL 3.5.2 a fait l'inverse : son fournisseur FIPS continuait de proposer et négocier X25519MLKEM768, dont la partie X25519 n'est pas approuvée FIPS. Aucune des deux piles ne proposait le groupe post-quantique approuvé par FIPS par défaut.

X25519 est-il approuvé par FIPS ?

Non. X25519 n'est pas un schéma d'accord de clés approuvé selon le NIST SP 800-56A, un module FIPS strict le traite donc comme non approuvé. Nous l'avons confirmé directement : sous le fournisseur FIPS d'OpenSSL 3.5.2, la génération autonome de clés X25519 a échoué car non prise en charge avec un code de sortie non nul, alors que la même opération réussissait sous le fournisseur default.

X25519MLKEM768 est-il approuvé par FIPS ?

Pas au sens strict. C'est un hybride : la partie ML-KEM-768 est approuvée par FIPS 203, mais la partie X25519 n'est pas approuvée pour l'accord de clés. Le fournisseur FIPS d'OpenSSL ne bloquait pas l'hybride ; il le contrôlait via un indicateur d'approbation FIPS et continuait de le proposer et de le négocier par défaut. Le groupe fonctionne sous FIPS, mais sa moitié classique ne figure pas sur la liste approuvée.

Quel est le groupe TLS post-quantique approuvé par FIPS ?

L'hybride conforme aux normes FIPS et largement spécifié est SecP256r1MLKEM768 : NIST P-256, une courbe approuvée SP 800-56A, associée à ML-KEM-768 de la norme FIPS 203. Les deux moitiés sont approuvées. Dans notre laboratoire, le forçage de SecP256r1MLKEM768 avec les deux pairs en mode FIPS a permis une poignée de main réussie, mais ni Go 1.24 ni OpenSSL 3.5.2 ne le proposaient par défaut.

Pourquoi ma poignée de main TLS Go change-t-elle sous GODEBUG=fips140 ?

Parce que le mode FIPS de Go 1.24 restreint les courbes proposées à la sélection du NIST. Sous fips140=on ou fips140=only, le ClientHello capturé côté client ne proposait que secp256r1, secp384r1 et secp521r1, sans x25519 ni hybride post-quantique, et a négocié un P-256 classique. Un serveur Go en mode FIPS a envoyé un HelloRetryRequest pour forcer le pair à rétrograder vers secp256r1. La poignée de main réussissant toujours, la rétrogradation est totalement silencieuse à moins d'inspecter le groupe négocié.

FIPS compromet-il la protection contre les attaques « capturer maintenant, déchiffrer plus tard » ?

Dans les configurations par défaut testées, oui, de la manière la plus critique. Go en mode FIPS a supprimé tout échange de clés post-quantique pour revenir à la cryptographie classique, exactement le type de trafic qu'un attaquant cherche à enregistrer pour déchiffrer plus tard. OpenSSL a conservé l'échange de clés post-quantique, mais via un hybride dont la moitié classique n'est pas approuvée FIPS, ce qui constitue un problème de conformité plutôt que cryptographique. Dans les deux cas, l'activation de FIPS ne fournissait pas de protection post-quantique conforme par défaut.

Articles connexes

• Ce que prouvent les certificats. Analyser les garanties TLS directement sur le réseau au lieu de se fier aux déclarations.
• Combien de grands domaines restreignent la délivrance de certificats ? La même méthode passive, basée sur nos propres données, appliquée à l'écosystème des certificats publics.
• Sécurité des serveurs MCP distants. Une autre évaluation d'une configuration par défaut adoptée par la plupart des équipes plus vite qu'elle n'est auditée.