Attaque de l’intercepteur par ARP, DHCP, DNS, Wi-Fi et proxy TLS

L’attaque de l’intercepteur (aussi appelée attaque de l’homme du milieu, ou MITM pour Man-in-the-Middle) n’est pas une technique mais une position : quelqu’un s’est glissé sur le chemin entre deux extrémités et relaie ce qu’il veut bien relayer. Cette page passe en revue les points d’insertion un par un, puis trace la frontière qui compte en architecture : ce que l’authentification des extrémités, typiquement TLS (Transport Layer Security), arrête pour de bon, et ce qu’elle laisse passer sans broncher.

→ Lire l’explication complète de la marmotte

Points d’insertion de l’intercepteur sur le chemin réseau

Un poste qui démarre pose quatre questions à son environnement : à qui remettre les trames, par où sortir, quel résolveur interroger, à quelle adresse correspond tel nom. Aucune de ces réponses n’est authentifiée par défaut. Chaque question est donc un point d’insertion.

Le schéma suivant liste les cinq points d’insertion dans l’ordre où la page les traite. Les deux premiers et le quatrième exigent d’être à portée du segment ou de la radio, le troisième peut se jouer de loin, le cinquième est installé par l’organisation elle-même.

La position défendue ici tient en une phrase : un réseau ne se rend pas digne de confiance, il se traite comme hostile, et la confidentialité se joue aux extrémités. Les protections de premier saut restent pourtant obligatoires, parce qu’elles couvrent exactement ce que l’authentification ne couvre pas : la disponibilité, les protocoles hérités et le repli vers le clair. Le compromis central est là. Authentifier partout coûte une infrastructure de certificats à exploiter ; verrouiller le chemin coûte de la configuration sur chaque commutateur. Faire l’un sans l’autre laisse un trou connu.

ARP et voisinage IPv6

ARP (Address Resolution Protocol) associe une adresse IP (Internet Protocol) à une adresse matérielle MAC (Media Access Control). Le protocole accepte les réponses non sollicitées et ne vérifie rien : n’importe quelle machine du même domaine de diffusion peut annoncer que l’adresse de la passerelle, c’est elle. ARP date de 1982 et croit tout ce qu’on lui dit, ce qui en fait le protocole le plus sociable de la pile.

La topologie ci-dessous montre le détour : le trafic du client passe par l’intercepteur avant d’atteindre la passerelle, sans qu’aucun équipement ne signale quoi que ce soit.

En IPv6 (Internet Protocol version 6), le rôle d’ARP est tenu par NDP (Neighbor Discovery Protocol), avec la même crédulité : une annonce de voisin falsifiée écrase l’entrée légitime. La variante signée du protocole existe sur le papier et quasiment nulle part ailleurs.

Contre-mesures : l’inspection ARP dynamique, ou DAI (Dynamic ARP Inspection), qui rejette toute réponse contredisant la table d’associations apprise par la surveillance DHCP ; son équivalent IPv6 (inspection du voisinage) ; l’isolation des ports clients entre eux ; et une segmentation qui réduit la taille du domaine de diffusion, traitée dans mouvement latéral et segmentation. Le détail des protocoles est dans résolution locale et ICMP.

Piège récurrent : la DAI dépend d’une table alimentée par DHCP. Un hôte en adressage statique n’y figure pas et se fait couper, sauf liste d’exceptions tenue à la main, donc périmée.

DHCP et annonces de routeur

DHCP (Dynamic Host Configuration Protocol) distribue l’adresse, la passerelle et le résolveur. Le client retient en général la première offre reçue : un serveur pirate qui répond plus vite que le légitime devient la passerelle et le résolveur du poste, sans rien empoisonner du tout. Deux options méritent une attention particulière. L’option 252 pousse l’adresse d’un proxy via WPAD (Web Proxy Auto-Discovery). L’option 121 injecte des routes statiques plus spécifiques que la route par défaut, y compris celle d’un tunnel VPN (Virtual Private Network) : le trafic sort alors hors du tunnel alors que le client VPN affiche toujours « connecté » (technique publiée en 2024 sous le nom TunnelVision, CVE-2024-3661).

