¿Cómo puedo diagnosticar errores SSL del lado del cliente?

5

A menudo, en mi red doméstica recibo errores aleatorios de certificados SSL cuando visito ciertos sitios conocidos. Hoy fue un error de SSL de Google, donde Google aparentemente intentó identificarse como * .icloud.com. En el pasado hemos visto errores de Facebook, Barnes and Noble y otros. También parece estar en toda la red; mi escritorio, teléfono y teléfono de la esposa también tienen problemas con SSL cuando estamos conectados a la red.

No soy un experto en seguridad, así que tengo algunas conjeturas sobre por qué esto podría estar sucediendo:

  1. El servidor DNS que estamos usando no es confiable. La configuración DHCP de mi enrutador utiliza el servicio DNS de Google, por lo que lo dudo.
  2. Alguien está intentando hacer un ataque de hombre en el medio. Me parece poco probable, especialmente porque los certificados incorrectos que veo son de Apple, Akamai, etc.
  3. Mi ISP tiene problemas de enrutamiento.
  4. Todos estos sitios con los que tengo problemas al azar están mal configurados, y debo esperar a que los administradores de su sistema solucionen el problema.

¿Cuáles son las causas más comunes de estos errores? ¿Dónde empiezas a diagnosticar estos errores?

    
pregunta Phil 30.03.2013 - 14:27
fuente

3 respuestas

9

En SSL, las cosas son así: el cliente busca el nombre del servidor en el DNS; luego se conecta a la dirección IP que creó el DNS; luego se produce el protocolo de enlace SSL, durante el cual el servidor envía su certificado. Tenga en cuenta que la URL real no se ha enviado a ninguna parte en ese punto, solo el nombre del servidor; para que podamos ignorar la URL para el diagnóstico.

Dado que el problema afecta a varias máquinas con distintos sistemas operativos y navegadores, probablemente podamos descartar errores del navegador y del sistema operativo.

Google, Barnes and Noble, Facebook ... son creaciones humanas que, como tales, son imperfectas y pueden fallar ocasionalmente; pero es bastante improbable que todos falle simultáneamente.

Si eres el objetivo de un ataque Man-in-the-Middle , entonces El atacante es singularmente incompetente. Eso también es bastante improbable.

Para resumir, el problema probablemente esté en algún lugar entre su enrutador y su ISP. Los síntomas que observa son coherentes con la hipótesis de que la conexión TCP desde su navegador, anteriormente dirigida a www.google.com , termina en el iCloud de Apple servidores Un primer escenario potencial es el siguiente:

  

Su enrutador es una retransmisión de DNS. A través de DHCP, realmente configura sus máquinas domésticas para utilizar el enrutador como servidor DNS, y ese enrutador se alimentará del servidor DNS externo que configuró (el servidor DNS de Google). En ese caso, si el enrutador mezcla sus tablas internas (debido a un error de software o mala memoria RAM), es posible que proporcione direcciones IP incorrectas a sus máquinas.

En ese escenario, el problema no se limita a SSL. De hecho, cuando el navegador desea conectarse a cualquier servidor, solicita el nombre del servidor, pero no el puerto o el protocolo. Por lo tanto, si esa hipótesis es correcta, las conexiones HTTP simples y sin SSL también deberían fallar ocasionalmente. Por ejemplo, si su conexión a www.facebook.com se redirige a la dirección IP de www.google.com , obtendrá una respuesta de Google (en realidad una redirección a la página principal de Google), y nada parecido a Facebook.

Si solo sus conexiones SSL tienen problemas, entonces esto no es un problema de DNS. Esto apuntaría a un segundo escenario potencial:

  

Su ISP tiene algún problema con su enrutamiento dinámico. Intenta enrutar el tráfico de manera óptima, moviendo paquetes entre varios destinos. Esta decisión de enrutamiento puede ser específica de un puerto, lo que explica por qué el problema solo ocurre con SSL. Por alguna razón (posiblemente otra vez RAM incorrecta, en uno de los enrutadores ISP), los paquetes pueden ser mal dirigidos.

