Errores de certificado SSL en portales cautivos

10

Situación: huéspedes del hotel que intentan acceder a Internet a través de nuestro portal cautivo. Problema: Google, Yahoo y ahora más y más sitios que redirigen todas las páginas de inicio a HTTPS para que los invitados reciban un error de Certificado cuando los redirigimos a nuestra página de inicio de sesión. Apreciar el propósito de SSL es hacer exactamente esto, pero me pregunto si hay otra forma de administrar un proceso de confirmación de inicio de sesión de invitado para confirmar su identidad, antes de habilitar el acceso a través del firewall. Está asustando a los invitados que no entienden. Básicamente necesita una arquitectura diferente para un portal cautivo / proceso de autenticación y se pregunta qué piensa alguien. Gracias.

ssl redirect

Posible solución: WPA2-Enterprise con un servidor de autenticación Radius.

— Ajedi32

Esta no es una solución, pero por el momento los servidores son una solución alternativa. Permita que los usuarios accedan a https libremente, y en el primer hit http, serán redirigidos a medida que la industria se mueva más y más a https, esto será obsoleto.

— cusco

6

La definición completa de "portal cautivo" gira en torno a "redirigir al usuario sin su conocimiento", que es exactamente una de las cosas que SSL fue creado para evitar.

Si la primera URL que el navegador intenta abrir es HTTPS, no hay forma de redirigir el tráfico sin crear un error de certificado.

— Massimo
fuente

44

Sí, creo que el OP lo entiende. La pregunta era: ¿cuál es la alternativa? (Por ejemplo, si todos los sitios existentes usaran HTTPS, ¿cómo podría "administrar un proceso de confirmación de inicio de sesión de invitado" sin un portal cautivo?)

— Ajedi32

5

El Proyecto Chromium tiene una buena página que describe cómo funciona su lógica para detectar portales cautivos:

Intente conectarse (HTTP simple) a un host conocido + URI
Esperar HTTP 204 No Content
Si se recibe una respuesta diferente, suponga que es un portal cautivo.

Hay otros detalles en el enlace proporcionado con respecto a cómo manejan las fallas de DNS cuando intentan resolver el host conocido, etc. Este es solo un ejemplo, pero (en mi experiencia personal) los diseños de SO modernos están utilizando procesos similares a este para detectar y avisar al usuario incluso, en algunos casos, antes de que el usuario abra un navegador. (Considere: alguien que solo quiere usar un cliente IMAP u otro servicio que no sea HTTP). En ese caso, la detección no ocurre a través de SSL / TLS, por lo que se evita su preocupación.

RFC 6585 Sección 6 propone un nuevo código de estado HTTP 511 Network Authentication Requiredque no ayuda a su caso SSL / TLS pero es otro estándar que podría considerar si aún no lo usa.

— William Price
fuente

Android también tiene soporte para detectar portales cautivos. Cuando detecta un portal cautivo, muestra un mensaje en la barra de estado. La redacción es algo así como "Iniciar sesión en la red inalámbrica". Eso sucede incluso si ninguna aplicación ha intentado usar la conexión todavía. En algún momento también noté que un portal cautivo enviaba una redirección 30x con un encabezado HTTP adicional, lo que indica que se trataba de un portal cautivo, y el cuerpo contenía algunos datos XML. No sé si ese es un comportamiento estándar.

— Kasperd

0

En cualquier caso, si los usuarios reciben un error de certificado es porque el Certificado no coincide con el nombre de host del Sitio .

En su caso, esto significa que está redirigiendo a los usuarios a su portal sin cambiar la URL. Los usuarios ven " http://www.google.com " en su barra de direcciones pero su portal en la pantalla. Estos no coinciden, obviamente, y el certificado tampoco.

Debe redirigirlos en HTTP (antes del salto HTTPS) a la dirección de su portal (o nombre del servidor), hacer que inicien sesión allí y luego redirigirlos nuevamente al destino deseado, que coincidirá correctamente.

Consulte https://en.wikipedia.org/wiki/URL_redirection#HTTP_status_codes_3xx para saber cómo realizarlo con códigos HTTP 3xx, especialmente 303.

— Envidia
fuente

La mayoría de los usuarios probablemente no escriben https:// , pero los marcadores almacenados u otros mecanismos de fijación pueden dar como resultado que la primera solicitud vaya a un servicio basado en HTTPS y, por lo tanto, falle porque el protocolo de enlace TLS falla antes de llegar a la capa de protocolo HTTP para una redirección. Además de los marcadores, los ejemplos de dicha "fijación" incluyen una barra de búsqueda del navegador que tiene conocimiento previo de que el proveedor de búsqueda prefiere consultas a través de HTTPS; o una aplicación móvil que se conecta a servicios de red seguros.

— William Price

-1

La solución temporal es guiar a los usuarios para que comiencen la URL comenzando con "http" solo después de las señales wifi conectadas.

pero desafortunadamente, a los usuarios no les gusta. dicen "qué complicado servicio de wifi tenías"

— versi satu
fuente