Hispanopedia Wiki
Articulo de referencia

Autenticación de entidades nombradas basada en DNS

La autenticación basada en DNS de entidades nombradas ( DANE ) es un protocolo de seguridad de Internet que permite vincular certificados digitales X.509 , comúnmente utilizados...

Hispanopedia WikiContenido en espanolLectura gratuita

La autenticación basada en DNS de entidades nombradas ( DANE ) es un protocolo de seguridad de Internet que permite vincular certificados digitales X.509 , comúnmente utilizados para la seguridad de la capa de transporte (TLS), a nombres de dominio mediante las extensiones de seguridad del sistema de nombres de dominio ( DNSSEC ). [ 1 ]

Se propone en el RFC 6698 como una forma de autenticar entidades cliente y servidor TLS sin una autoridad de certificación ( CA ). Se actualiza con directrices operativas y de implementación en el RFC 7671. El uso específico de DANE para aplicaciones se define en el RFC 7672 para SMTP y en el RFC 7673 para el uso de DANE con registros de servicio (SRV) .    

Razón fundamental

Actualmente, el cifrado TLS/SSL se basa en certificados emitidos por autoridades de certificación (CA). En los últimos años , varios proveedores de CA sufrieron graves brechas de seguridad , lo que permitió la emisión de certificados para dominios conocidos a personas que no los poseen. Confiar en un gran número de CA puede ser problemático, ya que cualquier CA comprometida podría emitir un certificado para cualquier nombre de dominio. DANE permite al administrador de un nombre de dominio certificar las claves utilizadas en los clientes o servidores TLS de ese dominio almacenándolas en el Sistema de Nombres de Dominio (DNS). DANE requiere que los registros DNS estén firmados con DNSSEC para que su modelo de seguridad funcione.

Además, DANE permite al propietario de un dominio especificar qué CA está autorizada a emitir certificados para un recurso en particular, lo que resuelve el problema de que cualquier CA pueda emitir certificados para cualquier dominio.

DANE resuelve problemas similares a los siguientes:

Transparencia del certificado
Garantizar que las CA fraudulentas no puedan emitir certificados sin el permiso del titular del dominio sin ser detectadas.
Autorización de la Autoridad de Certificación DNS
Limitar qué autoridades de certificación pueden emitir certificados para un dominio determinado.

Cifrado de correo electrónico

Hasta hace poco, no existía un estándar ampliamente implementado para la transferencia de correo electrónico cifrado . [ 2 ] El envío de un correo electrónico es independiente de la seguridad; no existe un esquema URI para designar SMTP seguro. [ 3 ] En consecuencia, la mayoría de los correos electrónicos que se entregan a través de TLS utilizan únicamente cifrado oportunista . [ 4 ] Dado que DNSSEC proporciona una denegación de existencia autenticada (permite que un resolvedor valide que un determinado nombre de dominio no existe), DANE permite una transición incremental a SMTP cifrado y verificado sin ningún otro mecanismo externo, como se describe en RFC 7672. Un registro DANE indica que el remitente debe utilizar TLS. [ 3 ] 

Además, existe RFC 8162 para aplicar DANE a S/MIME , [ 5 ] y RFC 7929 estandariza los enlaces para OpenPGP . [ 6 ]  

Apoyo

