Portail (on dit portaux ?) captif et SSL
Bonjour, Pour bien commencer la semaine, je tente de trouver une astuce pour un de mes contacts (oui, je rends service). Le problème est tout simple et maintes fois débattu : comment fait-on un portail captif en 2017 quand les utilisateurs, une fois connectés, tapes automatiquement https://www.google.fr dans le navigateur ? Pour mémoire, un portail captif est censé intercepter les requêtes web et les rediriger sur une page d'authentification (ou de pub) si le client n'est pas encore validé. Si le client tapes une première URL en https, ca finit invariablement sur une erreur de certificat. La seule solution qui me vient à l'esprit serait d'avoir un énorme certificat wilcard. Impossible by design. Sinon, installer un certificat 'fake' sur chaque poste client mais nous ne sommes pas dans le cadre d'une base de clients 'maîtrisée' comme dans le parc d'une entreprise. Alors ? Il existe une astuce qui m'échappe ? faire une authentification à l'aide d'autre chose que du site web ? Jouer avec de la redirection au niveau IP (je ne vois pas comment) ? Bricoler avec du DNS menteur ? J'ai deux pistes : * RFC7710 qui semble prometteur mais qui n'avance pas en terme d'implémentation. * 802.1X : pas trop compris si ça permet de satisfaire aux exigences légales françaises ni même si c'est réaliste en terme de mise en œuvre. Merci pour vos lumières, Julien
Bonjour, Je ne pense pas que cela soit possible, du fait que Google utilise du HSTS en preload. https://fr.m.wikipedia.org/wiki/HTTP_Strict_Transport_Security Cordialement
Le 22 mai 2017 à 12:17, Julien Escario <escario@azylog.net> a écrit :
Bonjour, Pour bien commencer la semaine, je tente de trouver une astuce pour un de mes contacts (oui, je rends service).
Le problème est tout simple et maintes fois débattu : comment fait-on un portail captif en 2017 quand les utilisateurs, une fois connectés, tapes automatiquement https://www.google.fr dans le navigateur ?
Pour mémoire, un portail captif est censé intercepter les requêtes web et les rediriger sur une page d'authentification (ou de pub) si le client n'est pas encore validé. Si le client tapes une première URL en https, ca finit invariablement sur une erreur de certificat. La seule solution qui me vient à l'esprit serait d'avoir un énorme certificat wilcard. Impossible by design. Sinon, installer un certificat 'fake' sur chaque poste client mais nous ne sommes pas dans le cadre d'une base de clients 'maîtrisée' comme dans le parc d'une entreprise.
Alors ? Il existe une astuce qui m'échappe ? faire une authentification à l'aide d'autre chose que du site web ? Jouer avec de la redirection au niveau IP (je ne vois pas comment) ? Bricoler avec du DNS menteur ?
J'ai deux pistes : * RFC7710 qui semble prometteur mais qui n'avance pas en terme d'implémentation. * 802.1X : pas trop compris si ça permet de satisfaire aux exigences légales françaises ni même si c'est réaliste en terme de mise en œuvre.
Merci pour vos lumières, Julien
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/ <smime.p7s>
Le 22/05/2017 à 12:31, Laurent a écrit :
Le 22/05/2017 à 12:15, Julien Escario a écrit :
Bricoler avec du DNS menteur ?
C'est ce que font les McDo et autres hotels, ils me semblent..
Sauf que, si je ne me trompes pas, ca oblige à cliquer pour bypasser l'erreur de certificat non ? Ce qui donne de très mauvaises habitudes aux utilisateurs. Et comme dit plus haut, si HSTS, chrome ne t'autorise même plus à bypasser. Firefox doit suivre le même chemin. IE/Edge, je m'en fous et je n'ai rien pour tester :-) Julien
Le 22 mai 2017 à 12:15, Julien Escario <escario@azylog.net> a écrit :
* 802.1X : pas trop compris si ça permet de satisfaire aux exigences légales françaises ni même si c'est réaliste en terme de mise en œuvre.
802.1X est utilisé notamment sur les réseaux WiFi publics des Livebox et Freebox. Ça fonctionne très bien chez moi : lorsque tu connectes un device, une popup s'ouvre et invite l'utilisateur à s'identifier. Il peut ensuite naviguer normalement. Pour la partie légale, je ne vois pas trop le souci. -- Jonathan Leroy.
Le 22/05/2017 à 14:07, Jonathan Leroy a écrit :
Le 22 mai 2017 à 12:15, Julien Escario <escario@azylog.net> a écrit :
* 802.1X : pas trop compris si ça permet de satisfaire aux exigences légales françaises ni même si c'est réaliste en terme de mise en œuvre.
802.1X est utilisé notamment sur les réseaux WiFi publics des Livebox et Freebox. Ça fonctionne très bien chez moi : lorsque tu connectes un device, une popup s'ouvre et invite l'utilisateur à s'identifier. Il peut ensuite naviguer normalement.
OK, reste à savoir comment le faire. La doc ne semble pas pléthorique mais je n'ai pas encore beaucoup cherché.
Pour la partie légale, je ne vois pas trop le souci.
Je ne suis pas super précis sur ce point, je vais me renseigner pour voir si ça peut coller 'légalement'. Julien
Tu utilises un équipement (AP WIFI ou switch) pour intercepter le trafic et renvoyer au portal, ou tu es justement en train de développer un portail pour être agnostique de l’équipement qui « connecte » le client ? Parce que fais quand même gaffe à pas ré-inventer la roue :) Tout le monde sur le marché gère le 802.1x. C’est généralement pas utilisé pour de l’authentif avec self-provisioning sur WIFI Public par exemple parce que ça implique Radius derrière, donc un peu de dev pour faire du self-provisioning, et c’est assez lourd pour l’utilisateur. C’est plutôt pour authentifier sur une base d’utilisateurs existante (clients Orange, clients Free, salariés entreprise, etc…). Il me semble quand même que sur des équipements modernes/récents, le client est censé ouvrir une page de connexion quand il se connecte à un portal captif qui le demande. Par exemple, sur IOS, si à l’affichage de la splash page, tu la fermes, la connexion WIFI échoue donc à aucune moment tu n’as l’occasion de tenter d’accéder à une URL HTTPS à la main. Evidemment, c’est pas parfait, et il y a des cas où ça déconne joyeusement.
Le 22 mai 2017 à 16:08, Julien Escario <escario@azylog.net> a écrit :
Le 22/05/2017 à 14:07, Jonathan Leroy a écrit :
Le 22 mai 2017 à 12:15, Julien Escario <escario@azylog.net> a écrit :
* 802.1X : pas trop compris si ça permet de satisfaire aux exigences légales françaises ni même si c'est réaliste en terme de mise en œuvre.
802.1X est utilisé notamment sur les réseaux WiFi publics des Livebox et Freebox. Ça fonctionne très bien chez moi : lorsque tu connectes un device, une popup s'ouvre et invite l'utilisateur à s'identifier. Il peut ensuite naviguer normalement.
OK, reste à savoir comment le faire. La doc ne semble pas pléthorique mais je n'ai pas encore beaucoup cherché.
Pour la partie légale, je ne vois pas trop le souci.
Je ne suis pas super précis sur ce point, je vais me renseigner pour voir si ça peut coller 'légalement'.
Julien
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour, Je n'ai pas eu l'occasion de maîtriser cet aspect-là, mais à moins que je ne me plantes complètement, un proxy me semble le plus adapté. Le 802.1X est très utile si tu veux protéger l'accès à ton réseau local par authentification. Si tu te fiche de qui se connecte à ton réseau mais que tu veux seulement protéger les accès Web, tu fais rediriger tous tes flux web vers ton proxy qui montre un portail captif. Une fois l'utilisateur authentifié, le proxy devient transparent. Tu peux de plus y appliquer des fonctionnalités d'agrément comme une white/black list ou du cache, voir même déchiffrer les sessions SSL (je sais pas si c'est légal, je sais pas comment ça marche). Le proxy Squid le fait bien (même si j'ai eu une mauvaise expérience en tant qu'utilisateur, probablement mal paramétré ou dimensionné), mais je suppose qu'il y en a d'autres. Tu as différentes possibilités pour faire diriger tes flux vers le proxy. Il y aurait apparemment le DNS menteur (?), mais perso je verrais dans un premier temps avec des redirections type pare-feu, ton proxy acceptant tous les vHosts sur 80 et 443 et il fait le tri derrière, la session d'un utilisateur étant stockée dans un cookie je suppose, ou par rapport à son IP. Cordialement, Arnaud Le 22 mai 2017 à 12:15, Julien Escario <escario@azylog.net> a écrit :
Bonjour, Pour bien commencer la semaine, je tente de trouver une astuce pour un de mes contacts (oui, je rends service).
Le problème est tout simple et maintes fois débattu : comment fait-on un portail captif en 2017 quand les utilisateurs, une fois connectés, tapes automatiquement https://www.google.fr dans le navigateur ?
Pour mémoire, un portail captif est censé intercepter les requêtes web et les rediriger sur une page d'authentification (ou de pub) si le client n'est pas encore validé. Si le client tapes une première URL en https, ca finit invariablement sur une erreur de certificat. La seule solution qui me vient à l'esprit serait d'avoir un énorme certificat wilcard. Impossible by design. Sinon, installer un certificat 'fake' sur chaque poste client mais nous ne sommes pas dans le cadre d'une base de clients 'maîtrisée' comme dans le parc d'une entreprise.
Alors ? Il existe une astuce qui m'échappe ? faire une authentification à l'aide d'autre chose que du site web ? Jouer avec de la redirection au niveau IP (je ne vois pas comment) ? Bricoler avec du DNS menteur ?
J'ai deux pistes : * RFC7710 qui semble prometteur mais qui n'avance pas en terme d'implémentation. * 802.1X : pas trop compris si ça permet de satisfaire aux exigences légales françaises ni même si c'est réaliste en terme de mise en œuvre.
Merci pour vos lumières, Julien
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le Tue, May 23, 2017 at 09:30:28AM +0200, SERRUT Arnaud [qqqrno@gmail.com] a écrit: [...]
Si tu te fiche de qui se connecte à ton réseau mais que tu veux seulement protéger les accès Web, tu fais rediriger tous tes flux web vers ton proxy qui montre un portail captif. Une fois l'utilisateur authentifié, le proxy devient transparent.
Tout ca fonctionne tres bien quand tu interceptes de l'HTTP. (et une fois le proxy en mode "autorisation" ca va pour l'HTTPS) Le probleme qui motive le thread, c'est lorsque la toute premiere tentative de connexion, qu'il faut intercepter, et faire aboutir pour afficher la demande d'identification, est faite en HTTPS. Ce qui va etre le cas pour "www.google.fr" que beaucoup de monde a mis comme page par défaut, et qui a une politique HSTS embarquée dans les navigateurs. -- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 21 rue Frédéric Petit - 80000 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
Le 23/05/2017 à 10:17, Dominique Rousseau a écrit :
Le Tue, May 23, 2017 at 09:30:28AM +0200, SERRUT Arnaud [qqqrno@gmail.com] a écrit: [...]
Si tu te fiche de qui se connecte à ton réseau mais que tu veux seulement protéger les accès Web, tu fais rediriger tous tes flux web vers ton proxy qui montre un portail captif. Une fois l'utilisateur authentifié, le proxy devient transparent.
Tout ca fonctionne tres bien quand tu interceptes de l'HTTP. (et une fois le proxy en mode "autorisation" ca va pour l'HTTPS)
Huh ? Qu'est-ce que tu entends par proxy en mode 'autorisation' ?
Le probleme qui motive le thread, c'est lorsque la toute premiere tentative de connexion, qu'il faut intercepter, et faire aboutir pour afficher la demande d'identification, est faite en HTTPS. Ce qui va etre le cas pour "www.google.fr" que beaucoup de monde a mis comme page par défaut, et qui a une politique HSTS embarquée dans les navigateurs.
Merci, j'ai l'impression de ne pas avoir posé correctement la problématique. Je SAIS monter un portail captif, notamment avec de l'Unifi. Ca marche très bien avec Android (qui fait un check en HTTP sur connectivitycheck.google-truc) ou IOS (même chose à la loiche). Windows 10, je n'avais pas vérifier le comportement mais il semble avoir pris également de bonne habitudes. Non, le soucis c'est un ordi portable sous Windows 7/8/Linux/Whatelse qui se connecte au wifi (sans WPA, cé maaal) et qui ensuite ouvre son navigateur qui, par défaut, ouvre https://fr.yahoo.com, https://www.google.pl ou encore https://account.live.com/. Dans ce cas précis (mais pas rare), mon confrère avec lequel nous menons cette réflexion se prend IMMÉDIATEMENT un appel de support parce, je cite, "le wifi marche pas" (Hôtels, chambre d'hôtes, bref, des touristes étrangers pas toujours francophone). Alors il explique qu'il faut ouvrir http://orange.fr ou http://lemonde.fr ou un de ces sites qui font du CDN qui ne sait pas leur fournir de SSL. Sauf que d'ici peu (hum) de temps, ces sites vont enfin rajouter du SSL et il ne restera plus que la possibilité d'en trouver qui n'a pas rajouté de HSTS et de lui dire de bypasser la vérification du certificat. C'est moche et ça donne de mauvaises habitudes aux end-users (si le mal n'est pas déjà fait). C'est cette problématique que je tente de contourner. Si, en bonus, on a une solution qui permet d'éviter d'ouvrir des AP sans WPA, j'avoue que je ne cracherais pas dessus. Julien
Le Tue, May 23, 2017 at 10:44:44AM +0200, Julien Escario [escario@azylog.net] a écrit:
Le 23/05/2017 à 10:17, Dominique Rousseau a écrit :
Le Tue, May 23, 2017 at 09:30:28AM +0200, SERRUT Arnaud [qqqrno@gmail.com] a écrit: [...]
Si tu te fiche de qui se connecte à ton réseau mais que tu veux seulement protéger les accès Web, tu fais rediriger tous tes flux web vers ton proxy qui montre un portail captif. Une fois l'utilisateur authentifié, le proxy devient transparent.
Tout ca fonctionne tres bien quand tu interceptes de l'HTTP. (et une fois le proxy en mode "autorisation" ca va pour l'HTTPS)
Huh ? Qu'est-ce que tu entends par proxy en mode 'autorisation' ?
Ben soit du proxy transparent qui laisse tout passer, soit des autorisations au niveau parefeu. Dans mes souvenirs Squid fonctionne bien en mode transparent [sans cache, hein] sur l'HTTPS tant qu'on ne cherche pas à dire "non" de façon propre (ie message qui s'affiche dans le navigateur).
Le probleme qui motive le thread, c'est lorsque la toute premiere tentative de connexion, qu'il faut intercepter, et faire aboutir pour afficher la demande d'identification, est faite en HTTPS. Ce qui va etre le cas pour "www.google.fr" que beaucoup de monde a mis comme page par défaut, et qui a une politique HSTS embarquée dans les navigateurs.
Merci, j'ai l'impression de ne pas avoir posé correctement la problématique.
Je SAIS monter un portail captif, notamment avec de l'Unifi. Ca marche très bien avec Android (qui fait un check en HTTP sur connectivitycheck.google-truc) ou IOS (même chose à la loiche). Windows 10, je n'avais pas vérifier le comportement mais il semble avoir pris également de bonne habitudes.
Non, le soucis c'est un ordi portable sous Windows 7/8/Linux/Whatelse qui se connecte au wifi (sans WPA, cé maaal) et qui ensuite ouvre son navigateur qui, par défaut, ouvre https://fr.yahoo.com, https://www.google.pl ou encore https://account.live.com/.
Ben en tout cas, moi j'avais bien compris que le problème était celui-là avec le sujet et la description initiale :o) -- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 21 rue Frédéric Petit - 80000 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
Le Tue, May 23, 2017 at 10:57:18AM +0200, Dominique Rousseau [d.rousseau@nnx.com] a écrit: [...]
Dans mes souvenirs Squid fonctionne bien en mode transparent [sans cache, hein] sur l'HTTPS tant qu'on ne cherche pas à dire "non" de façon propre (ie message qui s'affiche dans le navigateur).
Ah oui mais non, en fait. Pour le cas dont j'ai souvenir, une fois "autorisé" le port 443 était ouvert, et seul le 80 passait en proxy transaprent. -- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 21 rue Frédéric Petit - 80000 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
Non, le soucis c'est un ordi portable sous Windows 7/8/Linux/Whatelse qui se connecte au wifi (sans WPA, cé maaal) et qui ensuite ouvre son navigateur qui, par défaut, ouvre https://fr.yahoo.com, https://www.google.pl ou encore https://account.live.com/.
Dans ce cas précis (mais pas rare), mon confrère avec lequel nous menons cette réflexion se prend IMMÉDIATEMENT un appel de support parce, je cite, "le wifi marche pas" (Hôtels, chambre d'hôtes, bref, des touristes étrangers pas toujours francophone).
Alors il explique qu'il faut ouvrir http://orange.fr ou http://lemonde.fr ou un de ces sites qui font du CDN qui ne sait pas leur fournir de SSL. Sauf que d'ici peu (hum) de temps, ces sites vont enfin rajouter du SSL et il ne restera plus que la possibilité d'en trouver qui n'a pas rajouté de HSTS et de lui dire de bypasser la vérification du certificat. C'est moche et ça donne de mauvaises habitudes aux end-users (si le mal n'est pas déjà fait).
Si c'est juste ça, il suffit de mettre en place une URL à fournir aux utilisateurs, du type https://monhotel.fr, à afficher à l'accueil, et faire en sorte que cette URL fonctionne depuis le réseau Wifi avant enregistrement (et affiche le portail captif). Et le support pourra fournir cette adresse aux client qui n'arrivent pas à se connecter.
C'est cette problématique que je tente de contourner. Si, en bonus, on a une solution qui permet d'éviter d'ouvrir des AP sans WPA, j'avoue que je ne cracherais pas dessus.
Idem, dans le cas d'un hôtel, il suffit de mettre une panneau à l'accueil / dans les chambres avec la clé à utiliser ... Après, pour un wifi plus étendu (aéroport, campus, etc), le wifi ouvert est indispensable, et il faut passer par le portail captif, en espérant que les utilisateurs comprendront, en voyant l'erreur du navigateur, qu'il faut se connecter en http. Un DNS menteur ou un proxy ne réglera pas le problème.
Visiblement, tu n’es pas le seul à attendre la RFC qui va bien :) http://community.arubanetworks.com/t5/Technology-Blog/Captive-Portal-why-do-...
Le 23 mai 2017 à 10:44, Julien Escario <escario@azylog.net> a écrit :
Le 23/05/2017 à 10:17, Dominique Rousseau a écrit :
Le Tue, May 23, 2017 at 09:30:28AM +0200, SERRUT Arnaud [qqqrno@gmail.com] a écrit: [...]
Si tu te fiche de qui se connecte à ton réseau mais que tu veux seulement protéger les accès Web, tu fais rediriger tous tes flux web vers ton proxy qui montre un portail captif. Une fois l'utilisateur authentifié, le proxy devient transparent.
Tout ca fonctionne tres bien quand tu interceptes de l'HTTP. (et une fois le proxy en mode "autorisation" ca va pour l'HTTPS)
Huh ? Qu'est-ce que tu entends par proxy en mode 'autorisation' ?
Le probleme qui motive le thread, c'est lorsque la toute premiere tentative de connexion, qu'il faut intercepter, et faire aboutir pour afficher la demande d'identification, est faite en HTTPS. Ce qui va etre le cas pour "www.google.fr" que beaucoup de monde a mis comme page par défaut, et qui a une politique HSTS embarquée dans les navigateurs.
Merci, j'ai l'impression de ne pas avoir posé correctement la problématique.
Je SAIS monter un portail captif, notamment avec de l'Unifi. Ca marche très bien avec Android (qui fait un check en HTTP sur connectivitycheck.google-truc) ou IOS (même chose à la loiche). Windows 10, je n'avais pas vérifier le comportement mais il semble avoir pris également de bonne habitudes.
Non, le soucis c'est un ordi portable sous Windows 7/8/Linux/Whatelse qui se connecte au wifi (sans WPA, cé maaal) et qui ensuite ouvre son navigateur qui, par défaut, ouvre https://fr.yahoo.com, https://www.google.pl ou encore https://account.live.com/.
Dans ce cas précis (mais pas rare), mon confrère avec lequel nous menons cette réflexion se prend IMMÉDIATEMENT un appel de support parce, je cite, "le wifi marche pas" (Hôtels, chambre d'hôtes, bref, des touristes étrangers pas toujours francophone).
Alors il explique qu'il faut ouvrir http://orange.fr ou http://lemonde.fr ou un de ces sites qui font du CDN qui ne sait pas leur fournir de SSL. Sauf que d'ici peu (hum) de temps, ces sites vont enfin rajouter du SSL et il ne restera plus que la possibilité d'en trouver qui n'a pas rajouté de HSTS et de lui dire de bypasser la vérification du certificat. C'est moche et ça donne de mauvaises habitudes aux end-users (si le mal n'est pas déjà fait).
C'est cette problématique que je tente de contourner. Si, en bonus, on a une solution qui permet d'éviter d'ouvrir des AP sans WPA, j'avoue que je ne cracherais pas dessus.
Julien
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 23/05/2017 à 11:24, David Ponzone a écrit :
Visiblement, tu n’es pas le seul à attendre la RFC qui va bien :)
http://community.arubanetworks.com/t5/Technology-Blog/Captive-Portal-why-do-...
J'en ai lu des kilos comme ce post. Mais la RFC1170, c'est statut proposal. Le temps que ce soit validé ET ajouté par les équipementiers, l'IoT aura déjà tué Internet. Julien
Sinon, tu laisses HTTPS ouvert pour 5 minutes, en espérant que le client finisse par aller sur une page HTTP pendant ces 5 minutes.
Le 23 mai 2017 à 11:35, Julien Escario <escario@azylog.net> a écrit :
Le 23/05/2017 à 11:24, David Ponzone a écrit :
Visiblement, tu n’es pas le seul à attendre la RFC qui va bien :)
http://community.arubanetworks.com/t5/Technology-Blog/Captive-Portal-why-do-...
J'en ai lu des kilos comme ce post.
Mais la RFC1170, c'est statut proposal. Le temps que ce soit validé ET ajouté par les équipementiers, l'IoT aura déjà tué Internet.
Julien
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 23/05/2017 à 11:41, David Ponzone a écrit :
Sinon, tu laisses HTTPS ouvert pour 5 minutes, en espérant que le client finisse par aller sur une page HTTP pendant ces 5 minutes.
Moui, c'est une option, comme de laisser TOUT le trafic ssl sortir, tout le temps (c'est juste une question d'arbitrage). Mon soucis c'est que le SSL s'est clairement démocratiser (et tant mieux) et tout porte à croire que ça va continuer. On a notamment des utilisateurs qui n'utilisent le wifi que pour faire du Netflix = grosse bande passante, jamais de trafic en clair. Julien
Alors si tu peux, tu shapes le trafic HTTPS tant que l'utilisateur est pas authentifié.
Le 23 mai 2017 à 12:01, Julien Escario <escario@azylog.net> a écrit :
Le 23/05/2017 à 11:41, David Ponzone a écrit :
Sinon, tu laisses HTTPS ouvert pour 5 minutes, en espérant que le client finisse par aller sur une page HTTP pendant ces 5 minutes.
Moui, c'est une option, comme de laisser TOUT le trafic ssl sortir, tout le temps (c'est juste une question d'arbitrage).
Mon soucis c'est que le SSL s'est clairement démocratiser (et tant mieux) et tout porte à croire que ça va continuer. On a notamment des utilisateurs qui n'utilisent le wifi que pour faire du Netflix = grosse bande passante, jamais de trafic en clair.
Julien
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 23/05/2017 à 12:10, David Ponzone a écrit :
Alors si tu peux, tu shapes le trafic HTTPS tant que l'utilisateur est pas authentifié.
Ca commence à faire une jolie usine à gaz non ? Avec plein de raison pour ne pas tomber en marche. Merci pour ces pistes. J'en déduis qu'il n'existe pas vraiment de solution 'propre' dans l'immédiat, avec quelques pistes pour le futur. On va continuer à bricoler quelques mois alors. Julien
Ben faudrait pouvoir forcer Win7/8 à ouvrir une page à la connexion. Ca serait facile avec un script powershell qui établie la connexion sur le SSID de l’accès public puis ouvre un navigateur vers une page bidon HTTP, mais le problème c’est comment envoyer le script au PC. Avec un autre SSID ouvert qui renvoie de force sur une page pour le télécharger ? Mais ça va être de nouveau le même problème si la première requête qui a atteint le portail est du HTTPS. Pourtant Ruckus s’y prend comme ça pour leur Zero-IT: SSID ouvert qui envoie sur une page web où on génère une clé DPSK et on récupère un exécutable ou un script d’autoconfig pour Mobile qui va configurer le bon SSID, avec le DPSK, et c’est fini. Je me demande donc comment Ruckus gère Win7/8. Si quelqu’un en a un sous la main pour tester...
Le 23 mai 2017 à 12:24, Julien Escario <escario@azylog.net> a écrit :
Le 23/05/2017 à 12:10, David Ponzone a écrit :
Alors si tu peux, tu shapes le trafic HTTPS tant que l'utilisateur est pas authentifié.
Ca commence à faire une jolie usine à gaz non ? Avec plein de raison pour ne pas tomber en marche.
Merci pour ces pistes. J'en déduis qu'il n'existe pas vraiment de solution 'propre' dans l'immédiat, avec quelques pistes pour le futur.
On va continuer à bricoler quelques mois alors.
Julien
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour, Systems Engineer chez UCOPIA, société française spécialisée dans le portail captif, je me permets de vous faire part de notre retour d'expérience sur ce sujet, qui s'applique à UCOPIA mais aussi à toute technologie de portail captif. Sujet récurrent chez nos clients et abordé sur notre blog : http://www.ucopia.com/actualites/experience-utilisateur-navigation-wifi/ Ci-dessous un complément d'informations. @Julien : la dernière partie devrait intéresser votre confrère. Pour pallier à ces problématiques d'erreur "HSTS" remontées par les utilisateurs, les éditeurs d'OS/Hardware ont implémenté un assistant dit "CNA". ("Captive Network Assistant"). Cet assistant permet d'éviter à l'utilisateur de lancer un navigateur web afin de faire apparaître le portail captif. (et potentiellement tomber sur https://google.fr et recevoir une erreur HSTS. De façon vulgarisée : Un portail captif est un mécanisme qui intercepte le flux utilisateur et lui présente du contenu qu’il n’a pas sollicité par lui-même, pour le forcer à s’authentifier. Le protocole HTTPs (et la surcouche HSTS qui l’utilise), ont pour but de garantir que le contenu reçu par un client est bien celui qu’il demande. Il y a ici incompatibilité entre les deux technologies. Voici le détail de ce qu’il se passe : - Lorsqu’un utilisateur non authentifié sur UCOPIA (ou tout autre portail captif) tente d’accéder à un site sécurisé (https://www.google.fr, ou https://www.mabanque.com ), le portail captif (lui aussi sécurisé, en HTTPS) est présenté. - Le navigateur utilisé récupère alors le certificat du portail captif et non celui du site demandé initialement, d’où cette alerte sécurité qui peut être simplement acceptée en HTTPS standard (et qui est bloquante en HSTS). C’est pour cela que la plupart des éditeurs de systèmes d’exploitation (pour ordinateurs ou mobiles) implémentent depuis récemment des assistants de connexion aux portails captifs : - Apple CNA pour les appareils mobiles (et MAC) Apple : la fameuse page qui s’ouvre toute seule lorsque vous vous connectez au wifi. - Cela apparaît sous forme de notification pour les appareils Android (requête vers http://connectivitycheck.gstatic.com/generate_204 sous Marshmallow et http://clients3.google.com/generate_204 pour Kitkat). - Le Consistent Connection Handling pour Microsoft, - qui fonctionne comme pour les appareils de marque Apple sur mobile - qui propose l’ouverture d’un navigateur sur Windows 8.1 - qui affiche une notification dans le système tray sur Windows 7 Ainsi le problème de la première page en HTTPS ne se pose pas lorsque l’on utilise ces mécanismes : cela doit être pris en charge par la brique portail captif. Vous pourrez vérifier alors qu’une notification invitant l’utilisateur à ouvrir son navigateur est envoyée sur les smartphones et tablettes concernées. - Pour les équipements sous Windows 8 et 10 : vous pouvez passer par l’assistant Wi-Fi. Une fois authentifié sur UCOPIA, l’utilisateur ne verra plus cette alerte sécurité. Autre alternative possible : modifier la page d’accueil par défaut du navigateur sur une page HTTP permettra la non apparition du message d’alerte de certificat. Si l’utilisateur ne passe pas par ces mécanismes, (soit parce qu’il clique volontairement sur leur fermeture, soit parce que son système n’en n’est pas équipé), et que sa première requête est en HTTPs voire HSTS : - Il aura une erreur dans son navigateur lui indiquant qu’il a demandé https://www.google.com et que c’est https://controller.access.network/ (par défaut dans le cas d’Ucopia) qui lui répond. - Cette erreur pourra être ignorée pour des sites en HTTPs. - Si le site initialement demandé supporte le HSTS, alors l’erreur ne pourra être ignorée Pour obtenir la redirection vers le portail captif, l'utilisateur peut simplement solliciter une page en HTTP afin que la redirection puisse être réalisée. Enfin, sachez que les nouvelles moutures des navigateurs web les plus courant commencent à bénéficier d'un Assistant dédié aux notions de portail captif, un exemple du rendu sur Firefox 52 : Un exemple du rendu de l’alerte obtenue (plus de blocage HSTS) ainsi qu’une ouverture du portail captif dans un nouvel onglet avec un appel à http://detectportail.firefox.com/success.txt qui permet la redirection vers le portail : L’alerte obtenue en premier onglet : [image: Images intégrées 3] En second onglet (ouvert par défaut) l’utilisateur verra apparaître le portail captif UCOPIA. [image: Images intégrées 4] Cela devrait arriver prochainement chez les autres éditeur tels que Chrome ou IE, étant déjà disponible sous Chromium. Un groupe de travail IETF à été ouvert afin de suivre les avancées et mettre en place des normes en réponse à ces problématiques liées aux portails captif : https://www.ietf.org/mailman/listinfo/captive-portals Antoine Le 23 mai 2017 à 12:31, David Ponzone <david.ponzone@gmail.com> a écrit :
Ben faudrait pouvoir forcer Win7/8 à ouvrir une page à la connexion. Ca serait facile avec un script powershell qui établie la connexion sur le SSID de l’accès public puis ouvre un navigateur vers une page bidon HTTP, mais le problème c’est comment envoyer le script au PC. Avec un autre SSID ouvert qui renvoie de force sur une page pour le télécharger ? Mais ça va être de nouveau le même problème si la première requête qui a atteint le portail est du HTTPS. Pourtant Ruckus s’y prend comme ça pour leur Zero-IT: SSID ouvert qui envoie sur une page web où on génère une clé DPSK et on récupère un exécutable ou un script d’autoconfig pour Mobile qui va configurer le bon SSID, avec le DPSK, et c’est fini. Je me demande donc comment Ruckus gère Win7/8. Si quelqu’un en a un sous la main pour tester...
Le 23 mai 2017 à 12:24, Julien Escario <escario@azylog.net> a écrit :
Le 23/05/2017 à 12:10, David Ponzone a écrit :
Alors si tu peux, tu shapes le trafic HTTPS tant que l'utilisateur est pas authentifié.
Ca commence à faire une jolie usine à gaz non ? Avec plein de raison pour ne pas tomber en marche.
Merci pour ces pistes. J'en déduis qu'il n'existe pas vraiment de solution 'propre' dans l'immédiat, avec quelques pistes pour le futur.
On va continuer à bricoler quelques mois alors.
Julien
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour, Avec un peu de retard, je tenais à remercier Antoine pour son récapitulatif vraiment complet et précis ! Je crois que le tour de la question est fait, les perspectives en plus. Encore merci Antoine, Julien Le 23/05/2017 à 14:40, Antoine BOISJIBAULT a écrit :
Bonjour,
Systems Engineer chez UCOPIA, société française spécialisée dans le portail captif, je me permets de vous faire part de notre retour d'expérience sur ce sujet, qui s'applique à UCOPIA mais aussi à toute technologie de portail captif.
Sujet récurrent chez nos clients et abordé sur notre blog : http://www.ucopia.com/actualites/experience-utilisateur-navigation-wifi/
Ci-dessous un complément d'informations. @Julien : la dernière partie devrait intéresser votre confrère.
Pour pallier à ces problématiques d'erreur "HSTS" remontées par les utilisateurs, les éditeurs d'OS/Hardware ont implémenté un assistant dit "CNA". ("Captive Network Assistant").
Cet assistant permet d'éviter à l'utilisateur de lancer un navigateur web afin de faire apparaître le portail captif. (et potentiellement tomber sur https://google.fr et recevoir une erreur HSTS.
De façon vulgarisée :
Un portail captif est un mécanisme qui intercepte le flux utilisateur et lui présente du contenu qu’il n’a pas sollicité par lui-même, pour le forcer à s’authentifier.
Le protocole HTTPs (et la surcouche HSTS qui l’utilise), ont pour but de garantir que le contenu reçu par un client est bien celui qu’il demande.
Il y a ici incompatibilité entre les deux technologies.
Voici le détail de ce qu’il se passe :
* Lorsqu’un utilisateur non authentifié sur UCOPIA (ou tout autre portail captif) tente d’accéder à un site sécurisé (https://www.google.fr, ou https://www.mabanque.com ), le portail captif (lui aussi sécurisé, en HTTPS) est présenté. * Le navigateur utilisé récupère alors le certificat du portail captif et non celui du site demandé initialement, d’où cette alerte sécurité qui peut être simplement acceptée en HTTPS standard (et qui est bloquante en HSTS).
C’est pour cela que la plupart des éditeurs de systèmes d’exploitation (pour ordinateurs ou mobiles) implémentent depuis récemment des assistants de connexion aux portails captifs :
* Apple CNA pour les appareils mobiles (et MAC) Apple : la fameuse page qui s’ouvre toute seule lorsque vous vous connectez au wifi. * Cela apparaît sous forme de notification pour les appareils Android (requête vers http://connectivitycheck.gstatic.com/generate_204 sous Marshmallow et http://clients3.google.com/generate_204 pour Kitkat). * Le Consistent Connection Handling pour Microsoft, o qui fonctionne comme pour les appareils de marque Apple sur mobile o qui propose l’ouverture d’un navigateur sur Windows 8.1 o qui affiche une notification dans le système tray sur Windows 7
Ainsi le problème de la première page en HTTPS ne se pose pas lorsque l’on utilise ces mécanismes : cela doit être pris en charge par la brique portail captif.
Vous pourrez vérifier alors qu’une notification invitant l’utilisateur à ouvrir son navigateur est envoyée sur les smartphones et tablettes concernées.
* Pour les équipements sous Windows 8 et 10 : vous pouvez passer par l’assistant Wi-Fi.
Une fois authentifié sur UCOPIA, l’utilisateur ne verra plus cette alerte sécurité.
Autre alternative possible : modifier la page d’accueil par défaut du navigateur sur une page HTTP permettra la non apparition du message d’alerte de certificat.
Si l’utilisateur ne passe pas par ces mécanismes, (soit parce qu’il clique volontairement sur leur fermeture, soit parce que son système n’en n’est pas équipé), et que sa première requête est en HTTPs voire HSTS :
* Il aura une erreur dans son navigateur lui indiquant qu’il a demandé https://www.google.com et que c’est https://controller.access.network/ (par défaut dans le cas d’Ucopia) qui lui répond. * Cette erreur pourra être ignorée pour des sites en HTTPs. * Si le site initialement demandé supporte le HSTS, alors l’erreur ne pourra être ignorée
Pour obtenir la redirection vers le portail captif, l'utilisateur peut simplement solliciter une page en HTTP afin que la redirection puisse être réalisée.
Enfin, sachez que les nouvelles moutures des navigateurs web les plus courant commencent à bénéficier d'un Assistant dédié aux notions de portail captif, un exemple du rendu sur Firefox 52 :
Un exemple du rendu de l’alerte obtenue (plus de blocage HSTS) ainsi qu’une ouverture du portail captif dans un nouvel onglet avec un appel à http://detectportail.firefox.com/success.txt qui permet la redirection vers le portail :
L’alerte obtenue en premier onglet :
Images intégrées 3
En second onglet (ouvert par défaut) l’utilisateur verra apparaître le portail captif UCOPIA.
Images intégrées 4
Cela devrait arriver prochainement chez les autres éditeur tels que Chrome ou IE, étant déjà disponible sous Chromium.
Un groupe de travail IETF à été ouvert afin de suivre les avancées et mettre en place des normes en réponse à ces problématiques liées aux portails captif : https://www.ietf.org/mailman/listinfo/captive-portals
Antoine
Le 23 mai 2017 à 12:31, David Ponzone <david.ponzone@gmail.com <mailto:david.ponzone@gmail.com>> a écrit :
Ben faudrait pouvoir forcer Win7/8 à ouvrir une page à la connexion. Ca serait facile avec un script powershell qui établie la connexion sur le SSID de l’accès public puis ouvre un navigateur vers une page bidon HTTP, mais le problème c’est comment envoyer le script au PC. Avec un autre SSID ouvert qui renvoie de force sur une page pour le télécharger ? Mais ça va être de nouveau le même problème si la première requête qui a atteint le portail est du HTTPS. Pourtant Ruckus s’y prend comme ça pour leur Zero-IT: SSID ouvert qui envoie sur une page web où on génère une clé DPSK et on récupère un exécutable ou un script d’autoconfig pour Mobile qui va configurer le bon SSID, avec le DPSK, et c’est fini. Je me demande donc comment Ruckus gère Win7/8. Si quelqu’un en a un sous la main pour tester...
> Le 23 mai 2017 à 12:24, Julien Escario <escario@azylog.net <mailto:escario@azylog.net>> a écrit : > > Le 23/05/2017 à 12:10, David Ponzone a écrit : >> Alors si tu peux, tu shapes le trafic HTTPS tant que l'utilisateur est pas authentifié. > > Ca commence à faire une jolie usine à gaz non ? Avec plein de raison pour ne pas > tomber en marche. > > Merci pour ces pistes. J'en déduis qu'il n'existe pas vraiment de solution > 'propre' dans l'immédiat, avec quelques pistes pour le futur. > > On va continuer à bricoler quelques mois alors. > > Julien > > > _______________________________________________ > Liste de diffusion du FRsAG > http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
participants (10)
-
Antoine BOISJIBAULT -
David Ponzone -
Dominique Rousseau -
Frederic Hermann -
Jonathan Leroy -
Julien Escario -
KASH -
Laurent -
merlin8282 -
SERRUT Arnaud