Côté IPv6, l’annonce de routeur, ou RA (Router Advertisement), joue le même rôle et transporte aussi l’adresse du résolveur. Le piège est d’architecture : sur un réseau déclaré « IPv4 uniquement », les postes ont IPv6 actif par défaut, écoutent les annonces, sollicitent DHCPv6 et préfèrent IPv6 quand il répond. Le réseau qui route de l’IPv6 sans le savoir est un classique que vingt ans de métier n’ont pas réussi à démoder.

Contre-mesures : surveillance DHCP (seuls les ports déclarés de confiance émettent des offres), filtrage des annonces de routeur et des réponses DHCPv6 sur les ports d’accès (RA Guard, RFC 6105, RFC signifiant Request for Comments). Ce filtrage se contourne par fragmentation et en-têtes d’extension sur les implémentations anciennes (RFC 7113) : vérifier le comportement réel du matériel plutôt que la case cochée. Voir DNS, DHCP et NTP.

DNS

Le DNS (Domain Name System) offre trois hauteurs d’insertion, et c’est la seule famille qui ne demande pas d’être sur le segment.

Le résolveur du poste : remplacé via DHCP ou annonce de routeur, il répond ce qu’il veut.
La résolution locale de repli : quand le DNS échoue, les postes Windows interrogent le segment en multidiffusion avec LLMNR (Link-Local Multicast Name Resolution) et NBT-NS (NetBIOS Name Service). Qui répond le premier gagne, et récolte au passage une authentification NTLM (NT LAN Manager) relayable, décrite dans la page NTLM. Ces deux protocoles se désactivent ; rien de légitime ne devrait en dépendre.
L’amont : empoisonnement du cache d’un résolveur, ou modification des enregistrements chez le bureau d’enregistrement après vol du compte de gestion.

Ce dernier cas est le plus vicieux, parce qu’il casse l’authentification elle-même. Une autorité de certification (AC) qui délivre un certificat à validation de domaine, ou DV (Domain Validation), vérifie le contrôle du nom par DNS ou par HTTP (Hypertext Transfer Protocol). Qui tient la zone obtient donc un certificat parfaitement valide. Le cadenas s’affiche, le serveur est faux.

Contre-mesures : DNSSEC (DNS Security Extensions) signe les enregistrements, mais la validation se fait en général sur le résolveur, pas sur le poste, et ne chiffre rien. Les transports chiffrés DoT (DNS over TLS) et DoH (DNS over HTTPS) protègent le dernier tronçon entre poste et résolveur, pas la véracité de la réponse. Les deux se complètent. Pour l’amont : enregistrements CAA (Certification Authority Authorization) pour restreindre les AC autorisées, verrou de registre, et surveillance des journaux publics d’émission CT (Certificate Transparency) pour ses propres domaines.

Wi-Fi et faux point d’accès

Un point d’accès s’identifie par un nom de réseau, le SSID (Service Set Identifier), que n’importe qui peut diffuser. Un faux point d’accès au signal plus fort récupère les clients, et se retrouve passerelle, serveur DHCP et résolveur d’un seul coup. Ce que la sécurité radio y change dépend du mode.

Réseau ouvert : rien. Le poste qui mémorise un réseau ouvert s’y réassociera partout où ce nom est diffusé.
Clé partagée, WPA2 (Wi-Fi Protected Access 2) en mode PSK (Pre-Shared Key) : toute personne connaissant la clé peut monter un faux point d’accès, et déchiffrer le trafic d’un autre client dont elle a capté la poignée de main. Sur un réseau invité, « toute personne » inclut la machine à café.
WPA3 avec SAE (Simultaneous Authentication of Equals) : supprime le déchiffrement passif entre clients, pas le faux point d’accès monté par quelqu’un qui connaît le mot de passe.
802.1X avec EAP (Extensible Authentication Protocol) : le client authentifie le serveur RADIUS (Remote Authentication Dial-In User Service) par son certificat, à condition que le profil Wi-Fi impose l’AC émettrice et le nom du serveur. Sans cela, le faux point d’accès présente n’importe quel certificat et collecte les identifiants. EAP-TLS avec validation stricte, poussé par gestion de parc, est la seule configuration à recommander.

La protection des trames de gestion, ou PMF (Protected Management Frames), empêche la déconnexion forcée d’un client ; elle ne l’empêche pas de choisir le mauvais point d’accès. Détails dans Wi-Fi d’entreprise.

