L'empreinte TLS et les hachages JA4 expliqués

Chaque connexion HTTPS commence par une poignée de main TLS, et chaque poignée de main TLS commence par un message Client Hello. Ce message contient une multitude d'informations sur le client qui se connecte — suites de chiffrement, extensions, courbes prises en charge, algorithmes de signature — qui varient sensiblement selon les navigateurs, les versions et les systèmes d'exploitation. L'empreinte TLS capture ces informations et les utilise comme signal d'identification.

Qu'y a-t-il dans un Client Hello ?

Lorsqu'un navigateur se connecte à un serveur HTTPS, il envoie un message Client Hello contenant : la version de TLS qu'il prend en charge, la liste des suites de chiffrement qu'il est prêt à utiliser, les extensions TLS qu'il inclut (comme SNI, ALPN et key share), les courbes elliptiques qu'il prend en charge, les algorithmes de signature qu'il accepte et les méthodes de compression qu'il propose.

Chaque famille de navigateurs possède une empreinte distinctive. Chrome, Firefox et Safari envoient tous des ordonnancements de suites de chiffrement différents, des ensembles d'extensions différents et des préférences de courbes différentes. Même au sein d'une même famille de navigateurs, différentes versions peuvent envoyer des messages Client Hello légèrement différents à mesure que des suites de chiffrement sont ajoutées ou dépréciées.

De JA3 à JA4

JA3 était le hachage d'empreinte TLS original, introduit par Salesforce en 2017. Il concatène la version de TLS, les suites de chiffrement, les extensions, les courbes elliptiques et les formats de points EC en une chaîne, puis calcule un hachage MD5. Bien que révolutionnaire, JA3 a des limites : il produit un unique hachage opaque difficile à analyser, et des changements mineurs dans n'importe quel champ produisent un hachage complètement différent.

JA4, introduit par FoxIO en 2023, améliore JA3 de plusieurs façons. Il produit une empreinte structurée avec trois composantes : un préfixe lisible (comme « t13d1715h2 » — TLS 1.3, 17 suites de chiffrement, 15 extensions, HTTP/2), un hachage ordonné des suites de chiffrement et un hachage ordonné des extensions. Cette structure rend les empreintes JA4 analysables d'un coup d'œil tout en conservant la précision nécessaire à l'identification.

Pourquoi les empreintes TLS comptent pour l'intelligence des appareils

Les empreintes TLS sont précieuses parce qu'elles sont collectées avant l'exécution de tout JavaScript. Un bot qui usurpe son user agent, falsifie son rendu canvas et modifie ses propriétés navigator envoie tout de même un véritable message Client Hello depuis la bibliothèque TLS qu'il utilise réellement. Si le Client Hello dit « bibliothèque crypto/tls de Go » mais que l'user agent dit « Chrome 124 », nous savons que quelque chose est usurpé.

Cette validation croisée est extrêmement puissante pour la détection des bots. La plupart des frameworks d'automatisation — Selenium, Puppeteer, Playwright — utilisent la pile TLS native du navigateur, donc leurs empreintes TLS correspondent au navigateur qu'ils contrôlent. Mais les clients HTTP personnalisés, les scrapers basés sur Go et les scripts Python utilisant la bibliothèque requests ont tous des empreintes TLS distinctives qui les identifient immédiatement comme des clients non-navigateurs.

La stabilité des empreintes TLS

L'une des préoccupations liées à l'empreinte TLS est la stabilité à travers les mises à jour des navigateurs. Lorsque Chrome ajoute ou retire une suite de chiffrement, l'empreinte TLS change. En pratique, cela se produit moins souvent que vous ne le pensez. La liste des suites de chiffrement de Chrome est relativement stable — les changements majeurs surviennent une ou deux fois par an, pas à chaque version.

Le format structuré de JA4 aide ici. Le préfixe lisible reste stable à travers les changements de version mineurs (le nombre de suites de chiffrement et d'extensions ne change pas souvent), donc même lorsque le hachage détaillé change, le préfixe assure une continuité. Dans notre système d'identification multi-niveaux, les données d'empreinte TLS sont placées au niveau 2 — suffisamment stables pour contribuer à l'identification, mais traitées via une correspondance inter-sessions pour gérer la dérive attendue.

Collecte côté serveur

Contrairement aux signaux côté client qui nécessitent l'exécution de JavaScript, les empreintes TLS sont collectées entièrement côté serveur. Nos serveurs edge inspectent la poignée de main TLS brute et extraient le Client Hello avant que la connexion soit établie. Cela signifie que l'empreinte TLS fonctionne même quand le JavaScript est bloqué, quand le navigateur a des extensions de confidentialité installées, ou quand le client n'est pas du tout un navigateur.

Cette nature côté serveur rend aussi les empreintes TLS résistantes à l'usurpation. Bien qu'il soit théoriquement possible de fabriquer un Client Hello TLS personnalisé imitant un navigateur spécifique, cela nécessite d'implémenter TLS à bas niveau — un effort bien plus important que de modifier une chaîne user agent. La plupart des outils d'usurpation ne s'y essaient pas.

Intégration à l'identification des appareils

Dans notre moteur d'identification des appareils, l'empreinte TLS sert à la fois de signal et de validateur. En tant que signal, elle contribue à l'empreinte globale de l'appareil avec son propre poids d'identification. En tant que validateur, elle fournit un recoupement contre l'identité de navigateur revendiquée. Si les signaux JavaScript disent « Chrome sur macOS » mais que l'empreinte TLS dit « Firefox sur Linux », l'écart déclenche un signalement de falsification dans notre analyse Smart Signals.