Estaba leyendo este artículo enlace y esta línea me llamó la atención, "Con TLS Configurado correctamente, DNSSEC no agrega nada ". Mi reacción fue de no estar de acuerdo, pero cuanto más lo pensaba, me di cuenta de que no podía pensar en un ejemplo contrario. De acuerdo, solo tengo una comprensión superficial de DNSSEC, pero parece correcto. ¿Me estoy perdiendo algo?
TL; TR: en algunos casos de uso como HTTPS (web) DNSSec no es realmente necesario. En otros casos de uso, como SMTP (correo), la falsificación de DNS no se notará por TLS, es decir, es posible que el hombre en el medio sea posible si se puede falsificar DNS, incluso si se utiliza el TLS en sí.
Detalles:
Cuando se usa dentro de HTTPS (web) y el sistema de CA establecido actualmente, no necesita DNSSec, porque el navegador verifica el nombre en la URL con el nombre en el certificado y valida la cadena de confianza utilizando un almacenamiento local (pre- de confianza) root-CA. Pero tenga en cuenta que la correcta emisión del certificado en sí podría verse afectada por la falsificación de DNS (ver más abajo).
Con SMTP (transporte de correo) la situación es diferente. Para obtener el próximo salto dentro de la entrega de correo, un agente de transferencia de correo (MTA) debe saber qué servidor es responsable de qué dominio de destinatario. Esto se hace buscando el registro MX en DNS. Si este registro se puede falsificar (lo que se puede hacer sin DNSSec), el MTA entregará el correo al servidor de correo incorrecto. Incluso si la entrega se realiza con TLS, el MTA de envío no notará si el MX informa que el servidor de los atacantes es el servidor de destino, porque el nombre de host del servidor de los atacantes y el nombre dentro del certificado seguirán coincidiendo. Existe un mecanismo similar a MX para correo para SIP (VoIP) en forma de registros SRV y, por lo tanto, tiene los mismos problemas.
Aparte de eso, hay otros protocolos que dependen de DNS seguro. El DANE probable más prominente es el que intenta reemplazar el sistema CA utilizado pero actualmente roto por un sistema donde el certificado esperado se almacena en el mismo lugar que el nombre de host, que está dentro del DNS. De la misma manera, también puede almacenar claves de host SSH.
Además, en el sistema actual con una CA pública de confianza previa, la mayoría de las verificaciones de identidad realizadas cuando se emite un certificado validado de dominio se pueden falsificar si el atacante puede realizar la falsificación de DNS en el lugar correcto. Esto incluye el caso donde la validación del dominio se realiza con correo o donde la validación se realiza al acceder a un archivo específico en el sitio solo con HTTP (porque el sitio aún no tiene HTTPS). Mientras que en el primer caso el registro MX tendrá que ser falsificado, deberá falsificar los registros A / AAAA o CNAME en el segundo caso. Y una vez que el atacante haya obtenido el certificado del sitio en cuestión, el ataque MITM contra el sitio no se notará por más tiempo.