¿Cómo debe responder el software cuando los portales cautivos o los certificados SSL no confiables impiden la conectividad?

Question

¿Cómo debe responder el software cuando los portales cautivos o los certificados SSL no confiables impiden la conectividad?

#1 de Matthew1471 (4 votos)
#2 de Alexey Vesnin (-1 votos)

5

Necesito solucionar un problema por el cual la llamada HTTPS inicial (o quizás la única) a un sitio web está bloqueada por un portal cautivo, no administrado por mí. La resolución ha sido pedirle al usuario que navegue a un sitio "http" único para indicar a la pila de software que inicie sesión a través del portal.

Desde la perspectiva de la aplicación, veo que el sitio esperado es:

SSL no está disponible (ninguno de los códigos de respuesta ICMP)
SSL tiene un certificado no confiable del portal
SSL tiene un certificado no confiable y contenido inesperado (inicio de sesión en el portal)

Cada uno de esos comportamientos resulta en un resultado diferente por varias pilas de software, sistemas operativos y software de elaboración doméstica.

¿Cuál es la forma más compatible de lidiar con los portales cautivos cuando:

¿Accediendo a un sitio web que ofrece servicios REST protegidos, aplicaciones SPA o similares?
Solicitando desde una aplicación en iOS, Android que aprovecha el marco HTTP incorporado para esa plataforma
Solicitar desde una aplicación que no aproveche el marco HTTP de la plataforma, sino que utiliza OpenSSL, BouncyCastle o Monotouch / MonoDroid
Solicitud desde una PC de escritorio (OSX o Windows)

w.r.t. # 4, sé que OSX intentará ponerse en contacto con enlace para determinar si existe una redirección 301/302 . .. o si el portal simplemente reemplaza el contenido directamente a través de un MITM / Content Injection.

network man-in-the-middle hsts mobile captive-portal

pregunta random65537 15.10.2015 - 19:02

fuente

2 respuestas

Lea otras preguntas en las etiquetas network man-in-the-middle hsts mobile captive-portal

¿Está mi enrutador / módem comprometido? GPG (PGP) problema de velocidad de descifrado

score 4 · Answer 1

No solo OSX sino que la mayoría de las plataformas ahora solicitarán una URL conocida y verán si el contenido se reemplaza o manipula para detectar puntos de acceso.

Windows 7+:

NCSI realiza una búsqueda de DNS en www.msftncsi.com, luego solicita enlace . Este archivo es un archivo de texto sin formato y solo contiene el texto Microsoft NCSI.

NCSI envía una solicitud de búsqueda de DNS para dns.msftncsi.com. Esta dirección de DNS debe resolver a 131.107.255.255. Si la dirección no coincide, se asume que la conexión a Internet no funciona correctamente.

Fuente: enlace

Android 4.2.2+:

enlace

Fuente: # 1 & # 2

La mayoría de estas URL se pueden cambiar si la privacidad es una preocupación.

La solución para su aplicación sería realizar una solicitud GET de HTTP y ver si se manipula.

En la mayoría de los hotspots que utilizo, veo una sesión de SSL / TLS fallida debido a que el sitio está firmado por el proveedor del hotspot en lugar de la que estaba intentando visitar (no tienen los certificados del sitio). Estoy intentando visitar), lo que marcará su comprobación de nombre de host TLS / SSL ... o simplemente bloquearán la conexión hasta que vean un GET HTTP en un sitio al que puedan MITM ... que se parecería a un tiempo de espera.

Una ventaja de tener una URL de estilo enlace en lugar de reutilizar Microsoft o Google es que puede intentar proporcionar información más útil sobre la salud de su aplicación si su URL de estado informa que el servicio funciona correctamente, pero la red del usuario no les permite conectarse a su punto final TLS / SSL si el La página de enlace está inactiva, entonces quizás su aplicación también esté inactiva.

score -1 · Answer 2

Es cierto: use Tor y / o I2P, son las herramientas exactas que necesita: capas de transporte resistentes a la manipulación indebida.

ACTUALIZACIÓN: el problema de las "URL predefinidas" es que están ... predefinidas . Fácil de hacer una trampa en una ruta de un paquete de red desde la aplicación al servidor. La raíz del problema es que los protocolos de enrutamiento tradicionales son muy "directos", demasiado fáciles de manipular. El significado mismo del término "Darknet" es que no se puede intentar en el sentido de manipulación indebida.