Wi-Fi public : la paranoïa raisonnable

Un consultant me montre fièrement son setup dans le lobby d’un hôtel à Singapour : VPN gratuit installé la veille, parce qu’il « ne fait jamais confiance au Wi-Fi des hôtels ». Pendant qu’il me parle, son téléphone est en train de pousser ses contacts vers le serveur d’analytics du fournisseur de VPN gratuit. Le réseau de l’hôtel, lui, était parfaitement banal. La menace qu’il craignait n’existait pas ; celle qu’il avait invitée tournait dans sa poche.

Le piège habituel

Le discours dominant sur le Wi-Fi public oscille entre deux caricatures, et les deux vous desservent. La première, celle des années 2010, qui survit dans les formations de sensibilisation copiées-collées : « le Wi-Fi public est mortellement dangereux, n’ouvrez jamais vos mails depuis un café, un pirate peut tout voir ». Cette peur a une racine réelle — en 2014, intercepter une session sur un réseau ouvert tenait de la démonstration de magie pour débutant — mais elle décrit un internet qui n’existe plus. À l’époque, la majorité du trafic web circulait en clair. L’extension Firesheep, en 2010, permettait à n’importe qui de voler les sessions Facebook des voisins de table en deux clics. C’est ce monde-là qui a façonné le réflexe « Wi-Fi public = danger absolu ».

La seconde caricature est l’inverse exact, et elle gagne du terrain : « HTTPSVersion sécurisée de HTTP, qui chiffre la communication entre navigateur et serveur via TLS.Voir le lexique est partout maintenant, tout est chiffré, le Wi-Fi public ne pose plus aucun problème ». C’est faux dans l’autre sens. HTTPS a effectivement fait s’effondrer la surface d’attaque historique, mais il ne couvre pas tout, et certains vecteurs résiduels sont précisément ceux que personne ne surveille parce qu’on a décrété le sujet réglé.

La position juste n’est ni la panique ni l’insouciance. C’est la paranoïa raisonnable : savoir exactement ce qui est protégé aujourd’hui, ce qui ne l’est pas, et calibrer son comportement en fonction du contexte réel — un café à Lyon n’est pas le Wi-Fi d’une conférence sectorielle à Shenzhen. Le problème des deux discours dominants, c’est qu’ils proposent une règle absolue. Or il n’y a pas de règle absolue. Il y a un modèle de menace, et il dépend de qui vous êtes et d’où vous êtes.

Ce que HTTPS a réellement changé — et ce qu’il n’a pas touché

Soyons précis sur la mécanique, parce que c’est de là que découle tout le reste. Avant la généralisation de HTTPS — disons avant 2018 pour la masse critique — un attaquant présent sur le même réseau pouvait lire le contenu exact de vos pages, capturer vos identifiants en clair, injecter du code dans les pages visitées, et voler vos cookies de session pour usurper votre identité. C’était trivial. Aujourd’hui, plus de 95 % du trafic web chargé dans Chrome et Firefox est en HTTPS. Le contenu transite chiffré de bout en bout entre votre navigateur et le serveur. Un attaquant qui sniffe le Wi-Fi du café voit du bruit chiffré vers des adresses IP. Il ne lit pas votre mail Gmail, il ne vole pas votre mot de passe sur une connexion HTTPS valide.

C’est un progrès massif, réel, et il faut le dire clairement : envoyer un mail professionnel depuis le Wi-Fi d’un hôtel, sur une session HTTPS valide, ne compromet pas le contenu de ce mail. Ce n’est pas une approximation rassurante, c’est la réalité cryptographique. La peur générique « on peut tout voir » est obsolète.

