Impedir que un hombre en medio ataque con un certificado autofirmado usando IP no DNS

1

He buscado preguntas similares pero no puedo encontrar la respuesta que necesito.

¿Prevenir a un hombre falso en el ataque central?

Después de leer esta pregunta:

"Authorized" Man in the middle

Creo que puedo entender el problema (simplificado).

El cliente intenta establecer una conexión con un servidor de destino. Un proxy secuestra la conexión. El proxy inicia una conexión cifrada al servidor de destino. El proxy crea un certificado falsificado y lo envía al cliente e inicia una conexión cifrada. El proxy es entonces un hombre en el medio.

Sin una CA, el cliente no sabe si ha realizado una conexión genuina.

Mi pregunta es sobre cómo se las arregla el proxy para secuestrar la conexión. Si el DNS de los clientes estaba comprometido, podría ver un caso en el que la IP resuelta podría ser la IP de proxy.

Si el cliente realiza una conexión directamente utilizando una dirección IP, ¿el proxy podría interceptar el tráfico? Quizás un enrutador hostil podría hacer esto.

    
pregunta Uzer 10.02.2017 - 19:22
fuente

3 respuestas

2

Si el proxy está en la ruta de la conexión, puede interceptar el tráfico. Este es el caso de un proxy definido explícitamente en el navegador y también con proxies transparentes instalados en un dispositivo donde todo el tráfico saliente debe pasar (como un firewall). También es el caso cuando un atacante en la red local redirige el tráfico mediante la falsificación de ARP. La falsificación de DNS solo es relevante si hay nombres de host involucrados, pero todos los demás casos funcionan con la dirección IP como objetivo también.

    
respondido por el Steffen Ullrich 10.02.2017 - 19:35
fuente
1

Básicamente, todas las comunicaciones pueden interceptarse si se desconectan del cable, sin importar a dónde vaya. TCP / IP debe ser enrutable, por lo tanto, los paquetes pueden ser inspeccionados (solo lectura) pero también manipulados (reescritos) por cualquier nodo entre el remitente y el receptor.

Los enrutadores de capa 3 y los firewalls con inspección de paquetes pueden hacer esto fácilmente, incluso a gran escala debido a que la potencia de cálculo se ha reducido (10000 paquetes por segundo no son un problema). Adivina qué está haciendo la NSA, usan exactamente estas partes de hardware.

En mi empresa, por ejemplo, usamos el llamado acelerador de WAN que intenta almacenar en la memoria caché el tráfico de http (s) para no tener tanta carga en nuestros enlaces WAN dentro de la compañía. La idea es buena, pero aquí está el problema: muchos sitios ya usan https, por lo que el acelerador de WAN no pudo acelerar nada.

Para poder hacerlo, todas nuestras computadoras obtienen un certificado de confianza que la política del grupo impone en Windows o que se almacena en AD, no sé el fondo. Luego, el acelerador de WAN encuentra un paquete que tiene un intercambio de https (SSL) y lo reemplaza a medida que describe la clave pública (también entregará un certificado "falsificado" con el nombre DNS que el cliente solicitó o probablemente una dirección IP si no se da ningún nombre) para que el cliente se engañe y piense que se está comunicando de manera segura con el receptor final.

En cambio, se está comunicando con el acelerador WAN, y ahora puede almacenar en caché / acelerar lo que sea.

El punto es, mi empresa (o mis empleados de TI en mi empresa) pueden (teóricamente) leer todo mi tráfico bancario privado, etc. en este nodo acelerador. ¡Qué bueno es eso!

Aún verás que estos sitios quizás no tengan la "insignia verde" en la barra del navegador, pero no habrá ninguna advertencia sobre la interceptación.

    
respondido por el flohack 10.02.2017 - 19:34
fuente
1

Sí el proxy siempre intercepta el tráfico.

No no puede leer el tráfico si usa el certificado del objetivo deseado.

Sí puede leer el tráfico si falsifica la clave pública, pero el navegador mostrará una advertencia, por lo que

No no hay manera de interceptar y leer el tráfico sin generar una advertencia del navegador.

Mi explicación comienza con esta oración:

  

El proxy crea una clave pública y la envía al cliente e inicia una conexión cifrada.

No es así como funciona. El proxy tendría que enviar un certificado falso al navegador, que incluiría la clave pública pero también tendría que contener otra información, como el dominio que posee la clave. Además, todo el certificado está firmado digitalmente y, por lo tanto, a prueba de manipulaciones. La firma se puede verificar utilizando la clave pública de la organización que emitió el certificado. Esa clave pública a su vez es verificada por otro certificado SSL, hasta la cadena CA. El certificado de CA se instala como parte de su sistema operativo, por lo que su clave pública es conocida.

Entonces, a menos que el proxy tenga una de las claves privadas de la cadena de confianza, es imposible que el proxy proporcione al navegador un certificado falso o una clave pública alternativa sin que el navegador sepa que es falso, puede No genere la firma.

Si el proxy no puede proporcionar una falsificación, no hay manera de convencer al navegador de que la clave pública y el nombre de dominio van juntos, y su navegador mostrará una advertencia de suplantación de identidad (phishing), y la barra de direcciones se volverá roja.

Incluso si está accediendo a un host a través de una dirección IP, el certificado aún es necesario y el usuario final puede ver el nombre de dominio en el certificado. El navegador siempre pondrá la barra de direcciones en rojo. Además, el usuario final puede hacer clic en un botón en el navegador para ver el certificado y determinar manualmente si el nombre de dominio es correcto. Si el nombre de dominio es sospechoso, el usuario debe cerrar el navegador y dejar de usar ese punto final.

    
respondido por el John Wu 11.02.2017 - 02:39
fuente

Lea otras preguntas en las etiquetas