Originally published at: http://korben.info/faire-on-narrive-a-tomber-portail-captif-dune-borne-wifi-publique.html
Quand on se connecte à un réseau public wifi, il arrive parfois qu’on ait du mal à obtenir le fameux “portail captif”’ où on nous demande en général notre adresse email, avant de nous laisser librement surfer. En effet, sur certaines bornes wifi, le truc est tellement mal configuré que si vous entrez l’URL de…
Ton navigateur fait ça tout seul, et t’affiche un bandeau indiquant qu’il semble avoir une page de connexion :
y’à qu’à attendre un peu et cliquer dessus.
J’ai découvert se bandeau un jour que la freebox v6 avait désynchro (la v6 affiche une page d’erreur avec un lien vers mafreebox.free.fr -qui marche pas sans DNS d’ailleurs-)
A priori en cas de pb réseau le navigateur (tester avec Firefox) va chercher une page HTTP qu’il connaît bien, si il trouve un contenu différent il affiche le bandeau. Windows fait ça tout seul aussi
- Connecté / Pas d’accès internet : Il n’a pas trouvé la page magique,
- Connecté / Authentification requise : La page a été chargée mais son contenu est différent
Moi, mon problème est inverse : je n’arrive pas à faire passer les connections en HTTPS sur le portail captif que j’ai mis en place 
[quote=“Bencici, post:3, topic:6035, full:true”]
Moi, mon problème est inverse : je n’arrive pas à faire passer les connections en HTTPS sur le portail captif que j’ai mis en place [/quote]Non c’est le même point que l’article : c’est impossible, ça s’appelle une attaque man-in-the-middle SSL sert justement a empêcher ce genre d’attaque.
Les navigateurs sont de plus en plus strict, un élément HTTP ou une redirection vers HTTP est bloqué depuis un site HTTPS (mixed content policy)
HTTP n’étant pas sécurisé affichera la page de login du routeur, toute page HTTPS sera bloqué par le navigateur (pas de certificat et/ou redirection HTTPS) le pb de fond est que la majorité des pages web migre en HTTPS: google doit être en home de 90-95% des internautes, pas de chance c’est de l’HTTPS depuis quelques mois / années
Mon problème ne vient pas forcément de la redirection mais de la navigation.
Une fois l’authentification faite, les sites en HTTPS ne chargent pas sur tous les navigateurs (vieux Firefox, Chrome sur Android…)
Simple, logique mais tout le monde ne le sait pas… accessoirement on peut taper macdonalds ou starbucks… enfin en .com hein soyez pas cons.
Une bonne idée est aussi de désactiver vos DNS personnalisés du style google, si le portail n’ouvre pas. On peut bien entendu les reactiver après coup.
1 « J'aime »
La plupart des portails forcent à utiliser leur DNS donc il sera même après connexion impossible de définir ses propres DNS parce que le traffic ne passera pas.
le truc est mal configuré, ou l’utilisateur trop impatient. Après quelques secondes, il y a une notification qui apparait ( sous android ) , et il suffit de cliquer dessus pour arriver sur le portail. Je n’ai jamais vérifié si ça venait du navigateur ou de l’OS par contre…
Et sinon, il y a l’excellent http://www.phoenixjp.net/news/fr/ , d’où j’arrive d’ailleurs pour commenter cette info.
ou bien ca vient du téléphone ? Mon nexus m’affichait la notif’, mon Samsung ne le fait pas (pour les mêmes wifi publics, sfr et orange).
donc perso mon téléphone se connecte à un réseau, et si je lance chrome vers google ou fb par exemple j’aurais la belle page “attention quelqu’un veut vous piquer vos infos” (parce que adresse demandée en https)
à noter que si je tape google en http_ j’aurais la page d’authentification du wifi. Par contre http_://facebook.fr me redirige automatiquement (comment c’est possible ?) vers httpS://facebook.fr , alors que je ne suis toujours pas connecté au wifi public (donc je tombe sur la page d’alerte)
Pour ma part c’est “perdu.com” dont j’ai un raccourci sous forme d’icône dans la barre de favoris. Spécial portails captifs !
[quote=“esteban, post:10, topic:6035, full:true”]
ou bien ca vient du téléphone ? Mon nexus m’affichait la notif’, mon Samsung ne le fait pas (pour les mêmes wifi publics, sfr et orange).[/quote]
comme expliqué plus haut c’est Logiciel: firefox (PC) le détecte tout comme WIndows, pour Andoid j’ai l’impression que c’est l’OS, car la notif apparait en notif sur le réseau Wifi, c’est pas un message qui apparait dans le navigateur.
[quote=“esteban, post:10, topic:6035, full:true”]donc perso mon téléphone se connecte à un réseau, et si je lance chrome vers google ou fb par exemple j’aurais la belle page “attention quelqu’un veut vous piquer vos infos” (parce que adresse demandée en https)
à noter que si je tape google en http_ j’aurais la page d’authentification du wifi. Par contre http_://facebook.fr me redirige automatiquement (comment c’est possible ?) vers httpS://facebook.fr , alors que je ne suis toujours pas connecté au wifi public (donc je tombe sur la page d’alerte)
[/quote]La redirection FB est un code HTTP 301 (permanently moved) + location donc mis en cache par ton navigateur, ton navigateur trouve le cache et la redirection avant de se rendre compte qu’il y’a un pb réseau.
Pour google, y’a soit une redirection JS, une date d’expiration (pour être de bien chopper ton cookie :-/ ), ou c’est un moved temporary code 302
SSL ne sert pas à empêcher une attaque MITM, il sert à protéger les données si ça arrive. Le “hacker” n’aura accès qu’à des données chiffrées. Mais rien n’empêche au traffic sur SSL d’être redirigé, de passer par un proxy, …ça arrive très fréquemment en entreprise d’ailleurs.
[quote=“UpsiloNIX, post:14, topic:6035, full:true”]SSL ne sert pas à empêcher une attaque MITM, il sert à protéger les données si ça arrive. Le “hacker” n’aura accès qu’à des données chiffrées. [/quote]Tu joues un peu sur les mots, dans ce cas brancher un cable réseau sur un hub, ou se connecter à un Wifi est un man in the middle , si on descend d’une couche OSI le simple fait d’avoir sa carte WiFi activée est un MITM vue qu’elle voit passer des packets WEP / WPA qui ne sont pas pour elle.
SSL au niveau de la couche applicative permet de garantir qu’il n’y’a pas eu de MITM (les données n’ont été ni interceptées, ni modifiées) ensuite dans la mise en oeuvre il y’a des données difficilement déchiffrable qui transitent et qui peuvent être intercepté au niveau de la couche transport, réseau ou physique. (Tout comme une VPN, TOR, du CPL…)
Je ne joue pas vraiment sur les mots, dans pas mal de cas un MITM se fait via ARP spoofing, qui se place sur la couche 2 et 3, on est loin de la couche 7.
SSL assure qu’il n’y a pas eu d’altération OK, mais d’interception, non. Si vraiment tu penses que tu as raison, explique moi comment, je suis tout ouvert mais j’ai du mal à voir comment SSL va vérifier qu’il n’y a pas eu de spoofing ARP et que quelqu’un n’a pas pu récupérer les paquets (chiffrés toujours).
Enfin on s’est peut-être tout simplement mal compris à la base 
[quote=“UpsiloNIX, post:16, topic:6035, full:true”]
Je ne joue pas vraiment sur les mots, dans pas mal de cas un MITM se fait via ARP spoofing, qui se place sur la couche 2 et 3, on est loin de la couche 7.
SSL assure qu’il n’y a pas eu d’altération OK, mais d’interception, non. Si vraiment tu penses que tu as raison, explique moi comment, je suis tout ouvert mais j’ai du mal à voir comment SSL va vérifier qu’il n’y a pas eu de spoofing ARP et que quelqu’un n’a pas pu récupérer les paquets (chiffrés toujours).
Enfin on s’est peut-être tout simplement mal compris à la base :)[/quote]
Par définition, récupérer des paquets chiffrés n’est pas un man in the middle, faire de l’ARP spoofing sur une connexion SSL n’est pas un man in the middle, par contre SSL permet de se protéger d’un simple ARP spoofing.
Tu dois travailler dans le réseau et résonne au niveau transport, mais ça n’a aucun sens, il faut raisonné globalement peu importe le moyen (VPN, TCP, UDP,ATM, IPv4, IPv6, IPoverPigeon…), avec SSL tes données n’ont ni été interceptées ni altérées. Ensuite que des paquets chiffrés se soient baladés n’importe où sur la toile ait été interceptés voir altérés ne change rien au constat que les données que tu reçois (et envois) n’ont été visible par personne, et si quelqu’un les a touché tu le sais, et peux redemander un envoi.
Google man in the middle : on parle bien de canal de communication, pas des couches inférieures.
Oui, il y a raison c’est quand même du MITM.
Firewall Fortinet, tu fais du ssl deep inspection, personne ne voit rien mais le contenu est intercepté.
ou
et sinon bien sur que la couche est importante.
NON, lis ta propre “source” : https://stackoverflow.com/a/14907718
Ou la défintion d’un man in the middle : https://fr.wikipedia.org/wiki/Attaque_de_l’homme_du_milieu
Pour Firewall Fortinet, c’est bien une attaque MITM qui se base sur des CA vérolés: les postes sont configurés pour faire confiance à un CA foireux, ensuite le firewall se fait passer pour les sites Web en question ça ne marche qu’avec des navigateurs peu fiable qui accepte qu’on manipule les certificats racines (typiquement IE et depuis peu Chrome).
Firefox est compilé avec la liste des certificats racines, il détecte parfaitement l’attaque et empêche toute navigation en HTTPS.
Ce type de solution est extrêmement dangereuse (une faille dans le firewall, et c’est tout le traffic SSL qui est accessible), et interdite (Usurpation d’identité numérique: 1an de prison 15000€ d’amende)