Solo me preguntaba. Usamos muchos certificados SSL. Hoy en día, casi exclusivamente utilizamos letsencrypt (¡gracias!). La conclusión de estos certificados es que la prueba de propiedad de los nombres de dominio en el certificado proviene del poder de manipular los registros DNS o el sitio web bajo estos dominios. La prueba de DNS proviene de agregar alguna clave (dada por letsencrypt) como un registro TXT al DNS.

Entonces, si es suficiente prueba para poder cambiar los registros DNS de un dominio, ¿por qué no usar certificados autofirmados con la huella digital en el DNS?

Diría que esto proporciona exactamente la misma cantidad de confianza que el procedimiento basado en DNS de letsencrypt (y otras CA):

1. Cree una CA autofirmada (solo siga los pasos de los diversos procedimientos)
2. Crear un certificado para algunos dominios
3. Firme el certificado del paso 2 con la CA del paso 1. Ahora tiene un certificado básico, firmado por una CA no confiable
4. Agregue un registro TXT (o dedicado) al DNS de cada uno de los dominios, indicando: firmamos el certificado de este dominio con esta CA. Como: 'CA = -pinta de dedo de CA-'
5. Un navegador descarga el certificado y lo verifica comparando la huella digital del certificado de CA / CA con los datos en el DNS para el dominio dado.

Esto permitiría crear certificados autofirmados de confianza sin interferencia de terceros, del mismo nivel de confianza que cualquier certificado SSL básico. Mientras tenga acceso al DNS, su certificado es válido. Incluso se podría agregar algo de encriptación DNSSEC, como hacer un hash de la CA más el registro SOA, para asegurarse de que la confianza desaparezca en los cambios en el registro DNS.

¿Se ha considerado esto antes?

Jelmer

La infraestructura básica, que haría esto posible, existe y se llama Autenticación basada en DNS de entidades nombradas (DANE) y se especifica en RFC6698 . Funciona mediante un TLSAregistro de recursos, que especifica el certificado o su clave pública de la entidad final o una de sus CA en la cadena (en realidad, hay cuatro tipos diferentes, consulte el RFC para obtener más detalles).

Adopción

Sin embargo, DANE aún no ha visto una adopción generalizada. VeriSign supervisa la adopción de DNSSEC y DANE y realiza un seguimiento de su crecimiento a lo largo del tiempo :

A modo de comparación, según VeriSign, existen alrededor de 2,7 millones de zonas DNS, lo que significa que un poco más del 1% de todas las zonas tienen al menos un registro TLSA.

No puedo dar ninguna respuesta autorizada, por qué DANE, pero aquí están mis especulaciones:

DANE tiene el mismo problema que las Listas de revocación de certificados (CRL) y el Protocolo de estado de certificados en línea (OCSP). Para verificar la validez de un certificado presentado, se debe contactar a un tercero. Hanno Böck ofrece una buena descripción general de por qué este es un gran problema en la práctica. Se reduce a la cuestión de qué hacer, cuando no puede comunicarse con el tercero. Los proveedores de navegadores optaron por un fallo suave (también conocido como permiso) en este caso, lo que hizo que todo fuera bastante inútil y Chrome finalmente decidió deshabilitar OCSP en 2012.

DNSSEC

Podría decirse que DNS ofrece una disponibilidad mucho mejor que los servidores CRL y OCSP de las CA, pero aún así hace imposible la verificación fuera de línea. Además, DANE, solo debe usarse junto con DNSSEC. Como el DNS normal opera sobre UDP no autenticado, es bastante propenso a la falsificación, ataques MITM, etc. La adopción de DNSSEC es mucho mejor que la adopción de DANE, pero aún está lejos de ser omnipresente.

Y con DNSSEC volvemos a encontrarnos con el problema del fallo suave. Que yo sepa, ninguno de los principales sistemas operativos de servidor / cliente proporciona un solucionador de validación DNSSEC de forma predeterminada.

Luego está también el tema de la revocación. DNSSEC no tiene mecanismo de revocación y se basa en claves de corta duración.

Soporte de software

Todo el software participante debe implementar el soporte DANE.

En teoría, podría pensar que este sería el trabajo de las bibliotecas de cifrado y los desarrolladores de aplicaciones no tendrían que hacer mucho, pero el hecho es que las bibliotecas criptográficas generalmente solo proporcionan primitivas y las aplicaciones tienen que hacer mucha configuración y configuración ellos mismos. (y lamentablemente hay muchas formas de equivocarse).

No sé, ningún servidor web importante (por ejemplo, Apache o nginx), por ejemplo, implementó DANE o tiene planes de hacerlo. Los servidores web son de particular importancia aquí, porque cada vez más cosas se basan en tecnologías web y, por lo tanto, a menudo son las primeras, donde las cosas se implementan.

