[FRsAG] Portail (on dit portaux ?) captif et SSL

[KASH]

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 <***@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>

[Laurent]

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..

[Julien Escario]

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

[Jonathan Leroy]

Le 22 mai 2017 à 12:15, Julien 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.
_______________________________________________
Liste de diffusion du FRsAG
h

[Julien Escario]

Le 22/05/2017 à 14:07, Jonathan Leroy a écrit :
> Le 22 mai 2017 à 12:15, Julien 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

[David Ponzone]

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 <***@azylog.net> a écrit :
>
> Le 22/05/2017 à 14:07, Jonathan Leroy a écrit :
>> Le 22 mai 2017 à 12:15, Julien 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/

[Brenas Emmanuel]

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 : [phone]

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 <frsag-***@frsag.org> de la part de SERRUT Arnaud <***@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 <***@azylog.net<mailto:***@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/

[David Ponzone]

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 <***@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 <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
>
> <OutlookEmoji-1472671273785_logo.png.png>
>
> SCIENCES PO LYON
> 14, avenue Berthelot
> 69365 Lyon cedex 07
> Tel : [phone]
> Bâtiment B – Bureau 3.03
> www.sciencespo-lyon.fr <http://www.sciencespo-lyon.fr/>
> www.universite-lyon.fr <http://www.universite-lyon.fr/>
> <OutlookEmoji-1473056700454_image002.jpg.jpg> <https://www.facebook.com/iep.lyon/> <OutlookEmoji-1473056744352_image003.png.png> <https://twitter.com/scpolyon>
>
>
> De : FRsAG <frsag-***@frsag.org <mailto:frsag-***@frsag.org>> de la part de SERRUT Arnaud <***@gmail.com <mailto:***@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 <***@azylog.net <mailto:***@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.
> 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/ <http://www.frsag.org/>
>
> _______________________________________________
> Liste de diffusion du FRsAG
> http://www.frsag.org/ <http://www.frsag.org/>

[Brenas Emmanuel]

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 : [phone]

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 <***@gmail.com>
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 <***@sciencespo-lyon.fr<mailto:***@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



<OutlookEmoji-1472671273785_logo.png.png>



SCIENCES PO LYON
14, avenue Berthelot
69365 Lyon cedex 07
Tel : [phone]
Bâtiment B – Bureau 3.03
www.sciencespo-lyon.fr<http://www.sciencespo-lyon.fr/>
www.universite-lyon.fr<http://www.universite-lyon.fr/>
<OutlookEmoji-1473056700454_image002.jpg.jpg><https://www.facebook.com/iep.lyon/> <OutlookEmoji-1473056744352_image003.png.png><https://twitter.com/scpolyon>


________________________________
De : FRsAG <frsag-***@frsag.org<mailto:frsag-***@frsag.org>> de la part de SERRUT Arnaud <***@gmail.com<mailto:***@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 <***@azylog.net<mailto:***@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.
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/

[Dominique Rousseau]

Le Tue, May 23, 2017 at 09:30:28AM +0200, SERRUT Arnaud [***@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: [phone] - fax: [phone] - http://www.neuronnexion.coop
_______________________________________________
Liste de diffusion du FR

[Julien Escario]

Le 23/05/2017 à 10:17, Dominique Rousseau a écrit :
> Le Tue, May 23, 2017 at 09:30:28AM +0200, SERRUT Arnaud [***@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

[Dominique Rousseau]

Le Tue, May 23, 2017 at 10:44:44AM +0200, Julien 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 [***@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: [phone] - fax: [phone] - http://www.neuronnexion.coop
_______________________________________________
Liste de diffusion du FRsAG
http://www

[Dominique Rousseau]

Le Tue, May 23, 2017 at 10:57:18AM +0200, Dominique 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: [phone] - fax: [phone] - http://www.neuronnexion.coop
_______________________________________________
L

[David Ponzone]

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 <***@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 [***@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/

________________________________________

[David Ponzone]

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 <***@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-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

[David Ponzone]

Alors si tu peux, tu shapes le trafic HTTPS tant que l'utilisateur est pas authentifié.


> Le 23 mai 2017 à 12:01, Julien 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/

__________________________________________

[David Ponzone]

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 <***@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/

______________________________________________

[Antoine BOISJIBAULT]

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 <***@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 <***@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/
>

[Julien Escario]

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 <***@gmail.com
> <mailto:***@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 <***@azylog.net
> <mailto:***@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/
>
>

[merlin8282]

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)