TLS ou tunnel VPN IPsec contre l’homme du milieu

TLS (Transport Layer Security) et IPsec (Internet Protocol Security) chiffrent des données en transit, mais pas au même endroit, ni contre les mêmes erreurs. Le compromis central est net : TLS protège l’application et son identité de bout en bout, IPsec protège le chemin réseau entre deux pairs, au prix d’une confiance forte dans les passerelles.

→ Lire l’explication complète de la marmotte

TLS, IPsec et homme du milieu : ce qui est réellement authentifié

Une attaque de l’homme du milieu, aussi appelée MITM (Man-in-the-Middle), consiste à intercepter, relayer ou modifier un échange en se faisant passer pour chaque extrémité. Chiffrer sans authentifier ne bloque pas cette attaque : un attaquant peut négocier deux canaux chiffrés distincts, un avec chaque victime, puis lire et modifier les données entre les deux. Un cadenas sans vérification du destinataire reste une boîte aux lettres très décorative.

TLS protège une session applicative, typiquement HTTPS (Hypertext Transfer Protocol Secure), LDAP sur TLS ou une API. Le client valide le certificat présenté par le serveur : chaîne de certification, nom de domaine, dates de validité, usages de clé et, selon le contexte, révocation. Avec mTLS (mutual TLS), le serveur valide aussi le certificat client. La protection suit alors le flux applicatif jusqu’au processus qui termine TLS.

IPsec protège des paquets IP (Internet Protocol) entre deux points de terminaison IPsec. En mode tunnel, une passerelle chiffre et encapsule les paquets destinés à un réseau distant. Le protocole IKE (Internet Key Exchange) authentifie les pairs et négocie les associations de sécurité, puis ESP (Encapsulating Security Payload) assure confidentialité, intégrité et anti-rejeu. L’identité vérifiée est celle de la passerelle, pas celle du serveur applicatif final.

Ce point tranche le débat : pour une API, une interface d’administration ou tout flux dont l’identité applicative compte, TLS reste obligatoire même si un tunnel IPsec existe. IPsec est un contrôle de transport et de segmentation, pas un substitut à l’authentification du service.

La page sur les tunnels, bastions et interconnexions protégées complète ce sujet pour le choix des topologies. Le modèle en couches expliqué dans couches, normes et vocabulaire réseau évite aussi de demander à une couche de réparer les fautes d’une autre. Ce genre de demande finit généralement dans une slide marquée « defense in depth », avec beaucoup de flèches et très peu de paquets valides.

Données non chiffrées avec TLS sans VPN IPsec

Avec TLS seul, les données applicatives sont chiffrées entre le client et le point de terminaison TLS. Un observateur réseau voit les adresses IP, les ports, le volume, le rythme des échanges et souvent le nom de serveur demandé pendant l’établissement. TLS 1.3 chiffre davantage d’éléments que ses prédécesseurs, mais ne rend pas le trafic invisible. Le réseau apprend qu’un échange existe, pas nécessairement son contenu.

Les données deviennent en clair au niveau du composant qui termine TLS : serveur web, proxy inverse, répartiteur de charge ou passerelle d’API. Si un proxy termine TLS puis parle HTTP en clair vers le backend, le tronçon interne transporte bien des données non chiffrées. Le chiffrement extérieur ne couvre alors plus ce tronçon. Le réseau interne n’acquiert pas soudainement des propriétés morales parce qu’il porte le mot « privé » dans un diagramme.

TLS seul est le choix recommandé pour les services accessibles depuis Internet et pour les flux interservices dont l’identité doit être vérifiée. Il impose les conditions suivantes :

TLS 1.3 doit être activé par défaut, TLS 1.2 restant réservé aux clients hérités avec suites AEAD (Authenticated Encryption with Associated Data), par exemple AES-GCM (Advanced Encryption Standard Galois/Counter Mode) ou ChaCha20-Poly1305.
La validation du nom de serveur et de la chaîne de certification ne doit jamais être désactivée. L’option -k de curl est un outil de diagnostic, pas une stratégie de confiance.
La terminaison TLS doit être cartographiée. Chaque saut après déchiffrement exige soit un réseau explicitement de confiance et segmenté, soit un nouveau canal TLS.
Les clés privées doivent rester hors des images de conteneur et des systèmes de fichiers partagés. Un HSM (Hardware Security Module) ou un service de gestion de clés réduit l’exposition, sans réparer une autorisation applicative absente.

