Tengo una configuración de portal cautiva para mi organización que obliga a los usuarios a la autenticación antes de que se me permita el acceso a la red. El desafío es que cuando un usuario abre su navegador y su página de inicio está https (por ejemplo, enlace ) y redirigir su tráfico a http://myportal.company.com el usuario final recibe un error.
Como la web ha predeterminado más y más HTTPS (¡lo cual es bueno!) ahora me está causando un problema.
¿Qué opciones tengo?
Un portal cautivo es esencialmente hacer un hombre en el ataque central. HTTPS y otros protocolos que usan SSL / TLS están explícitamente para detectar y prevenir este tipo de ataques en el medio. Esto te deja con dos opciones: no hagas un hombre en el ataque central ni hagas que el cliente confíe en el hombre del medio. Todas las soluciones totalmente transparentes requieren que usted tenga algún control del cliente.
En muchos casos, confiar en el hombre del medio es posible si puede agregar el hombre en la CA central del portal cautivo como de confianza para el cliente. En algunos sistemas como Windows, esto se puede hacer de manera automatizada (política de grupo). Si los navegadores verán que el certificado está firmado por esta CA agregada explícitamente, también deshabilitará la verificación de la fijación de claves públicas (explícita y HPKP integrada). Pero tenga en cuenta que no funcionará en todos los casos, es decir, hay aplicaciones que no son de navegador, como Dropbox, que continúan realizando la fijación de certificados y por lo tanto ya no funcionarán.
El no hacer un hombre en el centro de los ataques funciona si configura el portal cautivo como un proxy explícito en el cliente. Si la configuración automática del proxy está habilitada en el cliente, esto se puede hacer con un servidor WPAD, se puede configurar con una política de grupo o se debe configurar manualmente. Con un proxy puedes solicitar autenticación. Pero está limitado a la autenticación básica (nombre de usuario y contraseña) o a la autenticación transparente utilizando NTLM. No hay forma de que primero pueda presentar alguna información al cliente que él deba aceptar. La autenticación de proxy solo funciona si el cliente sabe que está hablando con un proxy. Simplemente interceptar el tráfico HTTP / HTTPS normal y enviar una solicitud de autenticación de proxy no funcionará. Esto también significa que las aplicaciones que no conocen el proxy (es decir, que no usan la configuración del sistema) no funcionarán.
Y, finalmente, podría abandonar cualquier intento de redirigir al usuario y simplemente publicar información que describa que los clientes deben autorizarse primero utilizando una URL interna. Hasta que esto se haga, cualquier acceso simplemente falla y una vez que el cliente se autoriza a sí mismo, se permite el MAC del cliente específico por un tiempo.
Si entiendo su pregunta, usted tiene un servidor proxy que bloquea el acceso a Internet hasta que el usuario final se haya autenticado. Por "bloques" quiero decir: si su proxy recibe una solicitud de enlace , falsificará el host solicitado (google.com) y devolverá una redirección 302 encabezado a una página de inicio de sesión que está alojada en el propio proxy. Este es un esquema muy común que se puede encontrar en wifi público en McDondald's, Starbucks, etc. y también es bastante común en la configuración corporativa.
El problema con esto es, por supuesto, la falsificación. La suplantación de google.com causará un error de certificado, aunque (hasta hace poco) el usuario podría hacer clic en este. La introducción de HSTS hace que sea imposible evitar el error de certificación y pasar a la página de inicio de sesión del proxy. un usuario final puede hacer para anularlo.
Como usuario final, he estado encontrando esto como un problema cada vez más últimamente. La forma en que lo he tratado como usuario final es navegar a un sitio que no tiene HSTS (por ejemplo, CNN.com) o navegar por IP (por ejemplo, http://192.168.0.1 ). Estos también serán interceptados por el proxy, pero puedo solucionar cualquier error de certificación.
Creo que la forma "correcta" de que un servidor proxy exija autenticación no es con un redireccionamiento 302 sino con un Código de estado HTTP 407 que significa" se requiere autenticación proxy ". El proxy debe responder con este encabezado en lugar de la redirección 302. El navegador debe saber cómo interpretar HTTP 407 y presentar un diálogo apropiado para recopilar el nombre de usuario y la contraseña.
Segunda opción ... Si esta es una red corporativa y tiene la capacidad de impulsar la política de grupo, puede usarla para configure la página de inicio del navegador en la página de inicio de sesión del proxy, eliminando así cualquier necesidad de redirecciones.
Lea otras preguntas en las etiquetas tls certificates url-redirection captive-portal