Esta pregunta es sobre DNSCurve . Pensé en DNSCurve como "HTTPS para DNS" (como en este Answer ) pero tuvo algunos pensamientos resentidos sobre la relación de confianza entre los resolutores y los servidores de nombres que sirven las claves públicas.
Aquí hay un ejemplo para explicar de qué estoy hablando:
Supongamos que tenemos una configuración predeterminada de MitM con Bob como víctima y Eva como atacante.
- Eve ha encontrado una manera de controlar el tráfico de la red Bobs (por ejemplo, con envenenamiento arp).
- Ahora Bob intenta buscar en www.nytimes.com con una resolución local, solo de resolución (caché vacía). Su resolutor funciona recursivamente. (raíz) - > .com. - > nytimes.com. - > www.nytimes.com
- Eve analiza las solicitudes, las reenvía al destino real y finalmente entrega las respuestas a bob.
- Cuando el servidor de resolución de Bob le pide al servidor de nombres .com .com de nytimes.com la respuesta sería un registro NS de DNSCurve como uz5xgm1kx1zj8xsh51zp315k0rw7dcsgyxqh2sl7g8tjg25ltcvhyw.nytimes.com. Eve ahora toma su propio par de claves y genera un DNSCrypt-Record falsificado para poder descifrar las solicitudes.
- El resolutor de Bob asumirá que nytimes.com tiene la clave pública de Eve, crea una solicitud de curva de DNS y la envía al NS.
- Eve intercepta este mensaje, descifra su carga útil (= la solicitud dns), solicita el registro real al NS real (con o sin DNSCurve), falsifica la respuesta (con DNSCurve) y lo envía a Bob.
- Bob recibe la solicitud falsificada de Eve, pero debido a que Eve también forjó el registro inicial de NS, el resolutor de Bob piensa que esta es la clave pública válida para validar la respuesta, concluyendo que esta es una respuesta válida.
Si entiendo DNSCurve correctamente, debería proteger contra este tipo de situación. DNSSEC proporciona un Cain-of-Trust para prevenir este tipo de ataques, TSIG usa claves compartidas que deben intercambiarse fuera de banda, ¿cómo está manejando DNSCurve este problema? La Documentación oficial incluso declaró que "Si un nombre contiene varias claves públicas DNSCurve, use la primera" ( enlace ) que suena como un problema aún mayor, ya que podría permitir ataques aún más simples (falsificación de DNS clásica con sniffing y falsificación de UDP).
Estoy bastante seguro de que me perdí algo aquí, pero después de horas de investigación no pude encontrar ninguna respuesta a esa pregunta. El núcleo de esta pregunta es "¿dónde está el proceso de establecimiento de relaciones de confianza en DNSCurve?"