Bonjour, Avec un peu de retard, je tenais à remercier Antoine pour son récapitulatif vraiment complet et précis !
Je crois que le tour de la question est fait, les perspectives en plus. Encore merci Antoine, Julien Le 23/05/2017 à 14:40, Antoine BOISJIBAULT a écrit : > Bonjour, > > > > Systems Engineer chez UCOPIA, société française spécialisée dans le portail > captif, je me permets de vous faire part de notre retour d'expérience sur ce > sujet, qui s'applique à UCOPIA mais aussi à toute technologie de portail > captif. > > > > Sujet récurrent chez nos clients et abordé sur notre blog : > http://www.ucopia.com/actualites/experience-utilisateur-navigation-wifi/ > > Ci-dessous un complément d'informations. @Julien : la dernière partie devrait > intéresser votre confrère. > > > > Pour pallier à ces problématiques d'erreur "HSTS" remontées par les > utilisateurs, les éditeurs d'OS/Hardware ont implémenté un assistant dit > "CNA". > ("Captive Network Assistant"). > > Cet assistant permet d'éviter à l'utilisateur de lancer un navigateur web afin > de faire apparaître le portail captif. (et potentiellement tomber sur > https://google.fr et recevoir une erreur HSTS. > > > > De façon vulgarisée : > > Un portail captif est un mécanisme qui intercepte le flux utilisateur et lui > présente du contenu qu’il n’a pas sollicité par lui-même, pour le forcer à > s’authentifier. > > Le protocole HTTPs (et la surcouche HSTS qui l’utilise), ont pour but de > garantir que le contenu reçu par un client est bien celui qu’il demande. > > Il y a ici incompatibilité entre les deux technologies. > > Voici le détail de ce qu’il se passe : > > * Lorsqu’un utilisateur non authentifié sur UCOPIA (ou tout autre portail > captif) tente d’accéder à un site sécurisé (https://www.google.fr, ou > https://www.mabanque.com ), le portail captif (lui aussi sécurisé, en > HTTPS) > est présenté. > * Le navigateur utilisé récupère alors le certificat du portail captif et > non > celui du site demandé initialement, d’où cette alerte sécurité qui peut > être > simplement acceptée en HTTPS standard (et qui est bloquante en HSTS). > > > > C’est pour cela que la plupart des éditeurs de systèmes d’exploitation (pour > ordinateurs ou mobiles) implémentent depuis récemment des assistants de > connexion aux portails captifs : > > * Apple CNA pour les appareils mobiles (et MAC) Apple : la fameuse page qui > s’ouvre toute seule lorsque vous vous connectez au wifi. > * Cela apparaît sous forme de notification pour les appareils Android > (requête > vers http://connectivitycheck.gstatic.com/generate_204 sous Marshmallow > et > http://clients3.google.com/generate_204 pour Kitkat). > * Le Consistent Connection Handling pour Microsoft, > o qui fonctionne comme pour les appareils de marque Apple sur mobile > o qui propose l’ouverture d’un navigateur sur Windows 8.1 > o qui affiche une notification dans le système tray sur Windows 7 > > > > Ainsi le problème de la première page en HTTPS ne se pose pas lorsque l’on > utilise ces mécanismes : cela doit être pris en charge par la brique portail > captif. > > Vous pourrez vérifier alors qu’une notification invitant l’utilisateur à > ouvrir > son navigateur est envoyée sur les smartphones et tablettes concernées. > > * Pour les équipements sous Windows 8 et 10 : vous pouvez passer par > l’assistant Wi-Fi. > > Une fois authentifié sur UCOPIA, l’utilisateur ne verra plus cette alerte > sécurité. > > Autre alternative possible : modifier la page d’accueil par défaut du > navigateur > sur une page HTTP permettra la non apparition du message d’alerte de > certificat. > > > > Si l’utilisateur ne passe pas par ces mécanismes, (soit parce qu’il clique > volontairement sur leur fermeture, soit parce que son système n’en n’est pas > équipé), et que sa première requête est en HTTPs voire HSTS : > > * Il aura une erreur dans son navigateur lui indiquant qu’il a demandé > https://www.google.com et que c’est https://controller.access.network/ > (par > défaut dans le cas d’Ucopia) qui lui répond. > * Cette erreur pourra être ignorée pour des sites en HTTPs. > * Si le site initialement demandé supporte le HSTS, alors l’erreur ne pourra > être ignorée > > > > Pour obtenir la redirection vers le portail captif, l'utilisateur peut > simplement solliciter une page en HTTP afin que la redirection puisse être > réalisée. > > > > > > Enfin, sachez que les nouvelles moutures des navigateurs web les plus courant > commencent à bénéficier d'un Assistant dédié aux notions de portail captif, un > exemple du rendu sur Firefox 52 : > > Un exemple du rendu de l’alerte obtenue (plus de blocage HSTS) ainsi qu’une > ouverture du portail captif dans un nouvel onglet avec un appel à > http://detectportail.firefox.com/success.txt qui permet la redirection vers le > portail : > > > > L’alerte obtenue en premier onglet : > > > > Images intégrées 3 > > > > En second onglet (ouvert par défaut) l’utilisateur verra apparaître le portail > captif UCOPIA. > > > > Images intégrées 4 > > > Cela devrait arriver prochainement chez les autres éditeur tels que Chrome ou > IE, étant déjà disponible sous Chromium. > > > Un groupe de travail IETF à été ouvert afin de suivre les avancées et mettre > en > place des normes en réponse à ces problématiques liées aux portails captif > : https://www.ietf.org/mailman/listinfo/captive-portals > > > Antoine > > > > Le 23 mai 2017 à 12:31, David Ponzone <david.ponz...@gmail.com > <mailto:david.ponz...@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 <esca...@azylog.net > <mailto:esca...@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/ > >
smime.p7s
Description: Signature cryptographique S/MIME
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