Proxy TLS d’entreprise

Le proxy de déchiffrement termine la session TLS du poste, en ouvre une seconde vers le serveur, et fabrique à la volée un certificat signé par une AC interne installée dans le magasin de confiance des postes. La plaquette parle de « visibilité » ; la description exacte est une attaque de l’intercepteur avec bon de commande. La seule différence avec la version hostile est la gouvernance, d’où quatre conséquences à assumer.

La validation du serveur est déléguée. Le poste ne voit plus le certificat d’origine. Si le proxy valide mal (chaîne, nom, révocation, versions et suites acceptées), tout le parc hérite de sa faiblesse sans aucune alerte. Une étude académique de 2017 (The Security Impact of HTTPS Interception) a mesuré que la majorité des produits testés dégradaient la sécurité des connexions.
La clé de l’AC d’interception est un passe-partout. Quiconque l’exfiltre peut usurper n’importe quel site auprès de n’importe quel poste du parc. Elle vit dans un HSM (Hardware Security Module), voir module cryptographique matériel et PKCS#11, ou elle ne devrait pas exister.
Des garde-fous sautent côté client. Les navigateurs exemptent les ancres installées localement de l’épinglage de clé et des exigences CT.
Des protocoles cassent. L’authentification mutuelle mTLS (mutual TLS) ne traverse pas, les applications à certificat épinglé non plus ; QUIC, le transport de HTTP/3, est en général bloqué pour forcer le repli ; ECH (Encrypted Client Hello) est incompatible par construction.

Recommandation : ne pas déchiffrer par défaut. L’interception se justifie quand une obligation de contrôle du contenu sortant existe et qu’aucun agent sur le poste ne voit déjà ce contenu. Elle exige alors une clé en HSM, une validation amont testée, une liste d’exclusions maintenue (flux mTLS, catégories sensibles) et un périmètre documenté. Sans ces conditions, elle retire plus de sécurité qu’elle n’en apporte.

Ce que l’authentification des extrémités arrête

Un échange de clés non authentifié ne protège de rien face à un intercepteur actif : celui-ci négocie un secret avec chaque côté et relaie entre les deux, comme détaillé dans établir une clé avec Diffie-Hellman. L’authentification ferme cette porte en liant l’échange à une identité.

Dans TLS 1.3, le serveur signe avec sa clé privée la transcription complète de la poignée de main, clés éphémères comprises. Sans cette clé privée, l’intercepteur ne peut pas produire la signature ; s’il présente son propre certificat, il lui faut une chaîne vers une ancre du magasin de confiance du client. Résultat, sous réserve que ce magasin soit sain :

lecture du contenu : arrêtée (clés de session inconnues de l’intercepteur) ;
modification, injection, rejeu : arrêtés (chiffrement authentifié, numéros de séquence), à l’exception des données anticipées 0-RTT, rejouables par construction ;
rétrogradation de version : arrêtée (TLS 1.3 place un marqueur dans l’aléa du serveur et couvre toute la négociation par le message de fin) ;
avec mTLS, usurpation du client : arrêtée, y compris par un proxy de déchiffrement, d’où l’incompatibilité citée plus haut.

Une précision qui change les architectures : l’authentification porte sur un nom, pas sur une intention. Un proxy d’hameçonnage posé sur un domaine ressemblant, avec un certificat valide pour ce domaine, passe tous les contrôles et relaie mot de passe, code à usage unique et jeton de session (voir ingénierie sociale et accès initial). Seule une authentification liée à l’origine, type WebAuthn, refuse de répondre au mauvais nom. Les fondamentaux de la chaîne de certification sont dans PKI et TLS.

Ce que l’authentification des extrémités laisse passer

Vendre TLS comme réponse à l’interception revient à confondre enveloppe scellée et courrier livré. Voici ce qui reste.

Ce qui passe	Pourquoi	D’où doit venir le reste
Métadonnées	Adresses, ports, tailles, horaires, question DNS et nom du serveur dans le SNI (Server Name Indication) restent visibles	DoT ou DoH, ECH quand il est disponible, tunnel vers un point de sortie de confiance
Blocage et retard	La disponibilité n’est pas une propriété de TLS : l’intercepteur coupe, ralentit ou filtre sélectivement	Protections de premier saut, chemins redondants, supervision
Repli vers le clair	Si le clair est accepté, l’intercepteur supprime l’offre de chiffrement	Politiques qui interdisent le clair
Terminal ou magasin de confiance compromis	Une ancre ajoutée valide tous les faux certificats	Inventaire des ancres, durcissement du poste
Alerte acceptée	Le contrôle a fonctionné, l’humain a cliqué	Suppression du contournement
Premier contact	Rien à comparer la première fois	Distribution préalable des clés

