TLS post-quantique en 2026 : pourquoi le JA4 ne sauve plus le scraper

Il y a encore un an, le schéma était clair : vous prenez un client capable de falsifier le handshake TLS, vous choisissez un profil pour le nouveau Chrome, vous obtenez un JA4 correspondant — et l'antibot passe. En 2026, cette recette a commencé à échouer pour une raison qui n'a rien à voir avec le « contournement des protections ». Les navigateurs ont massivement adopté l'échange de clés post-quantique, tandis que la plupart des stacks de scraping ne l'ont pas fait. Et maintenant, l'absence de partage de clés post-quantique est en soi un marqueur d'automatisation.

Analysons selon les critères : qu'est-ce qui a changé dans le handshake, quels stacks ont déjà migré, lesquels ne l'ont pas fait, et pourquoi le hachage JA4 correspondant n'est plus une condition suffisante.

Ce qui s'est passé : l'échange post-quantique est devenu la norme, et non une excentricité

L'échange hybride de clés post-quantiques est une combinaison de la courbe elliptique classique X25519 et du mécanisme de grille ML-KEM (norme NIST FIPS 203). La session reste protégée si au moins un des deux composants est résistant. L'idée est de se protéger contre le scénario « intercepte maintenant, déchiffre plus tard », lorsque le trafic est archivé en prévision d'un futur ordinateur quantique.

Chronologie de l'implémentation dans les clients :

• Chrome 124 (avril 2024) — l'échange hybride post-quantique est activé par défaut ; dans les patches curl-impersonate, cela est noté comme « courbes X25519Kyber768/X25519MLKEM, introduites dans Chrome 124 et 130 ».
• Firefox 132 (novembre 2024) — support inclus.
• Safari sur iOS et macOS — l'échange post-quantique est arrivé en octobre 2025.
• OpenSSL 3.5.0 (avril 2025) — les groupes hybrides X25519MLKEM768, SecP256r1MLKEM768 et SecP384r1MLKEM1024 ont été ajoutés à la liste par défaut des groupes TLS.
• Go 1.24 (février 2025) — X25519MLKEM768 est inclus dans crypto/tls par défaut, sauf si Config.CurvePreferences est explicitement défini.

Du côté de l'infrastructure, la situation est encore plus claire. Cloudflare Radar en avril 2026 montrait environ 67 % du trafic HTTPS humain avec un chiffrement post-quantique — contre 32 % en janvier 2025. Akamai a fait de l'échange de clés post-quantiques le paramètre par défaut pour toutes les connexions clients le 31 janvier 2026, achevant le déploiement sur le réseau en mars. Selon les mesures sectorielles, environ 57,4 % de toutes les transactions de navigateur sont déjà prêtes pour le post-quantique, avec une part d'environ 93 % pour Chrome.

Notez l'asymétrie : le support du côté des serveurs d'origine croît beaucoup plus lentement (environ 9 % chez Cloudflare). Ainsi, le post-quantique aujourd'hui est avant tout une caractéristique du client. Exactement ce qui intéresse l'antibot.

Critère 1 : taille du key share et structure ClientHello

Le key share post-quantique n'est pas « un autre drapeau dans l'extension ». Il est physiquement volumineux : environ 1124 octets contre 36 octets pour le classique X25519. Les conséquences sont visibles à l'œil nu au niveau des paquets.

Le ClientHello avec le key share post-quantique dépasse 1400 octets et ne peut plus tenir dans un seul segment TCP. Il est divisé en deux paquets ou plus. Et ensuite, commence la partie la plus intéressante pour la détection : le modèle de fragmentation varie selon les implémentations. Comment exactement le stack découpe un grand ClientHello, dans quel ordre il envoie les segments, avec quels timings — c'est un comportement observable qui ne peut pas être déduit du hachage JA4 et que presque aucun des auteurs d'outils de scraping ne reproduit consciemment.

