Files
Notebook/content/documentation/securité/ssl_bumping/ssl_bumping.md
Damien 2d8830960b
All checks were successful
Build and Deploy Hugo / Deploy Hugo Website (pull_request) Successful in 24s
Update documentation for clarity and consistency
Remove emojis and em dash separators
Simplify introductory sentences
Standardize section headings
2026-07-19 15:09:56 +02:00

10 KiB

title, date, weight, cascade
title date weight cascade
SSL Bumping : Comment analyser le trafic SSL 2025-06-22T20:00:00+02:00 3
type
docs

Introduction : Que se passe-t-il derrière le cadenas ?

L'icône du cadenas dans la barre d'adresse de votre navigateur est censée garantir que vos échanges sont chiffrés et illisibles par un tiers. Pourtant, dans de nombreux réseaux d'entreprise ou environnements scolaires, ce trafic est bel et bien analysé. Comment est-ce possible sans casser le chiffrement ?

C'est là qu'intervient le SSL Bumping (ou interception TLS). Loin d'être une simple technique de piratage, c'est un mécanisme couramment utilisé et légitime pour inspecter le trafic HTTPS.

Comprendre le SSL Bumping, c'est comprendre les limites du chiffrement de bout en bout dans certains contextes, et savoir comment les entreprises sécurisent (ou surveillent) leurs réseaux. Dans cet article, nous allons décortiquer le fonctionnement de cette technique et voir comment la mettre en place via un lab pratique : squid-ssl-bumping-lab.

Partie 1 : Le concept de l'interception TLS

Un "Man-in-the-Middle" assumé

Le principe du HTTPS est comparable à l'envoi d'un courrier dans un coffre-fort dont seuls l'expéditeur et le destinataire ont la clé. Si un équipement réseau (comme un proxy d'entreprise) a besoin d'analyser le contenu pour bloquer un malware ou empêcher une fuite de données, il se retrouve face à un mur : le trafic est chiffré.

Le SSL Bumping contourne ce problème en s'insérant au milieu de la communication :

SSL Bumping Expliqué

Le proxy va :

  1. Intercepter la connexion HTTPS du client.
  2. Déchiffrer le trafic pour l'analyser.
  3. Re-chiffrer les données avant de les envoyer au serveur final.

Au lieu d'avoir une seule connexion sécurisée entre votre navigateur et le site web, il y en a deux : une entre vous et le proxy, et une autre entre le proxy et le site. Le proxy agit comme un relais qui lit tout au passage.

[!NOTE] Question de vocabulaire On parle souvent de SSL Bumping (le terme historique utilisé par le proxy Squid), d'interception TLS (le terme techniquement exact aujourd'hui), ou d'inspection HTTPS. Dans tous les cas, il s'agit d'une attaque de type Man-In-The-Middle (MITM), mais réalisée de manière contrôlée et volontaire par l'administrateur du réseau.

Pourquoi inspecter le trafic chiffré ?

L'interception TLS répond à des besoins réels, principalement dans le monde professionnel :

  1. Sécurité réseau : Détecter les malwares téléchargés via HTTPS ou bloquer l'accès à des sites malveillants.
  2. Prévention des fuites de données (DLP) : S'assurer que des informations confidentielles ne sortent pas de l'entreprise.
  3. Filtrage et conformité : Bloquer certains contenus (réseaux sociaux, sites inappropriés) selon la politique de l'entreprise ou de l'établissement.
  4. Débogage : Analyser les requêtes API ou diagnostiquer des problèmes applicatifs complexes.

Bien sûr, cette visibilité totale implique une grande responsabilité, car le proxy a accès aux mots de passe, aux cookies de session et aux données personnelles.

Partie 2 : Comment ça marche techniquement ?

Pour s'insérer dans une connexion HTTPS sans que le navigateur ne bloque l'accès, le proxy doit réaliser un tour de passe-passe cryptographique.

Étape 1 : Le proxy devient une Autorité de Certification (CA)

Pour que le SSL Bumping fonctionne, le proxy doit être capable de générer des certificats à la volée pour n'importe quel site web. Pour cela, l'administrateur configure le proxy avec sa propre Autorité de Certification (CA) interne.

Étape 2 : La génération des certificats à la volée

Lorsque vous tentez d'accéder à https://www.example.com :

Génération des faux certificats

  1. Le proxy intercepte votre requête.
  2. Il se connecte au vrai serveur example.com et récupère son certificat légitime.
  3. Il génère instantanément un faux certificat pour example.com, signé par sa propre CA interne.
  4. Il présente ce faux certificat à votre navigateur.

[!TIP] Pourquoi le navigateur ne bloque-t-il pas la connexion ? Normalement, face à un faux certificat, votre navigateur affiche une grosse alerte de sécurité. Pour que l'interception soit transparente, le certificat de la CA du proxy doit être déployé et approuvé sur votre machine (souvent via les stratégies de groupe en entreprise, ou manuellement). C'est pour cela que l'on ne peut pas faire du SSL Bumping discrètement sur le réseau d'un inconnu.

