Suplantación de DNS + secuestro / redirección del puerto del cortafuegos para capturar solicitudes HTTPS sin obtener un "error no confiable de certificado" en el navegador del cliente [duplicar]

Question

Suplantación de DNS + secuestro / redirección del puerto del cortafuegos para capturar solicitudes HTTPS sin obtener un "error no confiable de certificado" en el navegador del cliente [duplicar]

#1 de David (2 votos)

2

Si pudiera configurar un servidor DNS que responda con la IP de mi servidor para un dominio determinado, junto con la redirección de https y todas las solicitudes de consultas de DNS a mi sitio https local y mi servidor DNS local respectivamente, ¿podría esto resultar en que el navegador del cliente obtenga una certificado de sitio sobre https que contiene las credenciales que coinciden con lo que el navegador obtiene de sus consultas de DNS, evitando así el error "certificado no confiable"?

Esto se basa en la lógica de que si solo redirigí el tráfico https y dejé el DNS en algún servidor externo, el DNS podría responder a las consultas del cliente con una IP que no coincide con la del certificado, generando así el error debido. al desajuste.

Si no es así, ¿cómo sabe el navegador que confía en el certificado que recibe? ¿Compara la IP proporcionada en el certificado con la información de DNS que tiene?

certificates dns dns-spoofing

pregunta Dudus 07.01.2018 - 02:06

fuente

1 respuesta

Lea otras preguntas en las etiquetas certificates dns dns-spoofing

pregunta sobre ipsec evita el ataque de inundación SYN OWASP ZAP enseñando a la araña a usar encabezado personalizado

score 2 · Accepted Answer

Los certificados no contienen direcciones IP, pero de hecho contienen el nombre de host del sitio al que se emiten. (es decir, www.google.com)

Cuando un navegador se conecta a un sitio HTTPS, verifica varias cosas :

Que el nombre de host en el certificado (específicamente, un nombre de host listado en el campo "Nombre alternativo del sujeto") coincide con el nombre de host solicitado.
El certificado fue emitido por un emisor de confianza (por ejemplo, una Autoridad de certificación de confianza)
Que el certificado no ha caducado y que ya ha pasado la fecha de emisión del certificado.

Para exitosamente (lo que significa que no hay advertencias para el navegador) el tráfico HTTPS de MITM necesitaría un certificado para el nombre de host correcto firmado por una autoridad de certificación en la que el dispositivo cliente confíe. Sin este mecanismo, HTTPS no sería efectivo en la protección contra atacantes activos. (Lo efectivo que es en realidad es una cuestión de debate entre los profesionales de la industria).

DNS no desempeña ningún papel en la verificación de certificados. (Existen algunos usos no convencionales como RFC 4398 , pero no conozco ningún navegador que los use.)