Aplicaciones

  • Google Chrome no admite DANE, ya que desea eliminar el uso de RSA de 1024 bits dentro del navegador [ 7 ] (DNSSEC utilizaba anteriormente una raíz firmada con RSA de 1024 bits [ 8 ] , y muchas zonas aún se firman con RSA de 1024 bits, aunque el valor predeterminado actual es ECDSA de 256 bits [ 9 ] ). Según Adam Langley, el código fue escrito [ 10 ] y, aunque no está en Chrome actualmente [ 11 ], sigue estando disponible como complemento [ 12 ] .
  • Mozilla Firefox no es compatible con DANE. Según las reacciones en los tickets sobre estos temas ("No tenemos planes de implementar esta función"), los desarrolladores de Mozilla consideran que DNSSEC y DANE están fuera del alcance de Firefox. [ 13 ] [ 14 ] La compatibilidad con complementos estuvo disponible hasta Firefox 56 (última actualización en 2016 [ 15 ] ), pero ya no existe. Ya no se puede implementar con las API de extensiones de Firefox más recientes y restrictivas. [ 16 ]
  • GNU Privacy Guard permite obtener claves a través de OpenPGP DANE (--auto-key-locate). Nueva opción --export-options export-dane. (versión 2.1.14) [ 17 ]
  • Cheogram Android permite la verificación a través de DANE y muestra el estado si se utilizó DANE o no [ 18 ].
  • FairEmail para Android permite verificar DANE para servidores SMTP y POP/IMAP [ 19 ]

Servidores

Servicios

Bibliotecas

TLSA RR

El registro de recursos TLSA (TLSA RR) de un servicio se encuentra en un nombre DNS que especifica las restricciones de certificado que deben aplicarse a los servicios en un puerto TCP o UDP determinado. Al menos uno de los registros TLSA RR debe proporcionar una validación (ruta) para el certificado ofrecido por el servicio en la dirección especificada.

No todos los protocolos manejan la coincidencia del nombre común de la misma manera. HTTP requiere que el nombre común en el certificado X.509 proporcionado por el servicio coincida, independientemente de que TLSA confirme su validez. SMTP no requiere que el nombre común coincida si el valor de uso del certificado es 3 (DANE-EE), pero en caso contrario sí lo requiere. Es importante verificar si existen instrucciones específicas para el protocolo que se está utilizando.

Campos de datos RR

El propio registro RR tiene 4 campos de datos que describen el nivel de validación que proporciona el propietario del dominio.

P.ej_25._tcp.somehost.example.com.TLSA3110123456789ABCDEF

Uso de certificados

El primer campo que aparece después del texto TLSA en el registro DNS RR especifica cómo verificar el certificado.

  • Un valor de 0 corresponde a lo que comúnmente se denomina restricción de CA (y PKIX-TA). El certificado proporcionado al establecer TLS debe ser emitido por la CA raíz indicada o una de sus CA intermedias, con una ruta de certificación válida hacia una CA raíz en la que la aplicación que realiza la verificación ya confíe. El registro puede simplemente apuntar a una CA intermedia; en ese caso, el certificado para este servicio debe provenir de esta CA, pero toda la cadena hasta una CA raíz de confianza debe seguir siendo válida. [ a ]
  • El valor 1 corresponde a lo que comúnmente se denomina restricción de certificado de servicio (y PKIX-EE). El certificado utilizado debe coincidir con el registro TLSA y, además, debe superar la validación de la ruta de certificación PKIX ante una CA raíz de confianza.
  • Un valor de 2 corresponde a lo que comúnmente se denomina aserción de ancla de confianza (y DANE-TA). El registro TLSA coincide con el certificado de la CA raíz, o con una de las CA intermedias, del certificado utilizado por el servicio. La ruta de certificación debe ser válida hasta el certificado coincidente, pero no es necesario que exista una CA raíz de confianza.
  • El valor 3 corresponde a lo que comúnmente se denomina certificado emitido por el dominio (y DANE-EE). El registro TLSA coincide con el certificado utilizado. No es necesario que el certificado esté firmado por terceros. Esto resulta útil para certificados autofirmados, pero también en casos donde el validador no dispone de una lista de certificados raíz de confianza.

Selector

Al conectarse al servicio y recibir un certificado, el campo selector especifica qué partes del mismo deben comprobarse.

  • Un valor de 0 significa seleccionar el certificado completo para la comparación.
  • Un valor de 1 significa seleccionar únicamente la clave pública para la verificación del certificado. Generalmente, basta con que coincida con la clave pública, ya que es probable que sea única.