Étape 3 : L'analyse en clair

Une fois les deux tunnels TLS établis (Client ↔ Proxy et Proxy ↔ Serveur), le proxy voit passer les requêtes HTTP en clair. Il a accès aux URL complètes, aux en-têtes, aux paramètres POST et au corps des réponses. Il peut alors appliquer ses règles de filtrage ou d'analyse antivirale.

Partie 3 : Mise en pratique avec Squid

Pour bien comprendre le mécanisme, rien ne vaut la pratique. J'ai préparé un environnement de test basé sur Squid, un proxy open-source très utilisé qui gère parfaitement le SSL Bumping : squid-ssl-bumping-lab.

Architecture du lab

Architecture du lab SSL

Déploiement rapide

  1. Clonez le dépôt :

    git clone https://gitea.arnodo.fr/Damien/squid-ssl-bumping-lab
    cd squid-ssl-bumping-lab
    
  2. Générez l'Autorité de Certification du lab :

    mkdir -p ssl
    openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 \
      -keyout ssl/squid-ca-key.pem \
      -out ssl/squid-ca-cert.pem \
      -subj "/CN=Squid CA/O=Mon Lab/C=FR"
    
  3. Lancez l'environnement :

    docker-compose up --build -d
    
  4. Configurez votre client :

    • Définissez le proxy HTTP/HTTPS sur localhost:3128.
    • Importez le fichier ssl/squid-ca-cert.pem dans les autorités de certification de confiance de votre navigateur ou de votre système.

[!WARNING] Avertissement de sécurité Ce lab est destiné à un usage éducatif. N'utilisez jamais cette CA en dehors de cet environnement de test et pensez à la supprimer de votre système une fois vos essais terminés.

Observer l'interception

Une fois la configuration terminée, naviguez sur quelques sites en HTTPS et consultez les logs de Squid :

docker-compose exec squid tail -f /var/log/squid/access.log

Vous constaterez que Squid enregistre les URL complètes des sites visités, prouvant qu'il déchiffre bien le trafic. Si vous cliquez sur le cadenas dans votre navigateur, vous verrez que le certificat du site est désormais émis par "Squid CA".

Partie 4 : Détection et alternatives

Comment savoir si l'on est intercepté ?

Si vous êtes sur un réseau d'entreprise, il est très probable que votre trafic soit inspecté. Pour le vérifier :

  1. Cliquez sur l'icône du cadenas dans votre navigateur.
  2. Affichez les détails du certificat.
  3. Vérifiez le champ "Émetteur" (Issuer). S'il s'agit du nom de votre entreprise ou d'un équipement réseau (comme Fortinet, Palo Alto, Zscaler) au lieu d'une autorité publique reconnue (Let's Encrypt, DigiCert...), votre trafic est intercepté.

Certaines applications utilisent le Certificate Pinning : elles intègrent en dur l'empreinte du certificat légitime du serveur. Si un proxy tente de présenter un faux certificat, l'application refusera simplement de se connecter, rendant l'interception impossible.

L'alternative : le filtrage SNI

Le SSL Bumping est lourd à gérer et pose des questions de confidentialité. Une alternative courante est le filtrage basé sur le SNI (Server Name Indication).

Lors de l'initialisation de la connexion TLS, le client indique le nom de domaine qu'il souhaite joindre en clair dans la requête initiale. Le proxy peut lire cette information sans avoir besoin de déchiffrer la suite du trafic. Cela permet de bloquer l'accès à certains domaines de manière beaucoup moins intrusive, même si l'on perd la visibilité sur l'URL complète et le contenu de la page.

Partie 5 : Enjeux légaux et bonnes pratiques

L'interception TLS n'est pas une décision technique à prendre à la légère. Elle implique d'avoir accès à des données potentiellement sensibles (identifiants personnels, données bancaires, informations de santé).

En entreprise, la mise en place du SSL Bumping doit s'accompagner de règles strictes :

  • Transparence : Les utilisateurs doivent être informés que leur trafic professionnel est analysé (généralement via la charte informatique).
  • Exceptions (Bypass) : Le proxy doit être configuré pour ne pas intercepter certaines catégories de sites, notamment les banques et les services de santé, afin de respecter la vie privée des collaborateurs.
  • Sécurité de la CA : La clé privée de l'autorité de certification interne doit être protégée de manière drastique. Si elle est compromise, un attaquant pourrait générer de faux certificats valides sur tout le parc informatique.

Conclusion

Le cadenas dans votre navigateur indique que la connexion est chiffrée, mais il ne garantit pas qu'il n'y a personne entre vous et le serveur final. Le SSL Bumping illustre bien le compromis permanent entre la sécurité globale d'un réseau et la confidentialité individuelle.

C'est une technique puissante et souvent indispensable en entreprise, mais qui exige une mise en œuvre rigoureuse et éthique. N'hésitez pas à utiliser le lab fourni pour expérimenter par vous-même et mieux comprendre les mécanismes sous-jacents de nos connexions quotidiennes.


Ressources utiles :