Las autoridades de certificación (CA) son organizaciones que están comprometidos certificado criptográfico Certificados SSL. Les ponen su firma electrónica, confirmando su autenticidad. Sin embargo, a veces surgen situaciones en las que los certificados se emiten con infracciones. Por ejemplo, el año pasado Google inició un "procedimiento de desconfianza" para los certificados de Symantec debido a su compromiso (cubrimos esta historia en detalle en nuestro blog). tiempo и два).
Para evitar este tipo de situaciones, hace varios años el IETF comenzó a desarrollar Tecnología DANE (pero no se usa mucho en los navegadores; hablaremos de por qué sucedió esto más adelante).
DANE (Autenticación de entidades nombradas 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 del sistema de nombres de dominio que minimiza los ataques de suplantación de direcciones. Utilizando estas dos tecnologías, un webmaster o cliente puede contactar a uno de los operadores de la zona DNS y confirmar la validez del certificado que se está utilizando.
Básicamente, el DANE actúa como un certificado autofirmado (el garante de su confiabilidad es DNSSEC) y complementa las funciones de una CA.
¿Cómo funciona esto
La especificación del DANE se describe en RFC6698. Según el documento, en Registros de recursos DNS Se agregó un nuevo tipo: TLSA. Contiene información sobre el certificado que se transfiere, el tamaño y el tipo de datos que se transfieren, así como los datos en sí. El webmaster crea una huella digital del certificado, la firma con DNSSEC y la coloca en TLSA.
El cliente se conecta a un sitio en Internet y compara su certificado con la "copia" recibida del operador DNS. Si coinciden, entonces el recurso se considera confiable.
La página wiki del DANE proporciona el siguiente ejemplo de una solicitud DNS a example.org en el puerto TCP 443:
IN TLSA _443._tcp.example.org
La respuesta se ve así:
_443._tcp.example.com. IN TLSA (
3 0 0 30820307308201efa003020102020... )
DANE tiene varias extensiones que funcionan con registros DNS distintos a TLSA. El primero es el registro DNS SSHFP para validar claves en conexiones SSH. Se describe en RFC4255, RFC6594 и RFC7479. La segunda es la entrada OPENPGPKEY para el intercambio de claves usando PGP (RFC7929). Finalmente, el tercero es el registro SMIMEA (el estándar no está formalizado en el RFC, existe solo un borrador) para el intercambio de claves criptográficas a través de S/MIME.
¿Cuál es el problema con el DANE?
A mediados de mayo se celebró la conferencia DNS-OARC (una organización sin fines de lucro que se ocupa de la seguridad, la estabilidad y el desarrollo del sistema de nombres de dominio). Expertos en uno de los paneles llegué a la conclusiónque la tecnología del DANE en los navegadores ha fallado (al menos en su implementación actual). Presente en la conferencia Geoff Huston, destacado investigador científico APNIC, uno de los cinco registradores regionales de Internet, respondió sobre el DANE como una “tecnología muerta”.
Los navegadores populares no admiten la autenticación de certificados mediante DANE. En el mercado hay complementos especiales, que revelan la funcionalidad de los registros TLSA, pero también su soporte. detenerse gradualmente.
Los problemas con la distribución del 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 recorrer toda la cadena de servidores DNS (desde la zona raíz hasta el dominio host) cuando se conecta por primera vez a un recurso.
Mozilla intentó eliminar este inconveniente utilizando el mecanismo Extensión de cadena DNSSEC para TLS. Se suponía que reduciría la cantidad de registros DNS que el cliente tenía que buscar durante la autenticación. Sin embargo, surgieron desacuerdos dentro del grupo 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 del DANE es la baja prevalencia de DNSSEC en el mundo. sólo el 19% de los recursos funcionan con él. Los expertos consideraron que esto no era suficiente para promover activamente al DANE.
Lo más probable es que la industria se desarrolle en otra dirección. En lugar de utilizar DNS para verificar certificados SSL/TLS, los actores del mercado promoverán los protocolos DNS sobre TLS (DoT) y DNS sobre HTTPS (DoH). Mencionamos esto ú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 han implementado a Google por su DNS público. En cuanto al DANE, aún está por verse en el futuro si la tecnología podrá “volver a tomar posesión” y aún generalizarse.