[FRsAG] 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 smime.p7s Description: Signature cryptographique S/MIME ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Portail (on dit portaux ?) captif et SSL
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 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/ > ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Portail (on dit portaux ?) captif et SSL
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.. ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Portail (on dit portaux ?) captif et SSL
Le 22 mai 2017 à 12:15, Julien Escario 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. ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Portail (on dit portaux ?) captif et SSL
Le 22/05/2017 à 14:07, Jonathan Leroy a écrit : > Le 22 mai 2017 à 12:15, Julien Escario 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 smime.p7s Description: Signature cryptographique S/MIME ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Portail (on dit portaux ?) captif et SSL
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 a écrit : > > Le 22/05/2017 à 14:07, Jonathan Leroy a écrit : >> Le 22 mai 2017 à 12:15, Julien Escario 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/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Portail (on dit portaux ?) captif et SSL
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 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/ > ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Portail (on dit portaux ?) captif et SSL
Bonjour à tous, juste un petit retour d'expérience. On utilise des portails captif dans nos établissements d'enseignement pour nos réseaux Wifi. Il en existe des payants en logiciel (ucopia par exemple) ou des intégrés à des concentrateur Wifi (comme chez Aruba). On peut aussi utiliser des portails gratuits comme univnaute (https://doc.entrouvert.org/univnautes/stable-iframe-unpidf/index.html) qui est basé sur une distrib pfsense. Pour tout cela on bricole le dhcp pour que la passerelle du vlan distribué corresponde à l'adresse du portail captif et la redirection se fait qu'on ait demandé du https ou non comme url à l'ouverture d'un navigateur (et effectivement ios ou Windows 10 gère automatiquement l'affichage du portail dès que la connexion Wifi se fait). On peut utiliser ces portails (ucopia ou univnaute) pour du réseau filaire. Quand au 802.1x il faut le garder pour du filaire avec un réseau local avec une population d'utilisateur connue et pas des invités temporaires. C'était mes deux centimes 😊 Bonne journée, Manu. Emmanuel BRENAS Service informatique [1472671273785_logo.png] SCIENCES PO LYON 14, avenue Berthelot 69365 Lyon cedex 07 Tel : 04 37 28 38 31 Bâtiment B – Bureau 3.03 www.sciencespo-lyon.fr<http://www.sciencespo-lyon.fr> www.universite-lyon.fr<http://www.universite-lyon.fr> [1473056700454_image002.jpg]<https://www.facebook.com/iep.lyon/> [1473056744352_image003.png] <https://twitter.com/scpolyon> De : FRsAG de la part de SERRUT Arnaud Envoyé : mardi 23 mai 2017 09:30 À : Julien Escario Cc : French SysAdmin Group Objet : Re: [FRsAG] Portail (on dit portaux ?) captif et SSL 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 mailto:esca...@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/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Portail (on dit portaux ?) captif et SSL
Le Tue, May 23, 2017 at 09:30:28AM +0200, SERRUT Arnaud [qqq...@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 - 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Portail (on dit portaux ?) captif et SSL
Emmanuel, donc ton portail captif reste proxy transparent pour tout le trafic une fois que l’utilisateur est authentifié ? Julien, je fais du portail captif fait-maison avec des bornes WIFI Meraki, qui permettent de rediriger l’utilisateur vers son propre portail captif rudimentaire écrit en quelques lignes de PHP. La doc de Meraki sur le sujet est plutôt pas mal. On peut faire ça aussi avec les bornes Ubiquiti, il y a des exemples fournis par la communauté. > Le 23 mai 2017 à 10:05, Brenas Emmanuel > a écrit : > > Bonjour à tous, > > juste un petit retour d'expérience. > > On utilise des portails captif dans nos établissements d'enseignement pour > nos réseaux Wifi. > > Il en existe des payants en logiciel (ucopia par exemple) ou des intégrés à > des concentrateur Wifi (comme chez Aruba). > > On peut aussi utiliser des portails gratuits comme univnaute > (https://doc.entrouvert.org/univnautes/stable-iframe-unpidf/index.html > <https://doc.entrouvert.org/univnautes/stable-iframe-unpidf/index.html>) qui > est basé sur une distrib pfsense. > > Pour tout cela on bricole le dhcp pour que la passerelle du vlan distribué > corresponde à l'adresse du portail captif et la redirection se fait qu'on ait > demandé du https ou non comme url à l'ouverture d'un navigateur (et > effectivement ios ou Windows 10 gère automatiquement l'affichage du portail > dès que la connexion Wifi se fait). > > On peut utiliser ces portails (ucopia ou univnaute) pour du réseau filaire. > Quand au 802.1x il faut le garder pour du filaire avec un réseau local avec > une population d'utilisateur connue et pas des invités temporaires. > > C'était mes deux centimes 😊 > Bonne journée, > Manu. > > Emmanuel BRENAS > Service informatique > > > > SCIENCES PO LYON > 14, avenue Berthelot > 69365 Lyon cedex 07 > Tel : 04 37 28 38 31 > Bâtiment B – Bureau 3.03 > www.sciencespo-lyon.fr <http://www.sciencespo-lyon.fr/> > www.universite-lyon.fr <http://www.universite-lyon.fr/> > > <https://www.facebook.com/iep.lyon/> > <https://twitter.com/scpolyon> > > > De : FRsAG mailto:frsag-boun...@frsag.org>> de la > part de SERRUT Arnaud mailto:qqq...@gmail.com>> > Envoyé : mardi 23 mai 2017 09:30 > À : Julien Escario > Cc : French SysAdmin Group > Objet : Re: [FRsAG] Portail (on dit portaux ?) captif et SSL > > 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 <mailto:esca...@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 <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.
Re: [FRsAG] Portail (on dit portaux ?) captif et SSL
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 smime.p7s Description: Signature cryptographique S/MIME ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Portail (on dit portaux ?) captif et SSL
Le 23/05/2017 à 10:17, Dominique Rousseau a écrit : > Le Tue, May 23, 2017 at 09:30:28AM +0200, SERRUT Arnaud [qqq...@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 smime.p7s Description: Signature cryptographique S/MIME ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Portail (on dit portaux ?) captif et SSL
Le Tue, May 23, 2017 at 10:44:44AM +0200, Julien Escario [esca...@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 [qqq...@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 - 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Portail (on dit portaux ?) captif et SSL
> 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 :-) Sans parler des applications (sur mobile et tablette) qui vont essayer de se connecter, en HTTPS, a leur portail de prédilection, a commencer par les anti-virus. En fait, sur des réseaux ouverts, si on redirige tous le trafic (HTTP/HTTPS) vers le portail captif, il faut faire attention à certains périphériques qui vont bombarder le portail de captif de requêtes, qui peuvent facilement le faire tomber s'il n'est pas correctement dimensionné / protégé. Pour la gestion de la page par défaut en HTTPS, il n'y a pas de solution parfaite. Sur un réseau wifi ouvert, les solution 'pop-up' des systèmes récent les plus courant (IOS, Android, Windows 10) fonctionnent assez bien, mais on est tributaire du terminal. Et cette fenêtre est un navigateur 'limité' qui peut empêcher certaines fonctions du portail captif (javascript). ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Portail (on dit portaux ?) captif et SSL
Oui tout transite par le portail captif. Emmanuel BRENAS Service informatique [1472671273785_logo.png] SCIENCES PO LYON 14, avenue Berthelot 69365 Lyon cedex 07 Tel : 04 37 28 38 31 Bâtiment B – Bureau 3.03 www.sciencespo-lyon.fr<http://www.sciencespo-lyon.fr> www.universite-lyon.fr<http://www.universite-lyon.fr> [1473056700454_image002.jpg]<https://www.facebook.com/iep.lyon/> [1473056744352_image003.png] <https://twitter.com/scpolyon> De : David Ponzone Envoyé : mardi 23 mai 2017 10:26 À : Brenas Emmanuel Cc : SERRUT Arnaud; Julien Escario; French SysAdmin Group Objet : Re: [FRsAG] Portail (on dit portaux ?) captif et SSL Emmanuel, donc ton portail captif reste proxy transparent pour tout le trafic une fois que l’utilisateur est authentifié ? Julien, je fais du portail captif fait-maison avec des bornes WIFI Meraki, qui permettent de rediriger l’utilisateur vers son propre portail captif rudimentaire écrit en quelques lignes de PHP. La doc de Meraki sur le sujet est plutôt pas mal. On peut faire ça aussi avec les bornes Ubiquiti, il y a des exemples fournis par la communauté. Le 23 mai 2017 à 10:05, Brenas Emmanuel mailto:emmanuel.bre...@sciencespo-lyon.fr>> a écrit : Bonjour à tous, juste un petit retour d'expérience. On utilise des portails captif dans nos établissements d'enseignement pour nos réseaux Wifi. Il en existe des payants en logiciel (ucopia par exemple) ou des intégrés à des concentrateur Wifi (comme chez Aruba). On peut aussi utiliser des portails gratuits comme univnaute (https://doc.entrouvert.org/univnautes/stable-iframe-unpidf/index.html) qui est basé sur une distrib pfsense. Pour tout cela on bricole le dhcp pour que la passerelle du vlan distribué corresponde à l'adresse du portail captif et la redirection se fait qu'on ait demandé du https ou non comme url à l'ouverture d'un navigateur (et effectivement ios ou Windows 10 gère automatiquement l'affichage du portail dès que la connexion Wifi se fait). On peut utiliser ces portails (ucopia ou univnaute) pour du réseau filaire. Quand au 802.1x il faut le garder pour du filaire avec un réseau local avec une population d'utilisateur connue et pas des invités temporaires. C'était mes deux centimes 😊 Bonne journée, Manu. Emmanuel BRENAS Service informatique SCIENCES PO LYON 14, avenue Berthelot 69365 Lyon cedex 07 Tel : 04 37 28 38 31 Bâtiment B – Bureau 3.03 www.sciencespo-lyon.fr<http://www.sciencespo-lyon.fr/> www.universite-lyon.fr<http://www.universite-lyon.fr/> <https://www.facebook.com/iep.lyon/> <https://twitter.com/scpolyon> De : FRsAG mailto:frsag-boun...@frsag.org>> de la part de SERRUT Arnaud mailto:qqq...@gmail.com>> Envoyé : mardi 23 mai 2017 09:30 À : Julien Escario Cc : French SysAdmin Group Objet : Re: [FRsAG] Portail (on dit portaux ?) captif et SSL 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 mailto:esca...@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<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
Re: [FRsAG] Portail (on dit portaux ?) captif et SSL
Le Tue, May 23, 2017 at 10:57:18AM +0200, Dominique Rousseau [d.rouss...@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 - 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Portail (on dit portaux ?) captif et SSL
> 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. ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Portail (on dit portaux ?) captif et SSL
Visiblement, tu n’es pas le seul à attendre la RFC qui va bien :) http://community.arubanetworks.com/t5/Technology-Blog/Captive-Portal-why-do-I-get-those-certificate-warnings/ba-p/268921 > Le 23 mai 2017 à 10:44, Julien Escario a écrit : > > Le 23/05/2017 à 10:17, Dominique Rousseau a écrit : >> Le Tue, May 23, 2017 at 09:30:28AM +0200, SERRUT Arnaud [qqq...@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/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Portail (on dit portaux ?) captif et SSL
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-I-get-those-certificate-warnings/ba-p/268921 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 smime.p7s Description: Signature cryptographique S/MIME ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Portail (on dit portaux ?) captif et SSL
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 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-I-get-those-certificate-warnings/ba-p/268921 > > 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/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Portail (on dit portaux ?) captif et SSL
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 smime.p7s Description: Signature cryptographique S/MIME ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Portail (on dit portaux ?) captif et SSL
Alors si tu peux, tu shapes le trafic HTTPS tant que l'utilisateur est pas authentifié. > Le 23 mai 2017 à 12:01, Julien Escario 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/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Portail (on dit portaux ?) captif et SSL
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 smime.p7s Description: Signature cryptographique S/MIME ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Portail (on dit portaux ?) captif et SSL
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 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/
Re: [FRsAG] Portail (on dit portaux ?) captif et SSL
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
Re: [FRsAG] Portail (on dit portaux ?) captif et SSL
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 obtenu
Re: [FRsAG] Portail (on dit portaux ?) captif et SSL
On 29/05/2017 15:44, Julien Escario wrote: > Je crois que le tour de la question est fait Presque : "portaux" c'est uniquement à l'heure de l'apéro :o) signature.asc Description: OpenPGP digital signature ___ Liste de diffusion du FRsAG http://www.frsag.org/
