¿Puedo mejorar la seguridad del sitio web almacenando claves SSL en DNS? ¿Se requiere DNSSec? ¿Hay modelos de amenaza disponibles?

¿Se requiere DNSSec para la distribución de clave pública / hash?

Sí. Uno tiene que tener un punto de partida confiable, y en este caso esa es la firma del dominio raíz. A partir de ahí, cada subdominio correspondiente se firma, por lo que hay una cadena de continuidad para demostrar que su solicitud no fue secuestrada en ningún paso de la investigación.

¿Existen modelos de amenazas que comparen el uso de DNS regular como un repositorio en lugar de DNSSec?

La falsificación de DNS ya es un método de ataque común y de baja barrera. DNSSEC se implementó principalmente para evitar eso. La verificación del certificado del servidor en el mismo canal que una consulta de DNS no autenticada no proporciona una mejora real de la seguridad.

¿Qué se debe almacenar, el hash o la clave pública completa?

En teoría, uno podría almacenar cualquiera de ellos al mismo nivel de seguridad efectivo. Sin embargo, DNSSEC está diseñado para almacenar la clave completa con el fin de firmar zonas, por lo que supongo que es posible que se adhiera al almacenamiento de claves y firmas completas para cada aplicación.

¿Qué tan difícil sería para los proveedores soportar esta validación adicional de un certificado SSL / TLS?

Creo que la complejidad del código sería menor que la de verificar un certificado SSL (que el análisis de X.509 es bastante molesto). Sospecho que la mayoría de los proveedores de navegadores podrían implementar esto con relativamente poco esfuerzo. Regularmente se escriben sistemas de complementos más complejos (como Convergence.io).

Consulte Certificados DNSSEC ahora en Chrome Stable

  

Esto permite que los sitios usen DNSSEC, en lugar de los certificados tradicionales, y está dirigido a sitios que actualmente no utilizan HTTPS, o certificados autofirmados.

Debe tenerse en cuenta que estos Certificados DNSSEC no utilizan en absoluto el protocolo cliente-servidor DNS, por lo que su computadora no realizará ninguna solicitud de DNS adicional:

  

Estos certificados son certificados X.509 autofirmados con una cadena DNSSEC incrustada en una extensión. La alternativa sería que el cliente realice una búsqueda DNSSEC.

Recuerda que solo es una función experimental para jugar:

  

El resultado más probable es que nadie los usa y saco el código dentro de un año.

Autenticación basada en DNS de entidades nombradas (DANE) es una RFC de seguimiento de estándares que permite al propietario de un sitio web colocar la clave pública de un host determinado en DNS. Un cliente puede usar DNS para verificar la integridad de la sesión SSL actual.

La Sección 1.2 de la RFC describe cómo es posible usar DANE para confiar en un certificado que no está en el almacén raíz de confianza. (lea: certificados generados localmente / gratis)

Requisitos notables

• Se requiere DNSSec
• Se debe utilizar un transporte seguro, como TSIG, SIG o IPSec
• El certificado completo o "SubjectPublicKeyInfo" se almacena en DNS
• Uno de los dos elementos de la viñeta anterior se almacenará o incluirá en el DNS
• Se admite la rotación / renovación de certificados agregando varios registros para el mismo host

  

Según este enlace, la piratería de DNS no es una preocupación para la mayoría de los usuarios de Internet. Las excepciones notables incluyen a los usuarios de WiFi y ciertos enrutadores SoHo son preocupantes. Si DNSSec solo es necesario para estos casos límite, ¿por qué retrasar la implementación de una tecnología límite?

La piratería de DNS ciertamente es una preocupación para las mismas personas para quienes los recientes ataques de SSL son una preocupación: las personas bajo gobiernos opresivos. Al controlar los ISP, pueden (y tal vez?) Bloquear / interceptar el tráfico a gran escala a través de DNS.

  

¿Se requiere DNSSec para la distribución de clave pública / hash?

Sí. Si su atacante es capaz de MITMing sus conexiones HTTP, lo que le obliga a usar SSL, podría ser capaz de MITM su DNS también.

  

¿Existen modelos de amenazas que comparen el uso de DNS regular como repositorio en lugar de DNSSec?

No lo sé, pero intente esto: elegir SSL sobre HTTP simple se hace para mitigar algunas de las mismas amenazas que al elegir DNSSEC sobre DNS. Ambos asumen un atacante que puede interceptar su tráfico.

Sin DNSSec, no puede decir que un adversario no ha modificado el registro de certificado que está buscando durante el vuelo. Un hombre en el medio podría fácilmente hacer esto.

En cuanto a lo difícil que sería, eso varía mucho según el proveedor, pero estaría involucrado. Deberían actualizarse muchas partes de los navegadores, las API del sistema, las bibliotecas de resolución y más. (Esto sería además de admitir DNSSEC en general).