1. Contexte et défis
Avec l’adoption massive de TLS 1.3, plus de 80 % du trafic web est aujourd’hui chiffré de bout en bout.
Cette évolution améliore la confidentialité mais complexifie la tâche des analystes réseau et des systèmes de détection d’intrusions (IDS).
Contrairement aux versions précédentes (TLS 1.2 et antérieures), TLS 1.3 chiffre presque intégralement la négociation, réduisant fortement les informations visibles.
L’inspection traditionnelle via déchiffrement (man-in-the-middle) est coûteuse, intrusive et souvent incompatible avec certaines politiques de confidentialité ou contraintes réglementaires.
Cet article détaille comment détecter des anomalies et menaces dans le trafic TLS 1.3 sans déchiffrement complet, en exploitant les métadonnées et le comportement réseau.
2. Métadonnées exploitables dans TLS 1.3
Même sans déchiffrement, certaines informations restent observables :
- SNI (Server Name Indication) : nom du serveur demandé, encore visible dans l’extension TLS ClientHello (sauf ESNI).
- Certificat serveur : domaine, validité, autorité de certification.
- ALPN (Application-Layer Protocol Negotiation) : protocole applicatif (ex : h2, http/1.1).
- JA3/JA3S : empreinte unique des paramètres TLS côté client et serveur.
- Taille et fréquence des paquets : modèle de trafic, utile pour la détection comportementale.
3. Empreintes TLS avec JA3 et JA3S
JA3 et JA3S permettent de créer une empreinte MD5 à partir des paramètres TLS visibles dans le ClientHello (JA3) et ServerHello (JA3S).
Ces empreintes identifient un client ou un serveur indépendamment du chiffrement.
Exemple : calcul d’une empreinte JA3 avec Zeek
zeek -i eth0 ja3
cat ssl.log | cut -f 9,10 | sort | uniq -c | sort -nr
On peut ainsi comparer les JA3 observés à une base de données de profils connus (malwares, outils de scan).
4. Analyse comportementale du trafic chiffré
Même sans contenu clair, on peut analyser :
- Durée des sessions : exfiltration lente = sessions longues avec flux régulier.
- Volume total échangé : flux anormalement élevé vers un domaine inhabituel.
- Fréquence des connexions : beaconing (connexions périodiques à un serveur C2).
- Destination : correspondance avec listes de domaines malveillants ou IP suspectes.
Exemple Suricata : détection de SNI suspect
alert tls any any -> any any (msg:"TLS SNI suspect"; tls_sni; content:"malicious.com"; nocase; sid:1000002; rev:1;)
5. Cas concret : détection d’un malware en TLS 1.3
Scénario : un poste infecté se connecte toutes les 10 secondes à un domaine inconnu via TLS 1.3.
- Capture du trafic avec
tcpdump -i eth0 port 443 -w capture.pcap - Analyse du SNI et empreintes JA3 avec Zeek
- Identification d’un JA3 inconnu dans la base interne
- Corrélation avec un schéma de beaconing → alerte SIEM
6. Intégration avec un SIEM
Les logs TLS (SNI, JA3, IP destination) peuvent être envoyés vers un SIEM comme Splunk ou ELK.
On peut créer des règles de corrélation :
- JA3 non répertorié + domaine inconnu = niveau de risque élevé
- Volume inhabituel + certificat auto-signé = alerte critique
7. Contre-mesures et durcissement
- Activer la journalisation TLS sur les IDS/IPS et routeurs.
- Maintenir une base à jour des JA3/JA3S connus (Cisco Talos, Abuse.ch).
- Bloquer ou inspecter les connexions vers des domaines nouvellement enregistrés.
- Utiliser DNS sur HTTPS/TLS interne pour contrôler les résolutions de noms.
8. Conclusion
L’inspection TLS 1.3 sans déchiffrement repose sur l’exploitation des métadonnées et du comportement réseau.
En combinant empreintes JA3, analyse statistique et corrélation SIEM, il est possible de détecter des menaces chiffrées avec un haut degré de précision, sans violer la confidentialité du contenu.
