Empreinte JA3 vs JA4 : guide du fingerprinting TLS client
Ce qu'est une empreinte JA3, ce qui change avec JA4, pourquoi l'ordre aléatoire des extensions de Chrome a cassé JA3, et comment l'utiliser en détection.
En bref. Une empreinte de client TLS résume la façon dont un client construit son ClientHello : quelles versions, suites de chiffrement, extensions et paramètres il propose. JA3 (2017) hache cinq de ces champs, dans l'ordre d'envoi, avec MD5. Quand Chromium a commencé à mélanger l'ordre des extensions début 2023, le même navigateur s'est mis à produire un JA3 différent à presque chaque connexion. JA4 (2023, FoxIO) trie les suites et les extensions avant de les hacher et conserve un préfixe lisible : il reste stable et se raisonne plus facilement. Les défenseurs utilisent les deux pour regrouper les clients, repérer des outils qui détonnent dans un environnement et pivoter dans la threat intelligence. Une empreinte identifie une pile TLS, pas un logiciel malveillant.
Pourquoi prendre l'empreinte du TLS
Dans une capture, les charges utiles TLS sont chiffrées. Ce qui reste lisible, c'est la négociation, à commencer par le ClientHello. Il contient le nom du serveur (SNI), les protocoles applicatifs souhaités (ALPN) et une liste de choix qui dépendent de la bibliothèque TLS et de la manière dont l'application l'a configurée. Deux programmes différents utilisant deux bibliothèques différentes produisent rarement des ClientHello identiques ; le même programme sur de nombreuses machines, si.
Cela donne aux défenseurs un moyen de dire « ces 40 connexions viennent du même type de client » sans rien déchiffrer.
JA3 : cinq champs et un MD5
JA3, publié par des ingénieurs de Salesforce en 2017, concatène cinq champs du ClientHello sous forme de valeurs décimales :
TLSVersion,Ciphers,Extensions,EllipticCurves,EllipticCurvePointFormats
Les valeurs d'un même champ sont séparées par des tirets, les valeurs GREASE sont ignorées, et la chaîne entière est hachée en MD5. Son pendant côté serveur, JA3S, fait de même avec la version, la suite choisie et les extensions du ServerHello.
Voici le ClientHello de la capture d'exemple fictive de PCAP Parser, une session TLS 1.3 vers g.api.mega.co.nz :
771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,
0-23-65281-10-11-35-16-5-13-18-51-45-43-27,29-23-24,0
JA3 = 7f805430de1e7d98b1de033adb58cf46
Deux détails sautent aux yeux. La version vaut 771 (0x0303, TLS 1.2) alors que la session est en TLS 1.3 : JA3 lit le champ de version historique, et TLS 1.3 négocie sa vraie version dans l'extension supported_versions (43). Et la liste des extensions est prise dans l'ordre où le client l'a envoyée, ce qui est précisément la faiblesse de JA3.
Pourquoi l'ordre aléatoire des extensions a cassé JA3
Début 2023, les navigateurs Chromium ont commencé à permuter l'ordre des extensions TLS dans chaque ClientHello. L'objectif était d'empêcher serveurs et équipements intermédiaires de dépendre d'un ordre fixe, ce qui rend l'écosystème TLS plus difficile à faire évoluer. Fastly a mesuré l'effet : avec une quinzaine d'extensions, le nombre d'ordres possibles est tel que pratiquement chaque connexion obtient un nouveau JA3.
Le navigateur n'a pas changé ce qu'il propose, seulement l'ordre. Mais comme JA3 hache l'ordre, l'empreinte a cessé d'être un identifiant stable pour Chrome, Edge et les autres navigateurs Chromium. La documentation JA4 de FoxIO cite ce changement parmi les raisons de la nouvelle conception. Un contournement utilisé par certains outils consiste à trier les extensions avant de calculer JA3, mais cela produit une valeur différente de celle des flux de renseignement existants.
JA4 : trié, tronqué, lisible
JA4 comporte trois parties reliées par des tirets bas, a_b_c :
| Partie | Contenu |
|---|---|
| a (lisible) | protocole (t TCP, q QUIC, d DTLS), version TLS la plus haute, d si un domaine SNI est présent ou i sinon, nombre de suites, nombre d'extensions, premier et dernier caractère de la première valeur ALPN |
| b | 12 premiers caractères hexadécimaux du SHA-256 de la liste des suites, triée |
| c | 12 premiers caractères hexadécimaux du SHA-256 de la liste des extensions, triée, sans SNI ni ALPN, suivie des algorithmes de signature dans l'ordre d'envoi |
Les valeurs GREASE sont ignorées partout. La même session d'exemple donne :
t13d1514h2_8daaf6152771_bc9a4605e104
Lisez le préfixe : TLS sur TCP, version 1.3, SNI avec un domaine, 15 suites de chiffrement, 14 extensions, ALPN h2. Les deux autres sessions de l'exemple, issues du même client, donnent t13d1514h1_8daaf6152771_bc9a4605e104 : seule la partie ALPN change (http/1.1 devient h1), et les deux hachages sont identiques. C'est l'avantage pratique : vous pouvez comparer l'empreinte entière, seulement b et c, ou le préfixe, et voir d'un coup d'œil pourquoi deux valeurs diffèrent.
Comme les extensions sont triées, la permutation de Chromium n'affecte pas JA4. Et comme la version vient de supported_versions, TLS 1.3 apparaît comme 13 au lieu du 771 historique.
Côté licence : l'empreinte de client TLS JA4 est publiée sous licence BSD 3-Clause, tandis que les autres méthodes de la famille JA4+ relèvent de la FoxIO License 1.1. Consultez le dépôt avant d'intégrer JA4+ à un produit commercial.
JA3 et JA4 en un coup d'œil
| JA3 | JA4 | |
|---|---|---|
| Publication | 2017, Salesforce | 2023, FoxIO |
| Champs | version, suites, extensions, courbes, formats de points | protocole, version, type de SNI, compteurs, ALPN, suites, extensions, algorithmes de signature |
| Ordre | tel qu'envoyé | suites et extensions triées |
| Hachage | MD5 de la chaîne entière | SHA-256 tronqué pour deux parties, préfixe lisible |
| Version TLS 1.3 | champ historique (771) | supported_versions le plus élevé (13) |
| Stable malgré l'ordre aléatoire des extensions | non | oui |
| QUIC | non défini | défini (préfixe q) |
Comment les défenseurs utilisent les empreintes TLS
Regrouper les clients d'une capture
Regroupez les sessions TLS par JA4 et comptez les hôtes par valeur. Dans un réseau de bureau typique, la plupart des sessions viennent d'une poignée de piles de navigateurs et de systèmes d'exploitation. Une empreinte vue sur un seul poste, vers des destinations que rien d'autre ne contacte, mérite un examen attentif.
Repérer les incohérences
Si le trafic HTTP d'un hôte se présente comme un navigateur dans son user agent, mais que ses sessions TLS portent une empreinte typique d'une bibliothèque de langage de script, quelque chose d'autre que le navigateur établit des connexions. Le même raisonnement vaut pour un serveur qui se met soudain à ouvrir du TLS avec une nouvelle pile.
Pivoter avec le renseignement, prudemment
Les plateformes de threat intelligence et les rapports d'éditeurs publient des empreintes associées à des outils précis. Une correspondance est une piste, pas un verdict. Combinez-la avec le SNI, le JA3S du serveur, la réputation de la destination, la chronologie et les traces sur l'hôte. Notez toujours quelle variante d'empreinte un flux utilise (JA3 brut, JA3 trié, JA4).
Établir une référence de votre environnement
Dressez la liste des empreintes normalement vues sur votre réseau, par rôle d'hôte. Les nouvelles valeurs ressortent alors sans avoir besoin d'une liste externe.
Les limites à connaître
- Pas propres aux logiciels malveillants. Tout programme qui utilise la même bibliothèque avec les mêmes réglages a la même empreinte. La pile TLS intégrée de Windows, par exemple, est partagée par de nombreuses applications.
- L'imitation est possible. Il existe des bibliothèques qui reproduisent le ClientHello d'un navigateur. Une empreinte de navigateur ne prouve pas qu'il s'agit d'un navigateur.
- Encrypted Client Hello. Avec ECH (RFC 9849), le vrai ClientHello, y compris le vrai nom du serveur, est chiffré dans un ClientHello externe qui porte des valeurs anodines. Les observateurs prennent l'empreinte du message externe et voient un nom public, pas la destination réelle.
- QUIC. HTTP/3 s'appuie sur QUIC, où le ClientHello se trouve dans des paquets QUIC chiffrés. JA4 définit une variante
q, mais un outil doit décoder QUIC pour la calculer ; PCAP Parser ne décode pas encore QUIC.
Voir JA3 et JA4 dans une capture
PCAP Parser calcule JA3 (chaîne et MD5), JA4 et JA3S pour chaque session TLS qu'il trouve sur TCP, et les affiche avec le SNI, l'ALPN, la version proposée et la version négociée dans son onglet TLS. Filtrez sur une empreinte pour lister toutes les sessions qui la partagent, puis exportez la vue. La visite guidée montre la vue TLS, et le comparatif des outils liste d'autres outils qui calculent ces empreintes. Pour le versant résolution de noms de la même enquête, poursuivez avec l'analyse DNS dans un pcap.
FAQ
Quelle est la différence entre JA3 et JA4 ?
JA3 est un hachage MD5 de cinq champs du ClientHello, dans l'ordre où le client les a envoyés. JA4 est une empreinte en trois parties, en partie lisible, qui trie les suites de chiffrement et les extensions avant de les hacher en SHA-256 tronqué, et qui indique en clair le protocole, la version TLS, la présence du SNI, les compteurs et l'ALPN.
Pourquoi JA3 ne fonctionne-t-il plus pour Chrome ?
Depuis début 2023, les navigateurs Chromium mélangent l'ordre des extensions TLS dans chaque ClientHello. JA3 hache les extensions dans l'ordre d'envoi, donc le même navigateur produit un JA3 différent à presque chaque connexion. JA4 trie d'abord les extensions, donc sa valeur reste stable.
Une empreinte TLS identifie-t-elle un logiciel malveillant ?
Non, elle identifie une implémentation et une configuration de client TLS. Beaucoup de programmes sans rapport partagent la même bibliothèque et donc la même empreinte. Utilisez les empreintes pour regrouper et prioriser, et confirmez avec la destination, la chronologie, les traces sur l'hôte et d'autres indicateurs.