Conclusion pratique : l'antibot a un nouveau niveau qui fonctionne en dessous de l'empreinte habituelle. Vous pouvez parfaitement rassembler une liste de chiffrements et d'extensions, mais vous vous trahissez par la façon dont votre stack envoie des octets dans le socket.

Critère 2 : cohérence avec la version déclarée du navigateur

Le principal piège de 2026 est le désynchronisme entre qui vous prétendez être et ce que fait réellement votre stack TLS.

Les plateformes antibot maintiennent des bases de données de ClientHello de référence. Une requête qui dans User-Agent et dans JA4 déclare Chrome 131, mais arrive sans key share post-quantique, ne correspond à aucun Chrome 131 valide connu. Ce n'est pas « suspect » — c'est une combinaison logiquement impossible. Un vrai Chrome de cette version ne peut physiquement pas envoyer un key share classique avec les paramètres par défaut.

À quel point cela est bien séparé par l'apprentissage automatique — cela a également été calculé. Le classificateur CatBoost sur les caractéristiques JA4 dans les études montre AUC 0,998 et précision 0,9863 ; le trafic post-quantique se distingue du classique avec une précision d'environ 98 %. Ce n'est pas « une heuristique avec des faux positifs », c'est pratiquement un indicateur déterministe.

Critère 3 : préparation des stacks spécifiques

C'est ici que se dessine la véritable ligne de séparation. Décomposons par groupes.

Envoient le key share PQ par défaut

• Chrome 124+, Firefox 132+, Safari (iOS/macOS depuis octobre 2025) — référence avec laquelle vous êtes comparé.
• Go 1.24+ — crypto/tls inclut X25519MLKEM768 par lui-même, sauf si vous avez redéfini CurvePreferences. Un point important : le post-quantique est présent, mais le JA4 d'un client Go nu n'est toujours pas celui d'un navigateur. Vous obtenez une empreinte « compatible PQ, mais pas ressemblant à Chrome ».
• Node.js 24 — utilise sa propre OpenSSL 3.5, donc la liste par défaut des groupes inclut déjà l'hybride. De plus, dans node:crypto, ML-KEM a été ajouté via crypto.encapsulate()/decapsulate() et ML-DSA dans sign()/verify().

Dépendent de ce à quoi ils sont liés

• Python : requests, aiohttp, httpx — utilisent le module ssl, qui prend l'OpenSSL système. Sur Ubuntu 24.04, le système a OpenSSL 3.0.x, où il n'y a pas de groupes post-quantiques. Pour obtenir le PQ, il faut compiler OpenSSL 3.5 à partir des sources, le placer via LD_LIBRARY_PATH et, très probablement, recompter Python lui-même. En pratique, cela signifie que le scraper Python typique en 2026 envoie un key share classique et apparaît comme une anomalie sur Akamai.

Savent faire, mais seulement si le bon profil est choisi