Cuando miramos CRL, OCSP, y OCSP Grapado como comparación, podríamos inferir cómo será la historia de adopción de DANE. Solo algunas de las aplicaciones que usan OpenSSL, libnss, GnuTLS, etc. admiten estas características. Tomó un tiempo para que un software importante como Apache o nginx lo admitiera y, nuevamente, refiriéndose al artículo de Hanno Böck, se equivocaron y su implementación es defectuosa. Otros proyectos de software importantes, como Postfix o Dovecot no son compatibles con OCSPy tienen una funcionalidad CRL muy limitada, básicamente apuntan a un archivo en el sistema de archivos (que no es necesariamente una relectura regular, por lo que tendrías que recargar tu servidor manualmente, etc.). Tenga en cuenta que estos son proyectos, que con frecuencia usan TLS. Entonces puede comenzar a mirar cosas, donde TLS es mucho menos común, como PostgreSQL / MySQL, por ejemplo, y tal vez ofrecen CRL en el mejor de los casos.

Por lo tanto, ni siquiera los servidores web modernos lo implementan y la mayoría del otro software ni siquiera ha implementado OCSP y CRL, buena suerte con su aplicación o dispositivo empresarial de 5 años.

Aplicaciones potenciales

Entonces, ¿dónde podrías usar DANE? A partir de ahora, no en Internet en general. Si controla el servidor y el cliente, tal vez sea una opción, pero en este caso, a menudo puede recurrir a la fijación de clave pública.

En el espacio de correo, DANE está obteniendo cierta tracción, porque SMTP no tuvo ningún tipo de cifrado de transporte autenticado durante el mayor tiempo. Los servidores SMTP a veces usaban TLS entre sí, pero no verificaron que los nombres en los certificados realmente coincidieran, ahora están comenzando a verificar esto a través de DANE.

Diferentes tipos de procedimientos de validación de certificados.

Con los certificados regulares firmados por CA, hay varios niveles de validación de certificados:

• Validación de dominio (DV)
  Solo se valida la propiedad del nombre de dominio, solo el nombre de dominio se muestra como "Asunto" en el certificado
• Validación de la organización (OV) El
  nombre de dominio y el nombre del propietario están validados, el nombre de dominio y el nombre del propietario se muestran como "Asunto" en el certificado
• Validación Extendida (EV) La
  validación más rigurosa de la entidad propietaria, el nombre de dominio y el nombre del propietario se muestran como "Asunto" en el certificado, barra verde con el nombre del propietario

El proceso que describe y propone un reemplazo solo se aplica al nivel más bajo, Validación de dominio (DV).

DV es el nivel en el que la validación es relativamente sencilla de automatizar, como lo que ha hecho LetsEncrypt, y proporciona un nivel de confianza similar al que DNS podría proporcionar si se usara como la única fuente para un ancla de confianza (implicaciones de la IU, certificado puede ser confiable pero contener datos adicionales que de ninguna manera están validados).

Autenticación basada en DNS de entidades nombradas (DANE)

DANE se basa en DNSSEC (ya que la autenticidad de los datos DNS es crucial) para publicar información de anclaje de confianza para clientes TLS en DNS.

Utiliza el TLSAtipo RR y puede usarse para identificar el certificado o la clave pública ( selector ) de la entidad final o de la entidad emisora ​​de certificados, con o sin necesidad de que la validación de la cadena de certificados tenga éxito ( uso del certificado ) y cómo el certificado / los datos clave se representan en el registro ( tipo coincidente ).

El TLSAnombre del propietario del registro tiene un prefijo que indica el puerto y el protocolo (p _443._tcp. Ej. ) Y el RData indica los modos y cert usage, además de los datos de cert / key que coinciden. Consulte la sección 2.1 de RFC6698 para conocer los detalles de estos parámetros.selectormatching type

Un TLSAregistro puede, por ejemplo, verse así:

_443._tcp.www.example.com. IN TLSA  2 0 1 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971

Con los modos de uso 2o 3(indica el uso del ancla de confianza TLSA solo), un cliente compatible con DANE aceptaría un certificado que no esté firmado por una CA de confianza general pero que coincida con el TLSAregistro.
Esto es conceptualmente igual a lo que propone en su pregunta.

¿La captura? Los clientes conscientes de DANE son actualmente más o menos inexistentes, un problema es que DNSSEC en sí no está tan ampliamente implementado (especialmente la validación en la máquina del cliente) como lo que probablemente se necesitaría para que DANE despegue. Probablemente sea un pequeño problema de huevo y gallina, considerando que DANE es uno de los primeros casos de uso nuevos potencialmente grandes que se basan en datos DNS autenticados.

Hay un complemento de navegador que agrega validación DNSSEC y DANE , aparte de eso, no hay mucho que esté cerca de la corriente principal en este momento. Y, al ser un complemento en lugar de ser compatible de forma nativa, sirve más como prueba de concepto que cualquier otra cosa cuando se trata de uso general.

Se podría hacer. Ha sido considerado. Todavía podría suceder, pero no ha habido mucho movimiento.