Le fossé protocolaire des portails captifs

Dans cette série de blogs, nous voulons montrer les problèmes que les appareils des utilisateurs finaux, tels que les smartphones, rencontrent avec les portails captifs, car la détection et la communication avec ces appareils ne sont pas normalisées. Un profane peut penser que les fabricants de matériel réseau et de systèmes d’exploitation ont résolu cette tâche depuis longtemps en définissant un protocole réseau, mais ce n’est pas le cas. Il y a une grande lacune dans le paysage protocolaire et les solutions actuellement disponibles sont des solutions de contournement, parfois mieux appelées « dirty hacks ».

La lacune du protocole

Il n’existe actuellement aucun protocole réseau permettant une communication normalisée entre un portail captif et les appareils de l’utilisateur final. Il devrait être possible pour l’appareil d’effectuer des opérations simples, comme l’authentification de l’utilisateur avant l’accès au réseau. Dans les entreprises, cette fonction peut être remplie par 802.1x, mais cette technologie ne peut être utilisée que dans les réseaux d’entreprise, car elle ne permet que des certificats ou une authentification par nom d’utilisateur et mot de passe, mais aucune des nombreuses autres fonctions nécessaires aux portails captifs. De nombreux utilisateurs finaux, comme les clients d’un hôtel, sont totalement incapables de faire face à une connexion WPA2-Enterprise demandant trop de détails. De plus, il n’y a pas d’aide possible dans un tel formulaire de connexion.

Le problème de la redirection

Pour accéder à un réseau, un utilisateur WiFi doit s’authentifier avec son nom d’utilisateur et son mot de passe, acheter un billet ou simplement accepter les conditions d’utilisation. Il existe de nombreuses variantes de types de connexion, mais en fin de compte, le problème est toujours le même. L’utilisateur veut être redirigé vers la page de connexion sans avoir à agir manuellement. Comme il n’existe pas de protocole standard, les portails de Capitale ont recours à des manipulations partiellement douteuses du trafic réseau pour réaliser cette fonctionnalité.

Il y a longtemps, les utilisateurs devaient ouvrir manuellement leur navigateur web et ouvrir un site web non crypté (HTTP), afin que le portail d’entreprise puisse les rediriger vers la page de connexion au moyen d’une réponse HTTP 302.

Le nombre de sites web cryptés via TLS augmente depuis longtemps et de manière spectaculaire ces deux dernières années, grâce à l’autorité de certification Let’s Encrypt. C’est une excellente nouvelle pour les internautes, mais cela évite de rediriger un navigateur vers la page de connexion. Si un navigateur appelle un site web crypté via HTTPS, il ne peut pas être redirigé sans un avertissement de certificat. À l’époque, nous faisions de telles redirections en espérant que l’invité ignorerait l’avertissement du certificat SSL/TLS. Cela a toujours été une mauvaise idée et personne ne devrait apprendre aux gens ordinaires un tel comportement, qui aurait des conséquences dramatiques sur les sites web réels.

Au cours des dernières années, TLS a reçu des extensions optionnelles qui le rendent plus sûr comme

• HSTS (HTTP Strict Transport Security)
• et HPKP (HTTP Persistent Key Pinning).

HSTS est une extension de confiance dès la première utilisation, qui indique au navigateur qu’il doit accéder à ce site web uniquement via TLS afin d’éviter le stripping TLS (qui est malheureusement toujours possible lors de l’envoi de courriels avec SMTP et STARTTLS).
HPKP, également une extension « trust-on-first-use », indique au navigateur de vérifier la somme de contrôle du certificat, de sorte qu’aucun autre certificat n’est autorisé, même s’il est valide (par exemple, s’il est émis par un pare-feu d’entreprise et si l’autorité de certification est installée sur le client).

Ces deux extensions ont pour effet pratique qu’un invité ne peut pas ignorer un avertissement concernant un certificat. C’est sans aucun doute une bonne chose pour la confiance dans les connexions cryptées. Pour cette raison, notre IACBOX ne redirige pas les connexions TLS vers la page de connexion depuis de nombreuses années.

Les solutions de contournement

Depuis de nombreuses années maintenant, la majorité des appareils dans un WiFi invité sont des appareils mobiles, il fallait donc trouver une solution à ce problème. Les deux grands acteurs – Google et Apple – ont trouvé une solution similaire. Ils effectuent un appel HTTP non chiffré vers un serveur spécifique au fournisseur et s’ils obtiennent autre chose qu’une réponse attendue (comme une redirection), un navigateur minimaliste – appelé « Captive Browser » – est ouvert. Ainsi, le problème des pages web cryptées est contourné et, mieux encore, aucun navigateur ne doit être ouvert manuellement. Cette fonctionnalité pose également un énorme problème de protection de la vie privée, mais c’est une autre histoire.

Non seulement les appareils mobiles, mais aussi les systèmes d’exploitation comme Windows à partir de la version 8 ou les navigateurs actuels comme Firefox et Google Chrome effectuent ce type de vérification de la connectivité.

Cette vérification de la connectivité est venue à la rescousse de la relation difficile entre l’utilisateur final et les portails captifs, mais les différentes solutions et les états internes non documentés des appareils clients rendent ce processus fragile.

WISPr

Un autre protocole dans ce domaine est le WISPr qui a été conçu pour permettre l’itinérance entre les réseaux 3/4G et WiFi. Ce protocole définit également une interface XML sur HTTPS par laquelle l’appareil de l’utilisateur final apprend qu’il se trouve derrière un portail captif et l’URL de la page de connexion. Cette réponse est nécessaire pour que les appareils Apple ouvrent leur navigateur captif. Android et Windows 8 et les versions ultérieures le supporteraient également, mais la vérification de la connectivité est suffisante pour ouvrir leur navigateur captif. Mais le WISPr ne résout pas le problème principal car l’appareil de l’utilisateur final doit appeler le portail captif.

Nous avons besoin d’une vraie solution

Une lueur d’espoir réside dans le groupe de travail capport de l’IETF, qui travaille sur de nouveaux protocoles, des extensions des protocoles actuels et des API pour permettre un mode de communication normalisé et la détection des portails captifs. Dans cette série de blogs, nous souhaitons examiner de plus près les développements actuels de ce groupe de travail.

Un pas petit mais important a déjà été fait – RFC-7710, qui définit une option DHCP pour IPv4 et IPv6 qui envoie l’URL de la page de connexion à l’appareil de l’utilisateur final et lui indique ainsi qu’il se trouve derrière un portail captif. L’IACBOX supporte cette option depuis 2016, mais nous n’avons pas encore vu d’appareil qui l’utilise réellement.

Cela montre le problème principal ici – sans le soutien des principaux systèmes d’exploitation mobiles – rien ne changera la situation actuelle.

Voici le second billet de blog Current state of capport RFC.