Erreurs de certificat SSL dans les portails captifs


10

Situation: les clients de l'hôtel tentent d'accéder à Internet via notre portail captif. Problème: Google, Yahoo et maintenant de plus en plus de sites redirigent toutes les pages d'accueil vers HTTPS afin que le client reçoive une erreur de certificat lorsque nous les redirigeons vers notre page de connexion. Le but de SSL est de faire exactement cela, mais demandez-vous s'il existe un autre moyen de gérer un processus de confirmation de connexion des invités pour confirmer leur identité, avant d'autoriser l'accès via le pare-feu. Ça fait flipper des invités qui ne comprennent pas. Fondamentalement, vous avez besoin d'une architecture différente pour un processus de portail / d'authentification captif et vous demandez ce que vous pensez. Merci.


Solution possible: WPA2-Enterprise avec un serveur d'authentification Radius.
Ajedi32

Ce n'est pas une solution, mais pour le moment des serveurs comme solution de contournement. Autoriser les utilisateurs à accéder librement à https, et lors du premier accès http, ils seront redirigés à mesure que l'industrie se déplace de plus en plus vers https, ce sera obsolète.
cusco

Réponses:


6

Toute la définition de «portail captif» s'articule autour de «rediriger l'utilisateur à son insu», ce qui est exactement l'une des choses que SSL a été créé pour éviter.

Si la première URL que le navigateur tente d'ouvrir est une URL HTTPS, il n'y a aucun moyen de rediriger le trafic sans créer d'erreur de certificat.


4
Oui, je pense que l'OP comprend cela. La question était: quelle est l'alternative? (Par exemple, si tous les sites existants utilisaient HTTPS, comment pourriez-vous "gérer un processus de confirmation de connexion d'invité" sans portail captif?)
Ajedi32

5

Le projet Chromium a une bonne page décrivant comment leur logique fonctionne pour détecter les portails captifs:

  1. Tentative de connexion (HTTP simple) à un hôte bien connu + URI
  2. Attendre HTTP 204 No Content
  3. Si une réponse différente est reçue, supposez qu'il s'agit d'un portail captif.

Il existe d'autres détails dans le lien fourni concernant la façon dont ils gèrent les échecs DNS lors de la résolution de l'hôte bien connu, etc. et invite l'utilisateur même, dans certains cas, avant que l'utilisateur n'ouvre un navigateur. (Considérez: quelqu'un qui veut uniquement utiliser un client IMAP ou un autre service non HTTP.) Dans ce cas, la détection ne se produit pas sur SSL / TLS, donc votre souci est évité.

La section 6 de la RFC 6585 propose un nouveau code d'état HTTP 511 Network Authentication Requiredqui n'aide pas votre cas SSL / TLS mais est une autre norme que vous pourriez envisager si vous ne l'utilisez pas déjà.


Android prend également en charge la détection des portails captifs. Lorsqu'il détecte un portail captif, il affiche un message sur la barre d'état. Le libellé est quelque chose comme "Se connecter au réseau sans fil". Cela se produit même si aucune application n'a encore essayé d'utiliser la connexion. À un moment donné, j'ai également remarqué un portail captif envoyant une redirection 30x avec un en-tête HTTP supplémentaire, indiquant qu'il s'agissait d'un portail captif et que le corps contenait des données XML. Je ne sais pas si c'est un comportement standard.
kasperd

0

Dans tous les cas, si les utilisateurs reçoivent une erreur de certificat, c'est parce que le certificat ne correspond pas au nom d'hôte du site .

Dans votre cas, cela signifie que vous redirigez les utilisateurs vers votre portail sans modifier l'URL. Les utilisateurs voient " http://www.google.com " dans leur barre d'adresse mais votre portail à l'écran. Celles-ci ne correspondent pas, évidemment, et le certificat non plus.

Vous devez les rediriger en HTTP (avant le saut HTTPS) vers votre adresse de portail (ou nom de serveur), les faire vous connecter là, puis les rediriger vers la destination prévue, qui correspondra correctement.

Voir https://en.wikipedia.org/wiki/URL_redirection#HTTP_status_codes_3xx pour savoir comment l'exécuter avec des codes HTTP 3xx, spécialement 303.


La plupart des utilisateurs ne sont pas probablement de type https:// , mais les signets enregistrés ou d' autres mécanismes d ' ancrage peut entraîner la première demande d' aller à un service basé sur le protocole HTTPS et de ne pas ainsi parce que TLS handshake échoue avant d' atteindre la couche de protocole HTTP pour une redirection. Outre les signets, des exemples de ce type d'épinglage incluent la barre de recherche d'un navigateur sachant au préalable que le moteur de recherche préfère les requêtes via HTTPS; ou une application mobile se connectant à des services réseau sécurisés.
William Price

-1

la solution temporaire consiste à guider les utilisateurs pour démarrer l'URL commençant par "http" uniquement après les signaux wifi connectés.

mais malheureusement, les utilisateurs ne l'aiment pas. ils disent "à quel point le service wifi était compliqué"

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.