El comportamiento depende del navegador. Si el navegador realmente enviará la solicitud HTTPS destinada a Facebook al portal cautivo, entonces es claramente una vulnerabilidad del navegador. Pero hay otras formas de manejar la situación.
Recientemente he tenido que usar una red con un portal cautivo unas cuantas veces. Y en esos casos empecé Chromium, que tenía un par de pestañas de Facebook abiertas desde una sesión anterior.
Lo que sucedió fue que se mostraba un mensaje de error adecuado. Pero al mismo tiempo, Chromium abrió una nueva pestaña que accedía a una URL HTTP específica con la intención real de ser secuestrada por el portal cautivo. Tan pronto como pasé el portal cautivo, las pestañas de Facebook se recargarían automáticamente y esta vez no obtendría un error.
Así que parece que Chromium detecta la presencia de un portal cautivo, lo abre de forma segura y, finalmente, lo detecta una vez que haya pasado el portal cautivo.
La detección de un portal cautivo similar existe en Android e iOS, aunque no está vinculado al navegador, sino que se realiza como parte de la asociación con el punto de acceso.
Veo algunos conceptos erróneos en su comprensión de cómo funcionan los portales cautivos. Los portales cautivos con los que me he encontrado ciertamente funcionaron de una manera diferente.
No se realizó ninguna intercepción para el tráfico DNS. Mientras use el servidor DNS proporcionado a través de DHCP, su computadora podrá realizar búsquedas de DNS sin restricciones sin haber accedido al portal cautivo.
Tampoco se extraen trucos de ICMP. Más bien, uno de los enrutadores en la ruta legítima entre su computadora y el servidor secuestrará las conexiones TCP al puerto 80. Una vez que la conexión TCP haya sido secuestrada, se enviará una redirección al portal cautivo al navegador. En las implementaciones adecuadas, esto redirige a una URL de HTTPS y de alguna manera incluye información sobre la URL original, de modo que pueda ser enviado allí más tarde. Toda la comunicación con el portal cautivo se realiza mediante un certificado legítimo para un nombre de dominio que realmente pertenece al portal cautivo.
Este enfoque funciona para HTTP, pero no para HTTPS. El enrutador que realiza el secuestro no tendrá un certificado válido para el sitio al que está accediendo, por lo que en cualquier navegador seguro recibirá una advertencia de certificado si se realiza el mismo secuestro para HTTPS.
Hay tres maneras de evitar que esto no funcione para HTTPS:
- Confíe en que los usuarios ignoren las advertencias de seguridad y acepten que su información privada será interceptada incluso después de haber sido presentada para una advertencia muy detallada sobre el riesgo.
- Confíe en que los usuarios entiendan cómo funciona todo y, por su cuenta, abra una URL HTTP para ser secuestrado y luego sepa que debe ir a la URL HTTPS original después de haber pasado el portal cautivo.
- Permita que el software del cliente detecte la presencia de portales cautivos y trate el problema de manera apropiada. Esto todavía depende de que los usuarios puedan detectar si un portal cautivo está intentando realizar ataques de phishing, pero al menos no filtra ninguna cookie.