La autenticación de entidades nombradas ( DANE ) basada en DNS es un protocolo de seguridad de Internet que permite que los certificados digitales X.509 , comúnmente utilizados para la seguridad de la capa de transporte (TLS), se vinculen a los nombres de dominio mediante las extensiones de seguridad del sistema de nombres de dominio (DNSSEC). [1]
Se propone en RFC 6698 como una forma de autenticar entidades de servidor y cliente TLS sin una autoridad de certificación ( CA ). Se actualiza con la guía operativa y de implementación en RFC 7671 . El uso específico de la aplicación de DANE se define en RFC 7672 para SMTP y RFC 7673 para usar DANE con registros de servicio (SRV) .
Razón fundamental
El cifrado TLS / SSL se basa actualmente en certificados emitidos por autoridades de certificación (CA). En los últimos años, varios proveedores de CA sufrieron graves violaciones de seguridad , lo que permitió la emisión de certificados para dominios conocidos a aquellos que no son propietarios de esos dominios. Confiar en una gran cantidad de CA puede ser un problema porque cualquier CA violada podría emitir un certificado para cualquier nombre de dominio. El 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). El DANE necesita que los registros DNS estén firmados con DNSSEC para que su modelo de seguridad funcione.
Además, el DANE permite al propietario de un dominio especificar qué CA puede 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:
- Transparencia del certificado
- Asegurarse de que las CA no autorizadas no puedan emitir certificados sin el permiso del titular del dominio sin ser detectadas
- Autorización de la autoridad de certificación de DNS
- Limitar qué CA pueden emitir certificados para un dominio determinado
Sin embargo, a diferencia del DANE, esas tecnologías tienen un amplio soporte de los navegadores.
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 de URI para designar SMTP seguro. [3] En consecuencia, la mayoría de los correos electrónicos que se envían a través de TLS utilizan únicamente cifrado oportunista . [4] Dado que DNSSEC proporciona una denegación de existencia autenticada (permite que un resolutor valide que un determinado nombre de dominio no existe), DANE permite una transición incremental a SMTP verificado y cifrado sin ningún otro mecanismo externo, como se describe en RFC 7672 . Un registro DANE indica que el remitente debe usar TLS. [3]
Además, existe un borrador para aplicar DANE a S / MIME , [5] y RFC 7929 estandariza los enlaces para OpenPGP . [6]
Apoyo
Aplicaciones
- Google Chrome no es compatible con DANE, ya que Google Chrome desea eliminar el uso de RSA de 1024 bits dentro del navegador [7] (DNSSEC anteriormente usaba una raíz firmada RSA de 1024 bits, [8] y muchas zonas todavía están firmadas con 1024- bit RSA). Según Adam Langley, el código fue escrito [9] y, aunque no está en Chrome hoy, [10] permanece disponible en forma de complemento. [11]
- Mozilla Firefox (antes de la versión 57) tenía soporte a través de un complemento. [12]
- GNU Privacy Guard Permite obtener claves a través de OpenPGP DANE (--auto-key-located). Nueva opción: print-dane-records. (versión 2.1.9) [13]
Servidores
- Sufijo [14]
- PowerMTA [15]
- Halón [16] [17]
- Exim [18]
Servicios
- Posteo [19]
- Tutanota [20]
Bibliotecas
- OpenSSL [21]
- GnuTLS [22]
TLSA RR
El TLSA RR (registro de recursos) de un servicio se encuentra en un nombre DNS que especifica las restricciones de certificado que se deben aplicar para los servicios en un determinado puerto TCP o UDP. Al menos uno de los 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 de nombres comunes 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 afirme su validez. SMTP no requiere coincidencias de nombre común, si el valor de uso del certificado es 3 (DANE-EE), pero de lo contrario requiere una coincidencia de nombre común. Es importante verificar si existen instrucciones específicas para el protocolo que se está utilizando.
Campos de datos RR
El RR en sí tiene 4 campos de datos, que describen qué nivel de validación proporciona el propietario del dominio.
- el campo de uso del certificado
- el campo selector
- el campo de tipo coincidente
- los datos de la asociación del certificado
P.ej _25._tcp.somehost.example.com. TLSA 3 1 1 0123456789ABCDEF
Uso del certificado
Validación de ruta PKIX | Objetivo de RR | |
---|---|---|
Ancla de confianza | Entidad final | |
Requerido | 0 | 1 |
No requerido | 2 | 3 |
El primer campo después del texto TLSA en el RR de DNS, especifica cómo verificar el certificado.
- Un valor de 0 es para lo que comúnmente se llama restricción CA (y PKIX-TA). El certificado proporcionado al establecer TLS debe ser emitido por la CA raíz listada o una de sus CA intermedias, con una ruta de certificación válida a una CA raíz en la que ya confía la aplicación que realiza la verificación. El registro puede apuntar simplemente a una CA intermedia, en cuyo caso el certificado para este servicio debe venir a través de esta CA, pero toda la cadena a una CA raíz confiable aún debe ser válida. [a]
- Un valor de 1 es para lo que comúnmente se denomina restricción de certificado de servicio (y PKIX-EE). El certificado utilizado debe coincidir exactamente con el registro TLSA y también debe pasar la validación de la ruta de certificación PKIX a una CA raíz confiable.
- Un valor de 2 es para lo que comúnmente se llama Trust Anchor Assertion (y DANE-TA). El certificado utilizado tiene una ruta de certificación válida que apunta a la mención del certificado en este registro, pero no es necesario que pase la validación de la ruta de certificación PKIX a una CA raíz confiable.
- Un valor de 3 corresponde a lo que comúnmente se denomina certificado emitido por dominio (y DANE-EE). Los servicios utilizan un certificado autofirmado. No está firmado por nadie más y es exactamente este registro.
Selector
Cuando se conecta al servicio y se recibe un certificado, el campo selector especifica qué partes del mismo deben verificarse.
- Un valor de 0 significa seleccionar todo el certificado para la coincidencia.
- Un valor de 1 significa seleccionar solo la clave pública para la coincidencia de certificados. Hacer coincidir la clave pública suele ser suficiente, ya que es probable que sea única.
Tipo coincidente
- Un tipo de 0 significa que toda la información seleccionada está presente en los datos de asociación del certificado .
- Un tipo de 1 significa hacer un hash SHA-256 de los datos seleccionados.
- Un tipo de 2 significa hacer un hash SHA-512 de los datos seleccionados.
Datos de asociación de certificados
Los datos reales que se compararán según la configuración de los otros campos. Esta es una "cadena de texto" larga de datos hexadecimales.
Ejemplos de
El certificado HTTPS para www.ietf.org especifica 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 mail.ietf.org._25._tcp.mail.ietf.org. TLSA 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6
Finalmente, el siguiente ejemplo, hace lo mismo que los demás, pero hace el cálculo 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 basada en DNS de entidades nombradas (DANE)
- RFC 6698 Protocolo de seguridad de la capa de transporte (TLS) de autenticación basada en DNS de entidades con nombre (DANE): TLSA
- RFC 7218 Adición de acrónimos para simplificar las conversaciones sobre la autenticación basada en DNS de entidades nombradas (DANE)
- RFC 7671 Protocolo de autenticación de entidades con nombre (DANE) basado en DNS: actualizaciones y orientación operativa
- RFC 7672 Seguridad SMTP a través de la autenticación oportunista basada en DNS de entidades designadas (DANE) Seguridad de la capa de transporte (TLS)
- RFC 7673 Uso de la autenticación basada en DNS de entidades con nombre (DANE) Registros TLSA con registros SRV
- RFC 7929 Autenticación basada en DNS de enlaces de entidades con nombre (DANE) para OpenPGP
Ver también
- Autorización de la autoridad de certificación de DNS
Notas
- ^ Un ejemplo poco común en el que esto podría ser útil sería si no confía completamente en la CA raíz, pero muchas aplicaciones aún la usan, y confía en una CA intermedia específica, por lo que enumera la CA intermedia y aún obtiene verificación de ruta de plena confianza.
Referencias
- ^ Barnes, Richard (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 .
- ^ "Soporte Postfix TLS - Verificación segura del certificado del servidor" . Postfix.org . Consultado el 30 de diciembre de 2015 .
- ^ a b Dukhovni; Hardaker (28 de julio de 2013). DANE para SMTP (PDF) . Actas del IETF 87. IETF.
- ^ Filippo Valsorda (31 de marzo de 2015). "El triste estado del cifrado SMTP" . Consultado el 30 de diciembre de 2015 .
- ^ Uso de DNS seguro para asociar certificados con nombres de dominio para S / MIME . IETF . 2015-08-27. Proyecto de identificación-ietf-dane-smime-09.
- ^ Wouters, P. (agosto de 2016). Autenticación basada en DNS de enlaces de entidades nombradas (DANE) para OpenPGP . IETF . doi : 10.17487 / RFC7929 . RFC 7929 . Consultado el 14 de septiembre de 2016 .
- ^ 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 .[ fuente autoeditada ]
- ^ 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 .
- ^ Adam Langley (20 de octubre de 2012). "Certificados grapados DANE" . ImperialViolet . Consultado el 16 de abril de 2014 .[ fuente autoeditada ]
- ^ Adam Langley (16 de junio de 2011). "HTTPS autenticado por DNSSEC en Chrome" . ImperialViolet . Consultado el 16 de abril de 2014 .[ fuente autoeditada ]
- ^ Cómo agregar soporte DNSSEC a Google Chrome
- ^ "Validador DNSSEC / TLSA" . Archivado desde el original el 2 de junio de 2018 . Consultado el 30 de abril de 2014 .
- ^ "GnuPG 2.1.9 lanzado" . gnupg.org . Consultado el 10 de octubre de 2015 .[ fuente autoeditada ]
- ^ "Soporte Postfix TLS - DANE" . Postfix.org . Consultado el 16 de abril de 2014 .
- ^ "Lanzamiento de PowerMTA 5.0" . SparkPost.com . Consultado el 26 de abril de 2020 .
- ^ Jakob Schlyter, Kirei AB. "DANE" (PDF) . RTR-GmbH . Consultado el 17 de diciembre de 2015 .
- ^ "Soporte Halon DANE" . Halon Security AB . Consultado el 17 de diciembre de 2015 .[ fuente autoeditada ]
- ^ "Exim 4.91 spec: conexiones SMTP cifradas mediante TLS / SSL / 15. DANE" . exim.org . Consultado el 5 de julio de 2018 .
- ^ Scaturro, Michael (24 de agosto de 2014). "Proteja su correo electrónico a la manera alemana" . The Guardian . Consultado el 29 de abril de 2018 .
... En mayo pasado, [Posteo] se convirtió en el primer proveedor de correo electrónico del mundo en adoptar la Autenticación de Entidades Nombradas (Dane) basada en DNS en sus servidores. ...
- ^ ¡¿DANE en todas partes ?! Hagamos de Internet un lugar privado de nuevo , tutanota.de , consultado el 17 de diciembre de 2015[ fuente autoeditada ]
- ^ Richard Levitte (7 de enero de 2016). "DANE CHANGES" . Consultado el 13 de enero de 2016 .[ fuente autoeditada ]
- ^ "Verificación de un certificado mediante DANE (DNSSEC)" . Gnu.org.[ fuente autoeditada ]
enlaces externos
- DNSSEC es innecesario - Contra DNSSEC
- Para DNSSEC - Una refutación a los puntos en "Contra DNSSEC"
- Lista de sitios de prueba DANE
- Herramienta en línea para verificar servidores de correo en busca de soporte DNSSEC y DANE
- Incidencia ilustrada del DANE con enlaces a procedimientos y herramientas