• curl_cffi / curl-impersonate — le support des courbes post-quantiques est présent dans le fork et déclaré explicitement. Mais la liste des cibles va de chrome99 à chrome146 (dans le fork — jusqu'à chrome150), et les anciens profils reproduisent le handshake de leur époque, c'est-à-dire sans PQ. Copier-coller impersonate="chrome116" d'un guide vieux de deux ans est un chemin direct vers la détection.
• uTLS — même principe : les profils HelloChrome en dessous de 131 ne contiennent pas de key share PQ. De plus, la bibliothèque a corrigé deux vulnérabilités d'empreinte en 2026 : CVE-2026-26995 (versions 1.6.0–1.8.1) et CVE-2026-27017 (1.6.0–1.8.0, désynchronisation du choix de chiffrement pour GREASE ECH — Chrome le choisit de manière déterministe, tandis que parrot dans uTLS lançait une pièce entre AES et ChaCha20, ce qui est impossible pour un vrai Chrome). Il est nécessaire de mettre à jour au moins vers 1.8.2.

Le dénominateur commun : les outils ont principalement rattrapé leur retard. Le problème ne vient pas d'eux, mais du fait que les configurations vieillissent plus vite que les navigateurs. Un profil qui était idéal en 2024 fonctionne aujourd'hui comme un marqueur.

Comment vérifier votre stack en cinq minutes

1. Envoyez une requête avec votre client de production à https://tls.peet.ws/api/all ou ja4db.com — ils renvoient les JA3/JA4 en direct et l'analyse de ClientHello en JSON.
2. Trouvez dans l'analyse la liste des supported_groups et key_share. Cherchez X25519MLKEM768 (ou X25519Kyber768 pour les anciens profils). S'il n'y a que x25519/secp256r1 — il n'y a pas d'échange post-quantique.
3. Comparez cela avec la version du navigateur que vous prétendez utiliser. Vous déclarez Chrome 131+ et ne voyez pas de groupes PQ — la combinaison est invalide, corrigez le profil.
4. Vérifiez la taille de ClientHello. Moins de ~1400 octets avec un Chrome récent déclaré — c'est le même indicateur, mais sous un autre angle.
5. Effectuez la vérification depuis chaque nœud de sortie, et pas seulement depuis votre machine de travail : l'inspection SSL sur la passerelle d'entreprise ou chez le fournisseur peut réécrire le handshake pour vous.

Quel est le rôle des proxys ici

Il est important de ne pas mélanger deux couches indépendantes. Le key share post-quantique concerne le handshake, la réputation de l'adresse concerne le réseau. L'antibot les considère séparément et les additionne.

De là découlent deux conséquences pratiques. Premièrement : une IP résidentielle idéale ne sauvera pas une requête qui, au niveau TLS, se présente comme Chrome 131 sans groupe PQ — vous perdrez avant même que le serveur ne regarde l'adresse. Deuxièmement, inversement : un handshake post-quantique correctement constitué ne sera d'aucune aide si une centaine de vos sessions proviennent d'un sous-réseau de datacenter avec une réputation ternie. Il faut réparer les deux couches, et elles se réparent avec des outils différents.

Répartition pratique des tâches : pour les objectifs derrière Akamai et Cloudflare, où ils prennent en compte à la fois le handshake et le réseau, il est raisonnable d'utiliser des proxies résidentiels et de faire monter le ciblage impersonate à un Chrome récent. Pour les applications mobiles et les plateformes où le poids de la réputation IP est plus élevé que les exigences TLS, les proxies mobiles gagnent souvent. Et pour les API internes, les exports partenaires et la surveillance interne, où il n'y a pas d'antibot, il n'est pas nécessaire de payer plus pour un résidentiel — des datacenter suffisent.

Si vous débutez avec l'empreinte, commencez par les bases : comment fonctionne JA4 et ce qu'il inclut. Et quand il ne s'agit pas d'un client HTTP, mais d'un véritable navigateur, la comparaison des constructions stealth et de leurs points faibles est rassemblée séparément — nodriver, Camoufox et Patchright dans les mesures de 2026.

Conclusion

L'échange de clés post-quantiques n'a pas été conçu comme un mécanisme antibot. Il est devenu tel par accident : les navigateurs ont rapidement et massivement migré vers cela, l'infrastructure (Akamai — depuis le 31 janvier 2026) en a fait le paramètre par défaut, et les stacks de scraping se sont répartis en trois groupes — ceux qui ont déjà migré, ceux qui dépendent de l'OpenSSL système et ceux qui ne peuvent le faire qu'avec un profil récent.

La vérification se résume à une question : votre client envoie-t-il X25519MLKEM768 et cela correspond-il à la version du navigateur que vous prétendez utiliser ? Si ce n'est pas le cas — un JA4 correspondant ne vous sauvera pas, car on compare désormais non pas le hachage, mais toute la forme du handshake dans son ensemble : la taille du key share, le nombre de segments TCP et l'ordre dans lequel ils sont envoyés. La bonne nouvelle est que cela se corrige dans la plupart des cas par une mise à jour du profil et de la version de la bibliothèque, et non par une réécriture du scraper.