Comment les portails captifs devraient-ils rediriger?
J'ai récemment lu cette question , ce qui me fait poser une question de suivi: comment ce portail captif essaie-t-il de rediriger l'utilisateur? Un commentaire très voté dit que c'est mal faire, après tout.
Donc, si l'on avait un portail captif légitime et bien intentionné, comment devrait-il rediriger les utilisateurs vers le portail tout en gardant à l'esprit la sécurité et la commodité des utilisateurs? C'est évidemment mauvais pour la sécurité et la commodité si les utilisateurs obtiennent une incompatibilité de certificat comme dans la question liée.
Techniquement, un portail captif est toujours une attaque de l'homme du milieu. Par conséquent, toutes les techniques contre MitM avertiront et devraient les avertir, donnant à l'utilisateur le pouvoir de décider de faire confiance ou non. Certains navigateurs ont détection de portail captif , en général, autorisant temporairement la redirection sans afficher aucune page avec le domaine d'origine.
Les besoins de sécurité contemporains rendent difficile la mise en œuvre transparente de portails captifs. Heureusement, les développeurs de navigateurs Web et de systèmes d'exploitation réalisent l'importance de signaler l'existence de ce statut intermédiaire entre une connexion ou non à Internet, ce qui réduit au minimum les cas de défaillance.
De ce point de vue, rediriger vers une page de connexion de portail captif séparée avec un certificat correctement signé et correspondant serait moins mal que d'afficher la page de connexion directement avec n'importe quel domaine.
Avons-nous d'autres options?
Nous pourrions effectuer la redirection uniquement sur HTTP simple pour éviter l'erreur de non-concordance de certificat. Ce serait toujours un MitM, mais sur un protocole qui n'a pas été conçu pour le détecter. Cela aurait parfaitement fonctionné avant HTTP Strict Transport Security (HSTS) contre notre attaque de déclassement du protocole , ce que serait ce genre de portail captif.
Aucune redirection du tout. Bloquez simplement tout le trafic avant que l'utilisateur n'ouvre manuellement l'URL de la page de connexion et ne se connecte. Sécurité maximisée, au détriment de la commodité. Maintenant, vous devez informer vos utilisateurs de cet arrangement, ce qui signifie généralement un besoin d'assistance supplémentaire. Même si vous dites à vos utilisateurs avec des images qu'ils doivent saisir cette adresse dans la barre d'adresse , certains d'entre eux essaient toujours de rechercher l'adresse à partir de Google.
Abandonnez le WiFi ouvert et utilisez une autre méthode d'authentification. Pas besoin de portail captif ni de page de connexion. Besoin de soutien important. L'entreprise WPA2 serait techniquement idéale car vous n'avez pas besoin d'une seule clé pré-partagée, mais elle est moins connue du groupe cible (personnes utilisant le WiFi en accès libre).
En même temps, c'est la raison même pour laquelle des portails captifs existent toujours. Mon idée d'un remplacement approprié pour les portails captifs serait une URL HTTP standard standardisée à laquelle les navigateurs tenteraient d'accéder lorsqu'un élément bloquant la connexion est détecté. Cette page effectuerait ensuite la redirection vers la page de connexion avec HTTPS et un certificat approprié, et le navigateur devrait détecter toute autre chose comme une attaque. Mais ce n'est que mon rêve, loin de la réalité. Les portails captifs existeront tant qu'ils fonctionneront dans la pratique.
Malheureusement, il n'y a pas de solution parfaite ici, étant donné que le but même de TLS est de se protéger contre ce type d'attaque. Mais je pense que la meilleure façon de procéder est la suivante:
- Pour les connexions HTTPS, bloquez-les simplement. N'essayez pas de rediriger. Cela donnera à l'utilisateur un message d'erreur indiquant aucun accès à Internet plutôt qu'un avertissement de sécurité. C'est mieux.
Pour les connexions HTTP, vous devez répondre avec 511 Authentification réseau requise :
Le code d'état 511 indique que le client doit s'authentifier pour accéder au réseau.
[...]
Le statut 511 NE DEVRAIT PAS être généré par les serveurs Origin; il est destiné à être utilisé en interceptant des proxys qui sont interposés comme moyen de contrôler l'accès au réseau.