TLS (Transport Layer Security) est un protocole qui chiffre l'ensemble du trafic internet et répond à vos besoins en cybersécurité. Il utilise des algorithmes cryptographiques pour chiffrer les communications web entre un serveur et ses clients. Cette technique est conçue pour sécuriser la connexion côté serveur, permettant aux serveurs d'identifier le client avec un degré de précision élevé, dès le premier paquet. Pour approfondir la sécurité TLS, commençons par comprendre son fonctionnement et ce qu'est le handshake TLS.
Pour une vue d'ensemble, consultez Qu'est-ce que l'empreinte TLS. Contournez les contrôles TLS avec le contournement anti-bot ou notre glossaire empreinte TLS.
Handshake TLS : comment ça fonctionne ?
Le handshake TLS est le processus qui chiffre et sécurise la connexion des deux côtés, client et serveur simultanément. Lorsqu'un client accède à un site chiffré TLS, il effectue un handshake TLS avec le serveur ; le handshake correspond au processus d'identification du client. Le processus commence par une requête du client pour initier la session sécurisée du site web. Cette session d'accès sécurisé est appelée session « hello » pour simplifier. TLS étant un protocole de chiffrement évolutif, il existe plusieurs versions avec un large éventail d'options de chiffrement (également appelées cipher suites). Le client (navigateur, script ou autre) envoie au serveur une liste de méthodes de chiffrement supportées ou cipher suites et la version TLS actuelle dans le message « Client Hello » pour initier la requête. Le serveur analyse ensuite la liste avec ses propres chiffrements supportés et renvoie le message « Hello » contenant le protocole TLS, la cipher suite choisie et le certificat SSL incluant la clé publique de chiffrement. Ensuite, le client utilise la clé publique du certificat SSL et vérifie son exactitude (le nom du serveur doit correspondre au DNS du certificat, et celui-ci ne doit pas être expiré). Après une vérification complète, le client envoie une autre chaîne aléatoire (appelée premaster secret) chiffrée avec la clé publique du serveur, que le serveur déchiffre avec la clé privée ; client et serveur génèrent alors une clé de session à partir du random client, du random serveur et du premaster secret. Ces valeurs doivent être identiques, et enfin serveur et client envoient un message « finished » chiffré avec la clé de session. Lorsque client et serveur sont sécurisés, on peut dire que le handshake TLS est terminé. Voici un diagramme représentant l'ensemble du processus.
Bibliothèque TLS : reconnaître le client utilisateur
Le Client Hello est en réalité une liste de chiffrements supportés par le client ; chacun utilise une bibliothèque TLS différente, listées ici avec leurs différences notables :
Grâce à l'empreinte TLS, le serveur peut identifier la bibliothèque TLS utilisée par le client et la comparer aux résultats attendus ; chaque bibliothèque est différente et supporte des chiffrements dans un ordre distinct. Les clients web peuvent être facilement distingués selon leur signature TLS. Il faut garder à l'esprit que cette information est disponible dès la première session (ou le premier paquet), que le serveur voit avant même de répondre au client. De plus, tant que le standard Encrypted Client Hello ne sera pas généralisé, cette information reste accessible à tout réseau tiers qui peut l'inférer.
Un client peut modifier la chaîne User-Agent (pour simuler un autre navigateur) mais le message Hello peut parfois révéler sa version réelle et son système d'exploitation ; certains navigateurs contiennent une liste de chiffrements préférés différente (comme Chrome 81 et 93).
Implémentation open source et méthodes de calcul de signature
JA3
La méthode la plus populaire d'empreinte TLS (ou calcul de signature) est JA3. Développée par une équipe Salesforce et open-sourcée en 2017 (blog Salesforce). Elle prend le paquet Client Hello et produit un hash MD5 identifiant le client pendant le handshake TLS. Les composants extraits du paquet sont la version TLS, les chiffrements acceptés, la liste des extensions, la courbe elliptique et ses formats. Après extraction, ces champs sont combinés dans l'ordre, séparés par des virgules pour les champs et des tirets pour les valeurs, puis la chaîne résultante est convertie en hash MD5. JA3 reste largement utilisé, bien que JA4 soit de plus en plus courant pour les stacks TLS 1.3 modernes.
JA3S
Utilisé pour l'implémentation côté serveur de la communication SSL ou TLS, il accompagne JA3 focalisé côté client et aide à juger de la légitimité et de l'exactitude d'une application. L'empreinte est générée à partir des champs du message Server Hello, comme la version TLS, les chiffrements et les extensions. JA3 et JA3S offrent une protection contre la possibilité qu'un malware génère le même hash MD5 qu'une application légitime.
L'implémentation de référence se trouve dans salesforce/ja3.
JA4
JA4 est un format d'empreinte client TLS plus récent (FoxIO, 2023+) qui encode la version TLS, l'usage SNI, le nombre de chiffrements/extensions, ALPN et des hash SHA256 tronqués: par exemple t13d1516h2_8daaf6152771_d8a2da3f94cd. Il est largement utilisé aux côtés de JA3 dans les discussions anti-bot et scraping.
- Spécification et contexte : JA4+ network fingerprinting (FoxIO)
- Capturer des valeurs réelles : tls.peet.ws
- Décoder les chaînes : Décodeur JA4 (outil gratuit Piloterr toolbox)
Notre Analyseur de capture TLS extrait JA3 et JA4 depuis le JSON tls.peet.ws.
TS1
Cette méthode d'empreinte TLS fonctionne différemment, en créant un hash unique pour chaque signature TLS. Inspirée initialement de JA3, elle est aujourd'hui plus complète. Elle encode tous les paramètres du message Client Hello au format JSON, puis calcule son hash SHA1 pour produire la signature. Dans cette méthode, différents clients ont des hash uniques pouvant être stockés en base pour comparer facilement les signatures. Ces signatures encodent plus de paramètres que JA3 pour représenter une image plus précise du client au serveur. Grâce au format JSON, cette méthode est plus « future-proof » pour les extensions TLS futures encore inexistantes.
Utilité de l'empreinte TLS : où est-elle utilisée ?
Le cas d'usage le plus courant de l'empreinte TLS est la protection anti-bot et anti-DDoS, pour protéger les pages web des attaques de crawling. Certaines personnes l'utilisent aussi pour des campagnes de phishing (usage illégitime, bien entendu). Scénarios courants :
Détection et protection contre les bots
Une application programmée ou conçue pour effectuer des actions spécifiques sur d'autres appareils, souvent à l'origine de cyberattaques. Dans certains scénarios à grande échelle, un réseau d'appareils est utilisé pour des cyberattaques massives, appelé botnet. Les chercheurs ou professionnels peuvent les tracer pour identifier leurs points communs, comme un malware, et partager les résultats avec la communauté sécurité sous forme d'IOCs.
Après identification d'un bot, vous pouvez bloquer son IP ou faire appel à un organisme de protection anti-bot (professionnels), ou implémenter un CAPTCHA pour protéger vos ressources.
Protection DDoS
Le DDoS (Distributed Denial of Service) vise à submerger un site cible avec du trafic indésirable. Ces attaques utilisent aussi des botnets. Une fois la montée de trafic détectée, examinez le client hello de tous les appareils connectés. Si les champs client hello sont identiques sur tous les appareils, ils sont probablement infectés par le même malware. Vous pouvez alors bloquer toutes leurs adresses IP pour protéger votre site.
Contrôle de vos signatures TLS
La plupart du temps, les paramètres du message client hello TLS ne sont pas contrôlables par les outils ou scripts, mais en Python, vous pouvez contrôler la liste des cipher suites. Certaines méthodes offrent un contrôle complet sur les signatures TLS :
- Puppeteer Extra: automatisation Chrome headless
- curl-impersonate: impersonation TLS navigateur
- uTLS: impersonation TLS en Go
- reqwest-impersonate: impersonation TLS en Rust (voir aussi wreq)
- JA3Transport: bibliothèque Go pour TLS au format JA3
Conclusion
L'empreinte TLS gagne en popularité et est devenue extrêmement courante sur le web pour des usages légitimes comme le blocage des attaques DDoS et la protection anti-bot, mais elle rend aussi le web moins ouvert au public et plus restrictif envers certains clients. Les outils pour protéger les clients en falsifiant la signature TLS restent imparfaits et immatures ; leur développement reste crucial pour un web plus libre, accessible et ouvert. La meilleure solution viendrait des bibliothèques TLS elles-mêmes, en offrant un contrôle plus fin aux utilisateurs pour se protéger et sécuriser leurs sites. Quatre axes d'amélioration pour une base d'utilisateurs plus saine :
- Permettre aux utilisateurs de contrôler les extensions TLS
- Permettre aux utilisateurs de contrôler la liste exacte des chiffrements
- Supporter les dernières extensions utilisées par certains navigateurs
- Rendre le processus de vérification plus privé pour éviter les usages négatifs
- Fournir un support pour les nouveaux langages de programmation émergents
Consultez aussi Ressources empreinte pour les sites de test, bibliothèques et outils Piloterr toolbox.