Tipo coincidente

  • Un valor de tipo 0 significa que toda la información seleccionada está presente en los datos de asociación del certificado .
  • El tipo 1 significa realizar un hash SHA-256 de los datos seleccionados.
  • El tipo 2 significa realizar un hash SHA-512 de los datos seleccionados.

Datos de asociación de certificados

Los datos reales que se deben comparar según la configuración de los demás campos. Se trata de una larga cadena de texto con datos hexadecimales.

Ejemplos

El registro TLSA para www.ietf.org especifica que se debe verificar el hash SHA-256 de la clave pública del certificado proporcionado, ignorando cualquier CA.

_443._tcp.www.ietf.org. TLSA 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6

Su servicio de correo tiene exactamente el mismo certificado y TLSA.

ietf.org. MX 0 correo.ietf.org. _25._tcp.mail.ietf.org. TLSA 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6

Finalmente, el siguiente ejemplo hace lo mismo que los demás, pero realiza el cálculo del hash sobre todo el certificado.

_25._tcp.mail.alice.example. TLSA 3 0 1 AB9BEB9919729F3239AF08214C1EF6CCA52D2DBAE788BB5BE834C13911292ED9

Estándares

  • RFC 6394 Casos de uso y requisitos para la autenticación de entidades nombradas basada en DNS (DANE) 
  • RFC 6698 Autenticación basada en DNS de entidades nombradas (DANE) Protocolo de seguridad de la capa de transporte (TLS): TLSA 
  • RFC 7218: Adición de acrónimos para simplificar las conversaciones sobre la autenticación de entidades nombradas basada en DNS (DANE). 
  • RFC 7671 El protocolo de autenticación de entidades nombradas basado en DNS (DANE): actualizaciones y guía operativa 
  • RFC 7672 Seguridad SMTP mediante autenticación oportunista basada en DNS de entidades nombradas (DANE) Seguridad de la capa de transporte (TLS) 
  • RFC 7673 Uso de registros TLSA de autenticación de entidades nombradas basada en DNS (DANE) con registros SRV 
  • RFC 7929 Enlaces de autenticación de entidades nombradas (DANE) basados ​​en DNS para OpenPGP 
  • RFC 8162 Uso de DNS seguro para asociar certificados con nombres de dominio para S/MIME 
  • Borrador: Cifrado oportunista con semántica DANE e IPsec: IPSECA [ 29 ]

Véase también

Notas

  1. ↑ Un ejemplo poco común donde esto podría ser útil sería si no confías completamente en la CA raíz, pero muchas aplicaciones aún la usan, y sí confías en una CA intermedia específica, por lo que enumeras la intermedia y aún así obtienes una verificación de ruta de confianza completa.