Mais HTTPS ne chiffre pas tout, et c’est là que la nuance compte. Ce qu’il laisse fuiter, même quand il fonctionne parfaitement : les métadonnées de connexion. L’observateur sur le réseau ne voit pas le contenu de votre session bancaire, mais il voit que vous parlez au domaine de votre banque, à quelle heure, pendant combien de temps, et avec quel volume. Cette fuite passe par deux canaux : le DNSSystème qui résout les noms de domaine en adresses IP. Vecteur de surveillance et de censure très sous-estimé.Voir le lexique, si vos requêtes de résolution de noms partent en clair — ce qui reste le défaut sur beaucoup de configurations — et le champ SNI (Server Name Indication) du handshake TLSProtocole de chiffrement de transport, base de HTTPS et de la sécurité web moderne.Voir le lexique, qui annonce en clair le nom du serveur visité au tout début de la connexion chiffrée. Encrypted Client Hello (ECH) commence à fermer ce dernier trou, mais son déploiement reste partiel en 2026.

Au-delà des métadonnées, plusieurs catégories de trafic échappent encore à la protection HTTPS. Les portails captifs, par construction, sont servis en clair. Certaines applications mobiles font encore des appels d’APIDonnées sur les données : qui a écrit quoi, quand, où, à qui.Voir le lexique internes, d’analytics ou de mise à jour en HTTP non chiffré — la généralisation côté navigateur ne dit rien des apps mal codées. Les vieux protocoles mail sans TLS explicite (IMAP/POP3/SMTP en clair) traînent encore dans des configurations d’entreprise oubliées. Et les sites qui n’implémentent pas HSTSEn-tête HTTP qui force l'usage de HTTPS pour les visites futures d'un domaine.Voir le lexique restent exposés à un downgrade SSLstrip : un attaquant en position de MITMAttaque où un acteur s'interpose dans une communication entre deux parties qui se croient en direct.Voir le lexique force la connexion à repasser en HTTP avant que le navigateur n’ait verrouillé le HTTPS. Les grandes plateformes sont préchargées dans les listes HSTS des navigateurs et donc protégées ; le site moins courant de votre prestataire, beaucoup moins.

Le modèle de menace réel, vecteur par vecteur

Cessons d’agiter la peur abstraite du « hacker du café » et listons les vecteurs concrets qui restent exploitables en 2026. Ils se rangent en quelques familles, par ordre décroissant de fréquence réelle.

Le portail captif malveillant. C’est le vecteur le plus sous-estimé, et de loin. Quand vous rejoignez le Wi-Fi d’un hôtel, d’un aéroport ou d’un train, vous atterrissez sur une page captiveRéseau Wi-Fi ouvert ou partagé (hôtel, café, conférence) — modèle de menace particulier.Voir le lexique — bienvenue, acceptation de conditions, saisie d’un code. Cette page est servie en HTTP. Un réseau hostile peut présenter un portail contrefait qui vous demande de vous « authentifier » avec votre adresse mail et un mot de passe, ou qui vous invite à installer un « certificat de sécurité » pour accéder à internet. Ce certificat, une fois installé, permet de déchiffrer votre trafic HTTPS — il transforme votre propre appareil en complice du MITM. La règle est simple et absolue : un code de chambre, à la rigueur. Vos identifiants, jamais. Un certificat, jamais.

L’evil twin. Un attaquant déploie un point d’accès avec le même SSID qu’un réseau attendu : Airport_Free_WiFi, Starbucks_Guest, ConferenceWiFi. Votre appareil, s’il a mémorisé un réseau de ce nom, peut s’y connecter automatiquement et silencieusement. Une fois sur ce réseau contrôlé par l’attaquant, tout le reste — DNS spoofing, portail contrefait, tentative de downgrade — devient trivial parce qu’il maîtrise l’infrastructure. C’est pour ça que la connexion automatique aux réseaux ouverts est une mauvaise idée et que purger les réseaux mémorisés n’est pas de la coquetterie.