He conocido un viejo enrutador Cisco (con mala memoria RAM) que se comportó un poco así. Cuando un enrutador procesa un paquete IP, debe copiar y modificar parcialmente el encabezado (al menos para modificar el TTL), de modo que los errores en el enrutador puedan provocar la modificación de la dirección de destino.

Este escenario tiene una variante en la que su enrutador tiene mala memoria RAM (de nuevo ...) y se dispara por sí mismo cuando hace NAT .

Para diagnosticar más el problema:

  • Cuando ocurra el problema, desde la misma máquina, haga un nslookup www.google.com (si desea contactar a Google pero se redirige a otra parte), a continuación, openssl s_client -connect www.google.com:443 (usando OpenSSL herramienta de línea de comandos: si usa Linux o MacOS X, entonces ya lo tiene). Esto le indicará qué dirección IP devuelve el DNS y qué certificado devuelve el servidor que supuestamente responde en esa dirección.

  • Si el problema es intermitente (es decir, la conexión del navegador falla, pero intentarlo de nuevo funciona de inmediato), intente ejecutar una herramienta de captura de red como Wireshark o Monitor de red para observar exactamente qué sucedió cuando el problema ocurrió. Verá las direcciones IP tal como se ven desde su máquina.

  • Cambia el enrutador de tu casa. Por ejemplo, pida prestado un enrutador viejo a un amigo o compre uno nuevo (estos cuestan 40 $). Si el problema está en su ISP, entonces el personal de soporte de ISP probablemente afirmará primero que su enrutador tiene la culpa, por lo que este paso no se puede evitar de todos modos. Si al cambiar el enrutador se elimina el problema, sabrá que una vez más la memoria RAM defectuosa.

respondido por el Tom Leek 30.03.2013 - 20:40
fuente
1

Mucha gente está viendo los errores de certificados akamai y voice5 últimamente. Esto se debe a que la nube está manejando la retransmisión de sus certificados y los nombres no coincidirán a menos que su DNS se actualice muy rápidamente. Además, muchos ISP, como Optimum, almacenarán en caché los datos en los servidores locales, lo que también puede romper cosas. La mayoría de los servidores DNS de Windows y las estaciones de trabajo de Windows también almacenarán en caché lo contrario y forzarán una condición de falta de coincidencia. No es una sorpresa, y otra consecuencia del uso de la nube por seguridad. No eres tu. ¡Es lo triste que llaman una nube!

    
respondido por el Al Thiel 19.12.2013 - 20:10
fuente
0

Quería agregar alguna información adicional, porque tenía el mismo problema que describió Phil, excepto que en algunas ocasiones se me ofrecía lo que parecía una página web maliciosa (independientemente del navegador). La página web decía cosas como:

(Chrome): "Para continuar con su navegación web, descargue e instale este software. Microsoft System Tools 16.3846. ¡Estas herramientas de red están diseñadas solo para nuestros clientes!"

Qué tranquilizador. Estoy en un Macbook Pro por cierto. Los tipos de sitios con los que tuve problemas fueron: gmail, facebook, wikipedia, youtube.

De todos modos, era un navegador cruzado y parecía estar relacionado con la red (no tuve el problema en otras redes con la misma computadora). Nada parecía funcionar para solucionarlo, incluido el borrado de cachés, la reinstalación de navegadores, la instalación de nuevos navegadores, la ejecución de análisis de virus, lo que sea. No hay mucha información específica en la red ... mucha de ella se relaciona con la verificación de la fecha / hora de su computadora, lo cual definitivamente no es el problema en este caso.

Acabo de restablecer la configuración de mi módem, y por el momento, eso ha resuelto los errores de SSL. Sin embargo, mi dirección IP sigue siendo la misma, así que supongo que no es un problema de suplantación de IP.

De todos modos, espero que esto ayude a otros.

Saludos,

Erik

    
respondido por el Erik 22.06.2014 - 12:48
fuente

Lea otras preguntas en las etiquetas