Algunos dicen que la tecnología DANE para navegadores ha fallado

Estamos hablando de qué es la tecnología DANE para la autenticación de nombres de dominio DNS y por qué no se usa ampliamente en los navegadores.


/ Unsplash / Paulius Dragunas

¿Qué es DANE?


Las autoridades de certificación (CA) son organizaciones que certifican certificados SSL criptográficos. Pusieron su firma electrónica en ellos, confirmando la autenticidad. Sin embargo, a veces surgen situaciones cuando se emiten certificados con infracciones. Por ejemplo, el año pasado Google inició un procedimiento de "terminación de confianza" para los certificados de Symantec debido a su compromiso (cubrimos esta historia en detalle en nuestro blog, una o dos veces ).

Para evitar tales situaciones, hace unos años, el IETF comenzó a desarrollar la tecnología DANE (pero no se usó ampliamente en los navegadores; por qué sucedió, hablaremos más).

DANE (Autenticación de entidades con nombre basada en DNS) es un conjunto de especificaciones que le permite utilizar DNSSEC (Extensiones de seguridad del sistema de nombres) para controlar la validez de los certificados SSL. DNSSEC es una extensión para el sistema de nombres de dominio que minimiza los ataques asociados con la suplantación de identidad. Usando estas dos tecnologías, el webmaster o el cliente pueden contactar a uno de los operadores de la zona DNS y confirmar la validez del certificado utilizado.

De hecho, DANE actúa como un certificado autofirmado (DNSSEC es el garante de su fiabilidad) y complementa las funciones de CA.

Como funciona


La especificación DANE se describe en RFC6698 . Según el documento, se agregó un nuevo tipo a los registros de recursos DNS : TLSA. Contiene información sobre el certificado transmitido, el tamaño y el tipo de los datos transmitidos, así como los datos en sí. El webmaster crea una huella digital del certificado, lo firma con DNSSEC y lo coloca en TLSA.

El cliente se conecta al sitio en Internet y compara su certificado con una "copia" recibida del operador DNS. Si coinciden, el recurso se considera confiable.

La página wiki de DANE proporciona el siguiente ejemplo de consulta DNS para el servidor example.org a través del puerto TCP 443:

IN TLSA _443._tcp.example.org 

La respuesta a esto se ve así:

  _443._tcp.example.com. IN TLSA ( 3 0 0 30820307308201efa003020102020... ) 

DANE tiene varias extensiones que funcionan con otros registros DNS además de TLSA. El primero es el registro DNS SSHFP para la verificación de claves para las conexiones SSH. Se describe en RFC4255 , RFC6594 y RFC7479 . La segunda es la entrada OPENPGPKEY para el intercambio de claves mediante PGP ( RFC7929 ). Finalmente, el tercero es el registro SMIMEA (el estándar no está redactado en el RFC, solo existe su borrador ) para el intercambio de claves criptográficas a través de S / MIME.

¿Cuál es el problema con DANE?


A mediados de mayo, se realizó la conferencia DNS-OARC (esta es una organización sin fines de lucro que se ocupa de la seguridad, la estabilidad y el desarrollo del sistema de nombres de dominio). En uno de los paneles, los expertos concluyeron que la tecnología DANE en los navegadores falló (al menos en la implementación actual). Al asistir a la conferencia, Geoff Huston, miembro senior de APNIC , uno de los cinco registradores regionales de Internet, habló de DANE como "tecnología muerta".

Los navegadores populares no admiten la autenticación de certificados con DANE. Existen complementos especiales en el mercado que revelan la funcionalidad de los registros TLSA, pero su soporte se está eliminando gradualmente .

Los problemas con la propagación de DANE en los navegadores están asociados con la duración del proceso de validación de DNSSEC. El sistema se ve obligado a realizar cálculos criptográficos para confirmar la autenticidad del certificado SSL y pasar por toda la cadena de servidores DNS (desde la zona raíz hasta el dominio del host) cuando se conecta al recurso por primera vez.


/ Unsplash / Kaley Dykstra

Esta falla fue probada en Mozilla usando la Extensión de Cadena DNSSEC para TLS. Se suponía que reduciría la cantidad de registros DNS que el cliente tuvo que revisar durante la autenticación. Sin embargo, surgieron desacuerdos dentro del equipo de desarrollo que no pudieron resolverse. Como resultado, el proyecto fue abandonado, aunque fue aprobado por el IETF en marzo de 2018.

Otra razón de la baja popularidad de DANE es la baja prevalencia de DNSSEC en el mundo: solo el 19% de los recursos trabajan con él . Los expertos consideraron que esto no fue suficiente para promover activamente DANE.

Lo más probable es que la industria se desarrolle en una dirección diferente. En lugar de utilizar DNS para verificar los certificados SSL / TLS, los agentes del mercado, por el contrario, promoverán los protocolos DNS sobre TLS (DoT) y DNS sobre HTTPS (DoH). Mencionamos el último en uno de nuestros materiales anteriores sobre Habré. Cifran y verifican las solicitudes de los usuarios al servidor DNS, evitando que los atacantes falsifiquen datos. A principios de año, DoT ya estaba implementado en Google para su DNS público. En cuanto a DANE, aún queda por ver si la tecnología podrá "volver a la silla de montar" y aún convertirse en masa.

¿Qué más tenemos para lecturas adicionales?

Cómo automatizar la gestión de la infraestructura de TI: discuta tres tendencias
JMAP: un protocolo abierto reemplaza a IMAP al intercambiar correos electrónicos

Cómo ahorrar dinero usando la interfaz de programación de aplicaciones
DevOps en un servicio en la nube usando 1cloud.ru como ejemplo
1cloud Cloud Architecture Evolution

¿Cómo funciona el soporte técnico de 1cloud?
Mitos de la nube

Source: https://habr.com/ru/post/454322/


All Articles