TLS ne garantit ni l’autorisation métier, ni l’absence d’exfiltration par un client légitime, ni la sécurité du serveur une fois la session déchiffrée. Il ne masque pas non plus les métadonnées réseau. Pour les flux sensibles, ajouter filtrage, segmentation et journalisation, comme décrit dans filtrage, segmentation et NAC.

Données non chiffrées dans un VPN IPsec sans TLS

Avec IPsec en mode tunnel, les paquets circulant entre deux passerelles sont chiffrés sur le réseau intermédiaire. Un attaquant placé sur Internet ou chez un opérateur ne lit pas les flux internes encapsulés et ne les modifie pas sans être détecté. ESP inclut une vérification d’intégrité et un mécanisme anti-rejeu fondé sur des numéros de séquence.

Mais les données sont en clair avant l’entrée dans le tunnel et après sa sortie. Entre un serveur applicatif et la passerelle locale, puis entre la passerelle distante et le serveur cible, la confidentialité dépend du réseau local. Une compromission de passerelle est particulièrement coûteuse : elle expose potentiellement tous les flux transportés par le tunnel, pas seulement une application.

Un tunnel site à site sans TLS est acceptable uniquement pour des flux non exposés, entre zones réellement administrées, avec des passerelles durcies, une segmentation stricte et une authentification applicative indépendante. Cela couvre certains échanges de réplication ou des réseaux industriels hérités, mais n’offre pas d’identité cryptographique au serveur applicatif. Un hôte du réseau distant capable d’usurper une adresse ou d’atteindre le segment peut devenir le mauvais interlocuteur, tout en restant parfaitement « dans le VPN ».

IPsec doit utiliser IKEv2, des certificats ou des secrets partagés à forte entropie, PFS (Perfect Forward Secrecy) et des algorithmes modernes. Un secret partagé réutilisé pour dix tunnels transforme la compromission d’une passerelle en événement collectif. La rotation devient ensuite une séance de spéléologie dans des configurations oubliées, ce qui n’est pas une primitive cryptographique reconnue.

IPsec ne garantit pas que le bon processus reçoit les données, ne chiffre pas nécessairement les réseaux adjacents aux passerelles et ne remplace pas les règles de pare-feu. Les sélecteurs de trafic doivent être minimaux : annoncer 0.0.0.0/0 dans un tunnel intersites pour « simplifier » revient à déplacer le problème dans un paquet chiffré.

TLS dans IPsec : défense en profondeur, pas permission de relâcher

Combiner TLS et IPsec répond à deux objectifs distincts. IPsec réduit l’exposition sur le transport et limite les réseaux capables d’atteindre le service. TLS authentifie le service, protège les données jusqu’au point de terminaison applicatif et conserve cette protection si le chemin change.

Cette combinaison est justifiée pour les échanges entre sites, les administrations sensibles, les flux réglementés et les architectures où les passerelles réseau et les équipes applicatives n’ont pas le même périmètre de confiance. Elle paie deux fois certains coûts : gestion des certificats, dépannage des échecs de négociation, observabilité fragmentée et MTU (Maximum Transmission Unit) réduite par l’encapsulation. La fragmentation silencieuse dans un tunnel est un classique : tout fonctionne sur un test court, puis un transfert réel disparaît dans les marécages de Path MTU Discovery.

Le double chiffrement ne rend pas une application invulnérable. Si TLS se termine sur un proxy qui relaie en HTTP, IPsec ne protège ce HTTP que jusqu’à la passerelle distante. Si l’attaquant contrôle le proxy ou le serveur, les deux couches voient passer les données en clair. La frontière de déchiffrement doit donc être documentée et surveillée, pas seulement dessinée avec un cadenas bleu.

La recommandation est assumée :

Utiliser TLS pour tout protocole applicatif transportant une identité, un secret, une donnée métier ou une commande.
Ajouter IPsec pour interconnecter des réseaux, réduire la surface d’exposition et protéger les métadonnées de routage entre sites.
Ne jamais accepter IPsec seul comme preuve que l’application authentifie son correspondant.
Ne jamais accepter TLS seul comme preuve qu’un réseau interne est segmenté ou qu’un service non prévu est inaccessible.

Vérifier TLS et le transport IPsec

