Une attaque Man-in-the-Middle (MITM) consiste à s’intercaler entre deux parties qui communiquent — deux machines, un utilisateur et un serveur, deux applications — pour écouter leurs échanges, les modifier, ou injecter du contenu malveillant. Les deux parties croient communiquer directement l’une avec l’autre. En réalité, tout passe par l’attaquant.

Ce type d’attaque existe depuis les débuts des réseaux. Sa réalisation pratique a beaucoup évolué avec la généralisation du HTTPS et du chiffrement de bout en bout — mais elle reste possible dans des contextes bien précis, et ses implications sont graves.

La mécanique d’une attaque MITM

Une attaque MITM se décompose en deux phases :

L’interception : l’attaquant se positionne sur le chemin des communications
Le déchiffrement ou la manipulation : l’attaquant lit ou modifie les données transitant

La difficulté principale est la phase d’interception. Plusieurs techniques existent selon le contexte réseau.

ARP Poisoning — l’interception sur réseau local

Comment fonctionne ARP

Le protocole ARP (Address Resolution Protocol) est utilisé sur les réseaux locaux Ethernet et Wi-Fi pour faire correspondre une adresse IP à une adresse MAC (l’identifiant physique de la carte réseau). Quand une machine veut communiquer avec 192.168.1.1, elle envoie une requête ARP en broadcast : “Qui a l’IP 192.168.1.1 ? Donne-moi ton adresse MAC.”

Le problème : ARP n’a aucun mécanisme d’authentification. N’importe quelle machine sur le réseau peut répondre à cette requête, vraie ou fausse.

L’attaque

L’attaquant envoie des réponses ARP non sollicitées (ARP gratuitous) à toutes les machines du réseau :

À la machine victime : “L’IP 192.168.1.1 (le routeur) correspond à MON adresse MAC”
Au routeur : “L’IP de la victime correspond à MON adresse MAC”

Les deux machines mettent à jour leur table ARP (cache). Désormais, tout le trafic entre la victime et le routeur transite par la machine de l’attaquant. Il peut le lire, le modifier, et le retransmettre — transparent pour les deux parties.

Des outils comme Ettercap, arpspoof ou Bettercap automatisent cette attaque en quelques commandes.

Ce que l’ARP poisoning permet de capturer

Sur un trafic non chiffré (HTTP, Telnet, FTP, certains protocoles applicatifs) : tout. Identifiants, mots de passe, données échangées, contenu des pages visitées.

Sur du HTTPS : l’attaquant voit le trafic chiffré, mais pas son contenu — à moins de combiner avec du SSL stripping.

SSL Stripping — dégrader HTTPS en HTTP

L’idée

Quand un utilisateur tape masite.fr dans son navigateur sans préciser https://, le navigateur commence souvent par une requête HTTP, puis est redirigé vers HTTPS par le serveur (301 Moved Permanently).

L’attaque SSL stripping intercepte cette redirection. L’attaquant maintient une connexion HTTPS chiffrée avec le serveur, mais sert à la victime une version HTTP non chiffrée. La victime voit le bon contenu du site, mais en clair — sans cadenas dans la barre d’adresse.

Les limites actuelles

La généralisation de HSTS (HTTP Strict Transport Security) a largement contrecarré le SSL stripping. HSTS est un en-tête HTTP que les serveurs envoient pour indiquer aux navigateurs de n’accepter que les connexions HTTPS pour ce domaine, pendant une durée définie.

La HSTS Preload List va plus loin : des domaines sont inscrits en dur dans les navigateurs (Chrome, Firefox, Safari, Edge) comme “toujours HTTPS”, avant même la première connexion. Un attaquant ne peut pas intercepter la première requête pour injecter du HTTP.

HSTS ne protège que si le site a préalablement été visité (ou figure sur la liste de préchargement). La première connexion à un site depuis une machine neuve reste potentiellement vulnérable si HSTS n’est pas préchargé.

Evil Twin Wi-Fi — le faux point d’accès

L’attaque

L’attaquant crée un point d’accès Wi-Fi avec le même SSID (nom de réseau) qu’un réseau légitime — le Wi-Fi d’un hôtel, d’un café, d’un aéroport. Les appareils configurés pour se connecter automatiquement à ce réseau s’y connectent sans interaction de l’utilisateur.

