---
title: "SSL Bumping : Comment analyser le trafic SSL"
date: 2025-06-22T20:00:00+02:00
weight: 3
cascade:
  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](https://gitea.arnodo.fr/Damien/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é](images/ssl_bumping_explique.fr.svg#center)

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](images/generation_des_faux_certificats.fr.svg)

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](https://gitea.arnodo.fr/Damien/squid-ssl-bumping-lab).

### Architecture du lab

![Architecture du lab SSL](images/architecture_du_lab_ssl.fr.svg)

### Déploiement rapide

1. **Clonez le dépôt** :
   ```bash
   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** :
   ```bash
   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** :
   ```bash
   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 :

```bash
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 :**
- 🧪 [Le lab Squid SSL Bumping](https://gitea.arnodo.fr/Damien/squid-ssl-bumping-lab)
- 📖 [Documentation officielle Squid sur le SSL Bump](http://www.squid-cache.org/Doc/config/ssl_bump/)
- 🔐 [Recommandations de l'OWASP sur l'inspection TLS](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html)