Le DNS spoofing. Sans DoHProtocole qui chiffre les requêtes DNS dans du HTTPS, les masquant au FAI.Voir le lexique ou DoTVariante de DoH utilisant TLS direct au lieu de HTTPS.Voir le lexique actif, vos requêtes de résolution partent en clair et le réseau peut y répondre à sa guise. Vous tapez le nom de votre banque, le résolveur hostile renvoie l’IP d’une fausse page. En théorie, HTTPS vous sauve : le certificat de la fausse page ne validera pas, et le navigateur affichera une alerte. En pratique, une fraction non négligeable d’utilisateurs clique « continuer quand même ». Le chiffrement DNS supprime ce vecteur à la racine.

WPA2 à clé partagée. Le détail technique que presque personne ne connaît : sur un réseau WPA2-PSK où tous les clients partagent le même mot de passe — le cas standard des hôtels et cafés — un client qui connaît ce mot de passe et qui a capturé le handshake d’association d’une victime peut dériver sa clé de session et déchiffrer son trafic WPA2. Autrement dit, un réseau « protégé par mot de passe » partagé entre 200 personnes n’est, vis-à-vis de ces 200 personnes, guère plus privé qu’un réseau ouvert. WPA3 (avec SAE) corrige ça, mais reste minoritaire dans le parc hôtelier.

Le fingerprinting de trafic. Même sous VPN et HTTPS, un observateur passif peut analyser les patterns de timing, les volumes et les séquences de paquets pour inférer votre activité. C’est une attaque sophistiquée, pertinente pour les profils vraiment exposés et les adversaires étatiques, pas pour le voyageur d’affaires lambda. Je la cite pour être honnête sur la limite haute du modèle, pas pour alimenter l’angoisse.

La bonne approche : calibrer, pas ritualiser

La bascule pragmatique consiste à arrêter de chercher LA règle universelle et à raisonner par niveau de risque du moment. Le Wi-Fi public n’est pas dangereux ou sûr dans l’absolu ; il l’est en fonction de ce que vous transportez, de qui vous êtes, et de la juridiction où vous êtes. Trois mesures changent réellement quelque chose, et elles ne coûtent presque rien ; le reste est du folklore.

Premièrement, chiffrer son DNS au niveau système. C’est la mesure la plus rentable et la plus négligée. DoHProtocole qui chiffre les requêtes DNS dans du HTTPS, les masquant au FAI.Voir le lexique ou DoTVariante de DoH utilisant TLS direct au lieu de HTTPS.Voir le lexique activé fait disparaître d’un coup le DNS spoofing et la fuite de vos requêtes de résolution vers l’opérateur du réseau. Ça se configure une fois, au niveau de l’OS, et ça vous protège sur tous les réseaux ensuite — pas seulement le Wi-Fi public. C’est de la sécurité qui ne dépend pas de votre discipline du moment, donc elle tient.

Deuxièmement, traiter le portail captif comme une zone hostile par défaut. Ne jamais y saisir d’identifiant réutilisé ailleurs, ne jamais y installer de certificat, et idéalement ouvrir le portail dans une fenêtre dédiée plutôt que de laisser le navigateur principal s’y promener. La plupart des compromissions « via le Wi-Fi public » ne sont pas des prouesses cryptographiques : ce sont des gens qui ont tapé leur mot de passe sur une fausse page.

Troisièmement, choisir le bon canal selon l’enjeu. Pour une session vraiment sensible, le Wi-Fi public n’est pas le problème à résoudre — c’est le canal à éviter. Le partage de connexion 4G/5G ou une eSIMCarte SIM intégrée et reprogrammable, supportant plusieurs profils opérateurs.Voir le lexique locale vous donne un réseau que vous maîtrisez, sans evil twin ni portail captif. Le VPNTunnel chiffré entre votre appareil et un serveur, masquant votre IP et votre trafic à votre FAI.Voir le lexique a son rôle — il chiffre le transit et ferme le vecteur réseau local — mais à deux conditions souvent oubliées : il doit être activé avant de rejoindre le réseau (sinon votre IP et vos premières requêtes DNS sont déjà parties en clair), et il ne doit pas être un VPN gratuit, dont le modèle économique est précisément de monétiser ce que vous croyez protéger.