Un test de validation doit contrôler le certificat TLS et observer simultanément l’encapsulation IPsec. Le test suivant vérifie une API HTTPS avec une autorité de certification privée, puis capture les paquets ESP ou IKE sur l’interface exposée de la passerelle.

# Vérifier le certificat, le nom DNS et la chaîne de confiance de l'API.
# La commande échoue si api.exemple.interne ne correspond pas au certificat.
curl --fail --silent --show-error \
  --cacert ./ca-interne.pem \
  https://api.exemple.interne/health

# Observer uniquement le trafic de négociation IKE ou les paquets ESP.
# Exécuter sur l'interface WAN de la passerelle IPsec.
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500 or proto 50'

Le premier contrôle valide le service. Le second confirme l’existence du transport chiffré, pas le contenu ni l’autorisation applicative. Pour diagnostiquer une MTU, tester une charge sans fragmentation avec ping -M do sur IPv4, puis ajuster la MSS (Maximum Segment Size) TCP (Transmission Control Protocol) à la frontière du tunnel. Désactiver la découverte de chemin parce qu’un paquet est perdu n’est pas un correctif, c’est une demande officielle à la panne suivante.

Exploitation : clés, rotation, supervision et reprise

Les certificats TLS exigent un inventaire des noms de service, des émetteurs, des dates d’expiration et des points de terminaison. La révocation d’un certificat ne coupe pas les sessions TLS déjà établies : réduire la durée des certificats, limiter la durée des tickets de reprise de session et déployer un renouvellement automatisé réduit mieux cette fenêtre.

Les clés IPsec et les clés privées TLS doivent avoir des propriétaires distincts, des droits minimaux et une procédure de rotation testée. Sauvegarder une clé privée sans chiffrer la sauvegarde revient à créer une seconde production, moins surveillée et souvent plus bavarde. Les sauvegardes doivent inclure les certificats, chaînes, configurations de politique, identifiants de pairs et procédures de restauration, mais jamais exposer les secrets dans des dépôts de configuration.

Superviser les échecs de validation de certificat, les négociations IKE, les expirations à 30, 14 et 7 jours, les changements de suites cryptographiques et les volumes anormaux. Les journaux TLS et IPsec doivent être corrélés avec les flux réseau, sans journaliser les jetons, en-têtes d’autorisation ou données métier. Une capture de paquets est un excellent microscope et un exécrable coffre-fort.

🐝 Ce qui arrive si on s’en passe

Sans validation stricte des certificats ni tunnel correctement authentifié, l’homme du milieu n’a rien à casser : il présente son propre certificat, que le client accepte, ou s’installe sur un tronçon en clair derrière la passerelle. Le coût se mesure surtout après coup. Les journaux montrent des sessions chiffrées, ouvertes et fermées normalement, sans indiquer à qui le client parlait réellement, si bien que l’interception ne se distingue pas du trafic légitime. Tous les identifiants et jetons transmis pendant la période d’écoute doivent alors être tenus pour exposés et renouvelés, sans aucun moyen d’en restreindre la liste.

🦫 Explication de la marmotte 🍫

TLS protège une conversation entre un programme client et un programme serveur. Avant d’échanger des données, le serveur présente une preuve d’identité appelée certificat. Le client vérifie que cette preuve est encore valable, qu’elle a été émise par une autorité reconnue et qu’elle correspond bien au nom demandé. Les deux côtés créent ensuite des clés temporaires pour chiffrer la conversation. Si la vérification échoue, la connexion doit être arrêtée. Sinon, un attaquant peut se présenter comme le serveur.

IPsec protège les échanges entre deux équipements réseau, souvent deux passerelles reliant des sites. Les passerelles se reconnaissent d’abord, puis créent des clés et chiffrent les paquets qui traversent le réseau public. Une personne placée sur ce trajet ne peut pas lire ou modifier ces paquets sans provoquer une erreur.

Avec TLS seul, les données sont protégées jusqu’au serveur qui reçoit la connexion, mais le réseau voit encore qu’une communication existe. Avec IPsec seul, le trajet entre passerelles est protégé, mais les données redeviennent lisibles avant et après elles. Les deux protections ensemble couvrent à la fois la conversation du service et le trajet entre réseaux. Si un serveur, une passerelle ou une clé est compromis, le chiffrement ne protège plus les données à cet endroit : il faut alors limiter les accès, surveiller les événements et remplacer les clés.

Pages voisines

La citent

TLS ou tunnel VPN IPsec contre l'homme du milieu

Elle cite

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