Blocage sélectif. L’intercepteur ne lit rien mais choisit ce qui arrive. Bloquer les mises à jour fige un poste dans un état vulnérable. Bloquer la vérification en ligne de révocation OCSP (Online Certificate Status Protocol) suffit souvent à faire accepter un certificat révoqué, parce que la plupart des clients échouent ouverts. Falsifier l’heure via NTP (Network Time Protocol), rarement authentifié, ressuscite un certificat expiré.

Repli vers le clair. Une première requête en HTTP se réécrit avant la redirection vers HTTPS (HTTP over TLS) : c’est la raison d’être de HSTS (HTTP Strict Transport Security), qui interdit le clair pour un domaine, et de sa liste préchargée pour couvrir la première visite. En messagerie, SMTP (Simple Mail Transfer Protocol) négocie le chiffrement par la commande STARTTLS : l’intercepteur la retire de la réponse et le courrier part en clair, sauf politique MTA-STS (Mail Transfer Agent Strict Transport Security). En interne, tout protocole qui accepte encore le clair ou une authentification non liée au canal est concerné : voir désactiver le simple bind LDAP en clair, LDAP signifiant Lightweight Directory Access Protocol. Un relais NTLM n’a pas besoin de lire quoi que ce soit : il transporte l’authentification d’une victime vers un service qui n’exige ni signature ni liaison au canal.

Alerte acceptée. L’avertissement de certificat est le seul contrôle de sécurité dont le contournement est proposé par un bouton sur la même page. HSTS retire ce bouton. À l’inverse, chaque service interne en certificat autosigné entraîne les utilisateurs à cliquer : c’est une formation à l’attaque, dispensée gratuitement.

Premier contact. Le modèle TOFU (Trust On First Use) de SSH (Secure Shell) fait confiance à la première clé vue, puis détecte les changements. Un intercepteur présent ce jour-là est adopté comme légitime. Sur un parc reconstruit en permanence, chaque connexion est une première fois. Remèdes : certificats d’hôte SSH signés par une AC interne, ou empreintes distribuées par la gestion de configuration.

Exemple : chemin d’une connexion depuis un Wi-Fi non maîtrisé

La séquence suit un poste qui rejoint un réseau sans fil au nom connu, puis ouvre un site. Chaque ligne indique entre crochets ce que l’intercepteur obtient.

Lecture : sur sept étapes, l’authentification du serveur n’agit qu’aux deux dernières. Les cinq premières se jouent avant elle, et trois moments (la résolution, la première requête, la réaction à l’alerte) décident si elle ira à son terme. Un tunnel VPN monté dès l’association déplace le problème vers le point de sortie, sous réserve des routes injectées vues plus haut ; la comparaison des tunnels est dans TLS et VPN IPsec.

Pour savoir depuis un poste qui signe réellement le certificat reçu, et donc repérer un déchiffrement en chemin, comparer l’émetteur et l’empreinte SHA-256 du certificat présenté (visibles dans le navigateur) avec ceux relevés depuis un réseau de référence. Un émetteur interne là où une AC publique est attendue désigne le proxy ; un émetteur inconnu désigne un problème.

Prérequis, exploitation et détection des contre-mesures d’interception

Prérequis. Des commutateurs d’accès administrables qui prennent en charge surveillance DHCP, inspection ARP et filtrage IPv6 de premier saut ; une AC interne pour les services internes et pour 802.1X ; une gestion de parc capable de pousser profils Wi-Fi et magasins de confiance. Sans gestion de parc, la validation du certificat RADIUS repose sur une case que l’utilisateur coche.

Exploitation.