L’essentiel de cette approche tient dans une idée : on ne sécurise pas le Wi-Fi public en ajoutant des rituels anxieux, on le sécurise en mettant en place deux ou trois protections qui fonctionnent sans qu’on ait à y penser, puis en réservant les mesures lourdes aux contextes qui les justifient vraiment.

Ce que ça implique concrètement

Erreurs qu’on voit tout le temps

• « L’hôtel cinq étoiles est plus sûr qu’un café. » Aucun rapport. Les grands hôtels qui accueillent des profils intéressants sont des cibles plus attractives, pas plus protégées. La qualité du room service ne dit rien de la sécurité du réseau.
• « Le réseau a un mot de passe, donc c’est chiffré pour moi. » Sur du WPA2 à clé partagée, les autres clients qui connaissent le mot de passe peuvent potentiellement déchiffrer votre trafic. Un mot de passe partagé par 200 personnes ne vous isole pas de ces 200 personnes.
• « J’active le VPN une fois que je vais sur un site important. » Trop tard. Votre IP réelle et vos premières requêtes DNS sont déjà parties. Le VPN s’active avant de rejoindre le réseau, sinon il arrive après la bataille.
• « HTTPS est partout, je n’ai plus rien à faire. » HTTPS protège le contenu, pas les métadonnées, pas le portail captif, pas les apps qui font du HTTP en douce, pas les sites sans HSTS face à un SSLstrip.
• « Le VPN gratuit me protège. » Le modèle économique d’un VPN gratuit, c’est de monétiser votre trafic. Vous remplacez une menace hypothétique sur le réseau local par une menace certaine chez le fournisseur.
• Installer le « certificat de sécurité » du portail pour gagner du temps. C’est offrir à l’attaquant la capacité de déchiffrer tout votre HTTPS. Jamais.

Checklist actionnable

• N1 Vérifier le cadenas et la validité du certificat HTTPS avant de saisir tout identifiant
• N1 Ne jamais saisir d'identifiant réutilisé ni installer de certificat sur un portail captif
• N1 Activer le DNS chiffré (DoH ou DoT) au niveau système sur tous les appareils
• N1 Couper la connexion automatique aux réseaux ouverts et purger les réseaux mémorisés
• N1 Désactiver le Wi-Fi quand il n'est pas utilisé (anti-tracking et anti-evil-twin)
• N2 Activer le VPN AVANT de rejoindre le réseau, jamais après — et payant, jamais gratuit
• N2 Privilégier le partage de connexion 4G/5G ou une eSIM locale pour les sessions sensibles
• N2 Vérifier l'absence de DNS leak quand le VPN est actif
• N2 Pousser DNS chiffré et VPN d'entreprise par MDM avec activation automatique hors réseau corporate
• N3 Politique 4G/eSIM uniquement pour les appareils à données sensibles en contexte conférence/salon
• N3 Appareil dédié sans données critiques pour les profils exposés en juridiction à interception mature

Pour aller plus loin

La Wi-Fi Alliance documente les apports de WPA3 (SAE) face à WPA2, utile pour comprendre pourquoi le mot de passe partagé n’isole pas les clients entre eux. L’ANSSI publie un guide « Partir en mission » court et factuel, qui aligne la posture Wi-Fi sur le reste de la préparation de déplacement — à lire si vous bâtissez une politique d’entreprise.

Trois articles complètent celui-ci sur les mêmes vecteurs. DNS : durcir la résolution de noms détaille la configuration DoH/DoT qui ferme le vecteur le plus rentable. VPN : 95 % du marketing est faux explique précisément ce qu’un VPN protège, ce qu’il ne touche pas, et quels fournisseurs méritent votre confiance. Et eSIM en voyage couvre le canal de remplacement le plus simple quand vous voulez tout bonnement éviter le réseau de l’hôtel. La paranoïa raisonnable n’est pas une humeur, c’est une configuration : une fois ces trois pièces en place, le Wi-Fi public redevient ce qu’il aurait toujours dû être — un service banal, ni miraculeux ni terrifiant.