Introducción a DANE y TLSA
La infraestructura de clave pública (PKI) se basa en las autoridades de certificación (CA ) para garantizar la legitimidad de un certificado TLS . El problema radica en que cualquiera de las cientos de CA en las que confían los navegadores puede emitir un certificado para cualquier dominio, independientemente de si dicho dominio tiene alguna relación con esa CA. Si tan solo una de esas CA se ve comprometida, mal configurada o coaccionada, un atacante puede obtener un certificado fraudulento para su dominio que los navegadores aceptarán sin cuestionar. Esta es la debilidad estructural que subyace al modelo de confianza de las CA, y no es una hipótesis. Ya se han producido incidentes de emisión errónea de certificados, y volverán a ocurrir.
DANE, acrónimo de Autenticación de Entidades Nombradas Basada en DNS, es un protocolo de seguridad que ayuda a solucionar esta vulnerabilidad. Definido en el RFC 6698, DANE permite a los propietarios de dominios publicar la información de sus certificados TLS directamente en el DNS, protegida por firmas DNSSEC. En resumen, en lugar de confiar en cualquiera de los cientos de Autoridades de Certificación para confirmar la legitimidad de un certificado, DANE permite al propietario de un dominio especificar el certificado o la clave exactos que debería recibir de su servidor. Cualquier otro certificado debe ser rechazado.
DANE comparte esta información mediante un registro DNS TLSA. Este registro reside en la zona DNS de un dominio e indica a los clientes que se conectan qué certificado TLS o clave pública deben aceptar. En conjunto, DANE y TLSA brindan a los propietarios de dominios un control mucho mayor sobre la validación de certificados.
Por qué la infraestructura de clave pública tradicional por sí sola no es suficiente
Para comprender la importancia de DANE, primero hay que ver las deficiencias de PKI. El modelo de CA se basa en una idea: los navegadores y los sistemas operativos incluyen una lista de CA raíz de confianza, y cualquier certificado firmado por una de esas CA se considera válido. Esto suena bien, hasta que te das cuenta de que existen más de 100 CA raíz de confianza en todo el mundo.
El problema es el siguiente: cualquiera de estas autoridades de certificación (CA) puede emitir un certificado para cualquier dominio. Si una CA se ve comprometida o presionada por un gobierno o un actor malintencionado, puede crear un certificado fraudulento para su dominio. La mayoría de los clientes confiarán en él sin cuestionarlo. Esto no es solo una teoría. En 2011, una CA llamada DigiNotar sufrió una brecha de seguridad y se emitieron certificados falsos para dominios importantes, incluido Google. El incidente dejó claro lo frágil que puede ser el modelo de las CA.
Herramientas como los registros de Transparencia de Certificados (CT) y los registros CAA han mejorado la situación. Sin embargo, suelen avisar después de que se haya emitido un certificado defectuoso. DANE es diferente. Es una medida preventiva. Bloquea qué certificados son aceptables a nivel DNS, antes de que se pueda manipular cualquier protocolo de enlace TLS.
Cómo DNSSEC permite DANE
DANE no funciona por sí solo. Depende completamente de DNSSEC, las Extensiones de Seguridad del Sistema de Nombres de Dominio. Sin DNSSEC, almacenar información de certificados en el DNS no sería de mucha ayuda, ya que los registros DNS pueden ser manipulados con relativa facilidad.
DNSSEC añade firmas criptográficas a lo largo de la jerarquía DNS. Cada nivel del árbol DNS, desde la zona raíz hasta el dominio de nivel superior (TLD) y la zona de dominio específica, firma los registros que se encuentran debajo. Cuando un resolvedor obtiene un registro TLSA, DNSSEC le permite verificar que el registro sea auténtico y no haya sufrido modificaciones.
Imagina el DNS sin DNSSEC como una carta sin sello de seguridad. Cualquiera que la manipule podría alterar su contenido. DNSSEC añade ese sello en cada paso. DANE utiliza entonces ese canal seguro y confiable para transmitir instrucciones vinculantes sobre qué certificados TLS son aceptables.
Para que DANE te proteja eficazmente, DNSSEC debe estar completamente implementado y validado de extremo a extremo, desde la zona DNS autoritativa hasta el cliente que realiza la resolución. DANE, basado en DNS sin firmar, no ofrece seguridad real.
Comprensión de los registros TLSA y sus campos
Un registro TLSA se publica en un nombre DNS específico que incluye el protocolo, el puerto y el dominio del servicio. Por ejemplo, el registro TLSA para HTTPS en el puerto 443 en example.com aparecería en:
_443._tcp.example.com. IN TLSA <Usage> <Selector> <MatchingType> <CertificateData>Cada uno de los cuatro campos tiene una función específica:
- Uso del certificado (de 0 a 3): Este campo define a qué se vincula el registro. El uso 3, conocido como DANE-EE, es la opción más estricta. Vincula directamente al certificado o clave del propio servidor, omitiendo por completo la validación tradicional de la CA.
- Selector (0 o 1): Esto le indica al cliente si debe comparar la clave pública con el certificado completo (0) o solo con la clave pública del sujeto (SubjectPublicKeyInfo), es decir, con la clave pública (1). Generalmente se prefiere fijar la clave pública, ya que permanece válida incluso cuando se renueva el certificado, siempre que el par de claves sea el mismo.
- Tipo de coincidencia (0, 1 o 2): Esto define cómo se representan los datos del certificado. Un valor de 1 significa SHA-256 y un valor de 2 significa SHA-512. Se recomienda encarecidamente usar una función hash para mantener un tamaño de registro DNS manejable.
- Datos de la asociación de certificados: Este es el valor real, ya sea un hash o el certificado o clave en bruto, que el cliente compara con el certificado que presenta el servidor durante el protocolo de enlace TLS.
Un servidor que utiliza un certificado firmado por una CA podría usar el Uso 1 (DANE-TA) para vincularse a la clave pública de la CA emisora. Un servidor que ejecuta un certificado autofirmado normalmente usaría el Uso 3 (DANE-EE) para vincularse directamente a su propio certificado hoja.
Cómo DANE protege contra ataques MITM y de degradación
DANE resulta especialmente útil cuando se observa cómo bloquea dos de los tipos de ataques más peligrosos en la seguridad de redes: los ataques de intermediario (Man-in-the-Middle, MITM) y los ataques de degradación de TLS.
En un ataque de intermediario (MITM), un atacante se interpone entre un cliente y un servidor. Intercepta la conexión y presenta su propio certificado al cliente, mientras redirige el tráfico al servidor legítimo. Si el atacante logra obtener un certificado fraudulento, pero de confianza para la autoridad de certificación (CA), para el dominio objetivo, el cliente no tiene forma de detectar la intrusión. DANE soluciona este problema. Aunque el certificado falso parezca válido para el navegador, no coincidirá con el registro TLSA en el DNS, y un cliente compatible con DANE rechazará completar la conexión.
Los ataques de degradación funcionan de manera diferente. El atacante interfiere con el protocolo de enlace TLS para forzar a ambas partes a usar una versión de protocolo o conjunto de cifrado más antiguo y débil, más fácil de descifrar. Algunos ataques de degradación van más allá y eliminan por completo el cifrado mediante la eliminación de SSL. DANE ayuda a contrarrestar esto cuando se combina con herramientas de seguridad SMTP como STARTTLS. Cuando un servidor de correo publica un registro TLSA para su puerto SMTP, un agente de transferencia de correo (MTA) remitente que valida ese registro sabe que se requiere TLS y sabe qué certificado esperar. Cualquier intento de degradar o eliminar TLS se vuelve detectable.
Es importante reconocer las limitaciones de DANE. La compatibilidad con navegadores es inconsistente. Los principales navegadores no validan de forma nativa los registros TLSA para HTTPS, por lo que la navegación web cotidiana no se beneficia de DANE sin complementos adicionales o configuraciones personalizadas. DANE funciona mejor en entornos de servidor a servidor, especialmente en la entrega de correo electrónico, y en entornos donde se tiene control total sobre la pila tecnológica.
Cómo puede ayudar la consultoría de cifrado
DANE añade una capa significativa de control sobre la validación de certificados TLS, pero también introduce una complejidad operativa considerable. Es necesario implementar y validar completamente DNSSEC. Los registros TLSA deben actualizarse sincronizadamente con cada renovación de certificado. Además, la infraestructura de clave pública subyacente debe ser sólida antes de vincular cualquier elemento al DNS. Estas no son tareas puntuales, sino responsabilidades operativas continuas que se incrementan a medida que crece el entorno de certificados.
Los servicios PKI y CertSecure Manager de Encryption Consulting abordan ambos aspectos de este desafío: la arquitectura y la gestión continua.
Para organizaciones que están construyendo o reforzando su infraestructura de clave pública (PKI):
Nuestros servicios PKI le ayudan a diseñar e implementar una jerarquía de Autoridad de Certificación (CA) optimizada para entornos que requieren un control estricto de certificados. Ya sea que migre a DANE-EE para vincular directamente los certificados del servidor o utilice DANE-TA para establecer la confianza en una CA interna, la arquitectura PKI subyacente debe respaldar este compromiso. Nos aseguramos de que así sea, con soporte HSM compatible con FIPS 140-3, políticas de certificados documentadas y una implementación que resiste cualquier análisis.
Para afrontar el desafío operativo constante de mantener alineados los registros de TLSA:
Uno de los riesgos más prácticos en una implementación de DANE es que un registro TLSA se desincronice al renovar un certificado. Si el nuevo certificado no coincide con el registro TLSA publicado, las conexiones fallan. CertSecure Manager realiza un seguimiento de todos los certificados en su entorno, marca los certificados próximos a renovarse y proporciona a su equipo la visibilidad necesaria para actualizar los registros TLSA antes de que una discrepancia provoque una interrupción. No importa qué CA emitió el certificado ni dónde esté implementado: muestra toda la información en un solo lugar.
Para las organizaciones que utilizan DANE para la seguridad SMTP, donde la entrega de correo electrónico entre servidores depende de que los registros TLSA sean precisos y estén actualizados, este tipo de gestión proactiva de certificados no es opcional. Es la capa operativa que hace que DANE sea sostenible en lugar de frágil.
Conclusión
Los registros DANE y TLSA representan un avance significativo en la forma en que las organizaciones gestionan la autenticación de certificados TLS. Al integrar las expectativas de los certificados en los registros DNS firmados con DNSSEC, se logra la capacidad de aplicar una estricta fijación de certificados sin depender completamente del sistema global de CA. Para los equipos de seguridad que siempre se han sentido incómodos al confiar en cientos de CA que no pueden controlar, DANE es una alternativa práctica y técnicamente sólida.
Dicho esto, DANE por sí solo no es una solución definitiva. Su correcta implementación implica contar con un DNSSEC sólido, gestionar los registros con cuidado, especialmente durante la renovación de certificados, y comprender dónde existe soporte al cliente y dónde no. Para las organizaciones que manejan comunicaciones confidenciales, en particular correo electrónico o tráfico entre servidores, DANE merece ser considerada seriamente como parte de un enfoque de seguridad por capas.