Referencias

  1. ↑ Samad, Muhammad Alif Adha Bin (6 de octubre de 2011). "DANE: Llevando la autenticación TLS al siguiente nivel usando DNSSEC" . Revista IETF . Consultado el 5 de agosto de 2018 .
  2. ↑ "Soporte TLS de Postfix: verificación segura del certificado del servidor" . Postfix.org . Consultado el 30 de diciembre de 2015 .
  3. 1 2 Dukhovni; Hardaker (2013-07-28). DANE para SMTP (PDF) . Actas de la IETF 87. IETF.
  4. ↑ Filippo Valsorda (31 de marzo de 2015). "El triste estado del cifrado SMTP" . Consultado el 30 de diciembre de 2015 .
  5. ↑ Hoffman, P. (mayo de 2017). Uso de DNS seguro para asociar certificados con nombres de dominio para S/MIME . IETF . doi : 10.17487/RFC8162 . RFC 8162. Recuperado el 30 de marzo de 2022 .
  6. ↑ Wouters, P. (agosto de 2016). Enlaces de autenticación de entidades nombradas (DANE) basados ​​en DNS para OpenPGP . IETF . doi : 10.17487/RFC7929 . RFC 7929. Consultado el 14 de septiembre de 2016 .
  7. ↑ Langley, Adam (17 de enero de 2015). "ImperialViolet: ¿Por qué no DANE en los navegadores?" . www.imperialviolet.org . Consultado el 24 de marzo de 2017 .
  8. ↑ Duane Wessels, Verisign (16 de mayo de 2016). "Aumento de la clave de firma de la zona de fuerza para la zona raíz" . Verisign.com . Consultado el 29 de diciembre de 2016 .
  9. ↑ "Guía DNSSEC de Bind9" . bind9.readthedocs.io . Consultado el 22 de agosto de 2021 .
  10. ↑ Adam Langley (2012-10-20). "Certificados grapados de DANE" . ImperialViolet . Consultado el 16 de abril de 2014 .
  11. ↑ Adam Langley (16 de junio de 2011). "HTTPS autenticado por DNSSEC en Chrome" . ImperialViolet . Consultado el 16 de abril de 2014 .
  12. ↑ Cómo agregar compatibilidad con DNSSEC a Google Chrome
  13. ↑ "672600 - Usar la cadena DNSSEC/DANE integrada en el protocolo de enlace TLS en la validación de la cadena de certificados" .
  14. ↑ "1479423 - soporte para validación DNSSEC/DANE/TLSA" .
  15. ↑ Weber, Johannes (25 de octubre de 2016). "Cómo usar DANE/TLSA" . Weberblog.net .
  16. ↑ Validador DNSSEC/TLSA
  17. ↑ "GnuPG - Notas de la versión" . gnupg.org. 12 de junio de 2021. Consultado el 27 de agosto de 2021 .
  18. ↑ "cheogram-android 2.13.0-1" . Consultado el 11 de febrero de 2021 .
  19. ↑ "Preguntas frecuentes de FairEmail" . m66b.github.io. 3 de mayo de 2025. Consultado el 3 de mayo de 2025 .
  20. ↑ "Soporte TLS de Postfix - DANE" . Postfix.org . Consultado el 16 de abril de 2014 .
  21. ↑ "Lanzamiento de PowerMTA 5.0" . SparkPost.com . Consultado el 26 de abril de 2020 .
  22. ↑ "Especificación Exim 4.91: Conexiones SMTP cifradas mediante TLS/SSL / 15. DANE" . exim.org . Consultado el 5 de julio de 2018 .
  23. ↑ "mod_s2s_auth_dane_in" . prosody.im . Consultado el 11 de febrero de 2024 .
  24. ↑ Scaturro, Michael (24 de agosto de 2014). «Proteja su correo electrónico al estilo alemán» . The Guardian . Consultado el 29 de abril de 2018. ... El pasado mes de mayo, [Posteo] se convirtió en el primer proveedor de correo electrónico del mundo en adoptar la autenticación de entidades nombradas basada en DNS (Dane) en sus servidores. ...  
  25. ↑ ¡ ¿DANE en todas partes?! Hagamos de Internet un lugar privado de nuevo , tutanota.de , consultado el 17 de diciembre de 2015.
  26. ↑ ¿Habrá cifrado de transporte para mi correo electrónico ?, mailbox.org , consultado el 14 de febrero de 2026.
  27. ↑ Richard Levitte (2016-01-07). "DANE CAMBIOS" . GitHub . Recuperado el 2016-01-13 .
  28. ↑ "Verificación de un certificado mediante DANE (DNSSEC)" . Gnu.org.
  29. ↑ Osterweil, Eric; Wiley, Glen; Okubo, Tomofumi; Lavu, Ramana; Mohaisen, Aziz (6 de julio de 2015). "Cifrado oportunista con semántica DANE e IPsec: IPSECA" . Grupo de trabajo de ingeniería de Internet .
  • DNSSEC es innecesario - Contra DNSSEC
  • A favor de DNSSEC : una refutación a los puntos expuestos en "Contra DNSSEC".
  • Lista de centros de pruebas DANE
  • Herramienta en línea para comprobar si los servidores de correo son compatibles con DNSSEC y DANE.
  • Defensa de DANE ilustrada con enlaces a guías prácticas y herramientas.