L’attaquant contrôle l’intégralité du trafic réseau sortant de ces appareils.

Des outils comme hostapd-wpe, airbase-ng ou Bettercap permettent de monter un Evil Twin en quelques minutes avec du matériel Wi-Fi standard.

Ce qui est capturé

Tout le trafic non chiffré. Sur les protocoles applicatifs qui font confiance au réseau. Potentiellement les requêtes DNS (même si la connexion finale est HTTPS, les résolutions DNS sont souvent en clair et révèlent les sites visités). Les cookies de session si un site les transmet sans l’attribut Secure.

MITM sur TLS : l’attaque par certificat

Pour intercepter du HTTPS, il faut un certificat

Pour que l’attaquant déchiffre les communications HTTPS, il doit présenter à la victime un certificat pour le domaine cible. Ce certificat doit être signé par une autorité de certification (CA) reconnue par le navigateur, sinon celui-ci affiche une alerte.

En contexte entreprise, les solutions de DLP et d’inspection SSL font exactement ça : le firewall installe un certificat racine de confiance sur tous les postes, ce qui lui permet d’inspecter le trafic HTTPS. C’est une MITM légitime et volontaire.

Un attaquant peut tenter la même chose si :

Il a compromis une machine et peut installer un certificat racine de confiance
Il a compromis une CA (rare, mais s’est produit — DigiNotar en 2011)
Il exploite une CVE sur un navigateur ou une bibliothèque TLS

Le Certificate Pinning

Le certificate pinning consiste à embarquer dans une application la clé publique ou le certificat exact attendu pour un serveur donné. Même si l’attaquant présente un certificat signé par une CA reconnue, la connexion est refusée s’il ne correspond pas au certificat épinglé.

Utilisé dans les applications mobiles et les clients lourds pour les communications critiques. Difficile à mettre en œuvre pour un navigateur web grand public.

MITM passif vs actif

MITM passif : l’attaquant écoute les communications sans les modifier. Difficile à détecter. Objectif : collecter des informations.

MITM actif : l’attaquant modifie les données en transit — injecter du contenu malveillant dans une page web, modifier un virement bancaire avant envoi, substituer un fichier téléchargé par un exécutable malveillant. Détectable si des mécanismes d’intégrité sont en place (signatures, hashes).

Les protections côté utilisateur et organisation

Ne pas faire confiance aux Wi-Fi publics pour des usages sensibles

Un VPN d’entreprise chiffre tout le trafic depuis l’appareil jusqu’au point de sortie VPN, rendant l’Evil Twin inopérant pour lire les données. Pour les connexions en déplacement, le VPN doit être obligatoire.

Surveiller les alertes certificat

Un navigateur qui affiche une alerte de certificat invalide ne doit jamais être ignoré. C’est souvent le seul signal visible d’une attaque MITM sur TLS.

HSTS et HSTS Preloading côté serveur

Pour les sites et applications web : activer HSTS avec une durée longue (max-age=31536000), inclure les sous-domaines (includeSubDomains), et soumettre le domaine à la liste de préchargement HSTS. Cela protège les utilisateurs même lors de leur première connexion.

Segmentation réseau et détection ARP

Sur les réseaux internes, la segmentation par VLAN limite la portée de l’ARP poisoning. Des solutions de détection d’ARP spoofing (IDS réseau, fonctions des switchs managés comme Dynamic ARP Inspection) permettent de détecter et bloquer ces attaques automatiquement.

Authentification mutuelle (mTLS)

Dans les architectures de microservices et les communications machine-à-machine, le mTLS (mutual TLS) impose que les deux parties présentent un certificat. Cela empêche un attaquant de se faire passer pour le serveur ou pour le client — les deux doivent prouver leur identité.

Les attaques MITM sont en recul sur les connexions HTTPS modernes bien configurées, mais restent pertinentes sur les réseaux locaux, les Wi-Fi publics, les protocoles applicatifs non chiffrés, et dans des contextes où le chiffrement est mal implémenté. La défense est multicouche : chiffrement correct, VPN, segmentation réseau et vigilance sur les alertes de certificat.

Sources : ANSSI, recommandations de sécurité pour les réseaux Wi-Fi ; RFC 6797 (HSTS) ; RFC 8446 (TLS 1.3) ; OWASP, attaques Man-in-the-Middle.