Cómo los hotspots WiFi legítimos redirigen las solicitudes https

La mayoría de los hotspots redirigen con certificados no válidos.

El navegador / sistema operativo utiliza heurísticas para detectar ese comportamiento.

  

Esta determinación de estar en un portal cautivo o estar en línea se realiza al intentar recuperar la página web enlace

enlace

MacOS y iOS usan enlace (gracias @ceejayoz)

Por ejemplo, Android mostrará una notificación para redirigir el uso a la página de inicio de sesión del portal.

La mayoría de ellos solo usan su propio certificado de punto de acceso y esperan que los usuarios hagan clic en la advertencia y se conecten de todos modos. Personalmente, cuando veo una advertencia de este tipo y sé que es un portal cautivo, cancelo la solicitud y escribo una URL HTTP que no me importa, como http://redirect.me.away y dejo que el portal haga su trabajo a través de HTTP . Una vez que inicie sesión, reintento mi solicitud HTTPS que ahora funciona.

Sin embargo, la mayoría de las veces los evito: no vale la pena dedicar tiempo a llenar sus estupidos formularios de registro, especialmente dada la conexión a menudo deficiente que ofrecen. Tal vez algún día tengamos una red de punto de acceso EAP-Enterprise en la que se registre una vez y luego su dispositivo se conecte automáticamente con un nombre de usuario / contraseña y todo funcione a la perfección en segundo plano.

Hay una cosa que la red cautiva no puede hacer: redirigir a su propia página y devolver el certificado de servidor correcto. En principio, existen esas posibilidades: (a) no redirigir https en absoluto. (b) Redirigir con un certificado autofirmado. (c) devolver su propio certificado, por lo que la negociación https fallará. (d) mata inmediatamente cualquier intento de conexión con https.

Desde que cambié el código de red en iOS de http a https, encontré que más de una red cautiva mató inmediatamente cualquier intento de conexión. Eso sería una indicación bastante fuerte para una aplicación de que hay una red cautiva. Luego, la aplicación puede utilizar una mejor detección al visitar una de las URL de Google o Apple que se proporcionan para este fin y, si no responden como se esperaba, entonces definitivamente tiene una red cautiva. La aplicación puede ir desde allí e iniciar un navegador o dejar que el usuario acceda a la configuración.

No sé qué hacen exactamente los navegadores, pero pueden detectar que https se rechazó, y visitan automáticamente una página http que va al sitio de inicio de sesión.

Los portales cautivos actúan esencialmente como un intermediario, redirigiendo las solicitudes de los clientes a un sitio diferente (su página de inicio de sesión). Técnicamente, este es el mismo tipo de comportamiento que HTTPS intenta evitar, porque eso es lo que hacen los malos en las conexiones HTTP no seguras.

Por lo tanto, cuando puede conectarse a un sitio HTTPS desde un portal cautivo sin una advertencia y sin haber iniciado sesión antes en el portal, ocurrió una de las siguientes situaciones:

1. El portal cautivo no intercepta el tráfico SSL, sino que lo permite. Como resultado, se le envía la página de destino de inmediato, sin haber iniciado sesión nunca. Sin embargo, desde el punto de vista del proveedor, eso elimina en gran medida el propósito de tener un portal cautivo en primer lugar.
2. Una de las CA en su lista de CA de confianza, o una sub-CA verificada (directa o indirectamente) por una de esas CA raíz es deshonesta (o fue pirateada), aunque esto último es poco probable si el operador de WiFi es incluso legítimo. ). Como resultado, el punto de acceso tiene un certificado comodín (que coincide con el nombre de cualquier servidor) o puede emitir certificados arbitrarios que son aceptados por su navegador. Como resultado, ingresa una URL HTTPS y en su lugar obtiene la página de inicio de sesión sin ningún aviso.

El segundo ejemplo es una debilidad inherente en el diseño de certificados: su navegador / proveedor de sistema operativo (o, en el caso de los dispositivos de la compañía, el administrador de su sistema) ha implementado un certificado de CA en la máquina, esencialmente diciendo que "esta CA nunca emita certificados para cualquier servidor a nadie más que a los operadores legítimos de ese servidor). A menos que verifique cada CA de forma manual y elimine las cuestionables (lo cual es poco práctico para una persona), está confiando ciegamente en sus afirmaciones.

Si no se aplica ninguno de los dos casos anteriores, sucederá uno de los siguientes:

1. La conexión fallaría (debido a un servidor inalcanzable) hasta que se conecte a un servidor HTTP sin formato, sea redirigido a la página de inicio de sesión e inicie sesión
2. Recibirá una advertencia sobre un certificado no válido: el nombre del servidor no coincide o porque el certificado no es de una CA confiable. Si ignora esta advertencia, obtendrá la página de inicio de sesión.