La table de surveillance DHCP doit être persistée hors mémoire vive. Après un redémarrage de commutateur, une table vide combinée à l’inspection ARP coupe tous les postes jusqu’au renouvellement de leur bail.
Les ports de confiance (liaisons montantes, serveurs DHCP) sont à auditer : un port d’accès resté « de confiance » après un déménagement de baie annule la protection sur tout le segment.
Le magasin de confiance des postes s’inventorie comme un secret : toute ancre absente de la référence est un incident jusqu’à preuve du contraire.
L’AC d’interception a une durée de vie, une procédure de rotation et un plan de révocation testé. Sa compromission impose de la retirer de tous les postes, ce qui se prépare avant.
Le préchargement HSTS est quasi irréversible à court terme : tous les sous-domaines doivent servir HTTPS avant l’inscription.

Détection. Les signaux existent, encore faut-il les collecter : rejets de l’inspection ARP, offres DHCP ou annonces de routeur vues sur un port d’accès, changement d’adresse matérielle de la passerelle, point d’accès inconnu diffusant un SSID interne, certificat émis pour un domaine de l’organisation dans les journaux CT sans demande correspondante, émetteur inattendu constaté depuis un poste. Leur intégration relève de la théorie de la détection et du SIEM, SIEM signifiant Security Information and Event Management. Un intercepteur qui se contente de relayer ne laisse aucune trace sur les extrémités : la détection est réseau ou elle n’est pas.

FAQ

Un VPN suffit-il contre l’attaque de l’intercepteur sur un réseau non maîtrisé ?

Il protège le tronçon local à deux conditions : le client authentifie la passerelle par certificat, et le poste refuse tout trafic hors tunnel, routes poussées par le réseau local comprises. Le VPN ne supprime pas l’intercepteur, il déplace le point de confiance vers la sortie du tunnel.

DNSSEC rend-il TLS superflu, ou l’inverse ?

Non dans les deux sens. DNSSEC garantit que la réponse vient bien de la zone, sans chiffrer ni authentifier le serveur atteint. TLS authentifie le serveur, mais repose sur des certificats dont l’émission dépend du DNS. L’un protège la fondation de l’autre.

Le déchiffrement TLS d’entreprise est-il compatible avec TLS 1.3 ?

Oui pour un proxy actif qui termine les deux sessions. L’écoute passive avec la clé privée du serveur ne fonctionne plus, puisque TLS 1.3 impose des clés éphémères.

🐝 Ce qui arrive si on s’en passe

Sans protection de premier saut ni authentification imposée, chaque prise réseau et chaque poste compromis devient une passerelle potentielle pour ses voisins. Les protocoles internes qui tolèrent encore le clair livrent leurs identifiants à qui se déclare routeur. Les journaux des serveurs attribuent les actions relayées au compte de la victime, et l’enquête ne distingue plus l’utilisateur légitime de celui qui parlait à sa place. Les mises à jour récupérées sans vérification de signature peuvent être remplacées en transit. Comme l’intercepteur ne touche à aucune extrémité, aucun agent sur les postes ne remonte d’alerte : l’incident se découvre par ses effets, longtemps après son début.

🦫 Explication de la marmotte 🍫

Quand un appareil envoie des données, il ne connaît pas le chemin : il demande au réseau local à quelle machine remettre ses messages, quelle porte de sortie utiliser et à quelle adresse correspond un nom de site. Aucune de ces réponses n’est vérifiée par défaut. Une machine malveillante branchée sur le même réseau, ou une fausse borne sans fil, peut donc répondre à la place des vraies et recevoir tout le trafic, qu’elle lit, modifie, puis transmet. La parade principale consiste à ce que le site prouve son identité avec une clé secrète que lui seul détient, preuve contrôlée grâce à une liste d’organismes de confiance stockée sur l’appareil. Si la preuve est valide, le contenu devient illisible et toute modification est détectée. Cette protection a des limites. L’intercepteur voit toujours qui parle à qui, quand, et en quelle quantité. Il peut bloquer ou ralentir. Il peut pousser l’appareil vers une connexion non protégée si rien ne l’interdit. Et tout s’effondre si la liste de confiance a été modifiée, si l’utilisateur ignore l’avertissement, ou si la toute première connexion a été acceptée sans vérification. D’où la nécessité de protéger aussi le réseau local et de surveiller les appareils.

Pages voisines

La citent

Attaque de l'intercepteur par ARP, DHCP, DNS, Wi-Fi et proxy TLS

Elle cite

: les deux pages se citent l’une l’autre.