¿Por qué usar CAA?
Una CA siempre usa métodos de validación de dominio para asegurarse de que cada SSL /TLS la solicitud de certificado está autorizada (generalmente asegurándose de que esté vinculada de alguna manera a un sitio en particular usando ese dominio).
Por ejemplo, una CA puede proporcionar un archivo de verificación especial al solicitante. Colocar este archivo en el sitio web demuestra que el solicitante también controla ese sitio, pero no puede garantizar legitimidad de ese control. Un pirata informático que obtiene el control de un sitio puede hacerse pasar por el propietario legítimo y luego puede solicitar y recibir un SSL /TLS certificado que pasa los controles estándar de cualquier CA y, por lo tanto, parece legítimo. Luego podrían darse la vuelta y usar ese SSL /TLS certificado de travesura, en ese sitio o en otro lugar.
CAA ayuda a bloquear este tipo de explotación definiendo qué CA pueden emitir certificados para un dominio (o incluso restringiendo la emisión de certificados por completo). Esto limita el daño que puede infligir un secuestrador: incluso si tienen el control de un sitio, tendrán drásticamente menos opciones para obtener un SSL /TLS certificado.
Cómo funciona CAA
CAA usa DNS
El Sistema de nombres de dominio (DNS) es una parte crucial de la infraestructura de internet. El propietario de cualquier dominio mantiene registros DNS (dentro del llamado archivos de zona) señalando su nombre de dominio a la dirección IP donde está alojado su sitio, y nos permite escribir google.com en una ventana del navegador en lugar de 216.58.194.46.
Los registros DNS se utilizan comúnmente como la "guía telefónica para Internet", pero el DNS también permite otros tipos de registros especiales que pueden asignar otra información a un nombre de dominio.
Registros CAA
CAA usa un tipo especial de registro llamado Registro de recursos de autorización de la autoridad de certificación (Registro CAA). Estos se publican utilizando DNS, y el propietario del dominio simplemente agrega registros CAA junto con sus otros registros DNS. Un registro CAA incluye un etiqueta y propuesta de, y el par etiqueta-valor se conoce como perfecta. También es un bandera indicando cuán crítica es esta propiedad. Así es como se ve uno:
ejemplo.com. Problema CAA 0 "ssl.com"
Aquí, example.com es el dominio al que se aplica este registro, y CAA nos permite saber qué tipo de registro es este. los 0 es la bandera (cero es el valor predeterminado; hablaremos de esto a continuación). La etiqueta es y el valor (entre comillas) es ssl.com, que en conjunto conforman la propiedad.
Banderas
Las banderas tienen solo dos estados estrictamente definidos actualmente: 0 (no crítico) y 1 (crítico). Una bandera crítica le dice a la CA que deben Comprenda completamente la etiqueta de propiedad para continuar. RFC 6844 deja abiertas otras posibilidades para el uso de indicadores definidos por el usuario (también hablaremos de esto a continuación).
Etiquetas
RFC 6844 define el uso de tres etiquetas comunes: , problema yodef. (Al igual que con las banderas, permite otros tipos de etiquetas personalizadas potenciales).
El etiqueta
El etiqueta especifica qué CA (si existe) está autorizada para emitir certificados para este dominio. Por ejemplo, el propietario del dominio example.com puede restringir la emisión del certificado a una CA (aquí, SSL.com) mediante el siguiente archivo de zona DNS:
example.com. CAA 0 problema "ssl.com"
El propietario de un dominio puede elegir configurar múltiples archivos de zona para un dominio:
example.com. CAA 0 problema "ssl.com" example.com. CAA 0 problema "comodoca.com"
Los registros anteriores limitan SSL /TLS emisión de certificados para example.com a dos CA (SSL.com y Comodo.com).
El record también autoriza a la CA designada a emitir certificados para cualquier subdominio del dominio especificado. Un registro que permite SSL.com puede permitir la emisión de certificados para example.com y subdominios como www.example.com, correo.ejemplo.com e incluso el subdominio comodín especial * .example.com.
Un registro CAA puede usarse para restringir emisión de certificados, también: este registro les dice a las autoridades de certificación que usan CAA que no SSL /TLS los certificados deben emitirse para example.com y subdominios por any CALIFORNIA:
example.com. CAA 0 problema ";"
(El punto y coma en este ejemplo significa "no permitas nada aquí", Pero como mostraremos más adelante, también se utiliza para definir parámetros personalizados).
Tenga en cuenta que una etiqueta de emisión estándar permite que la CA emita un certificado para un comodín a menos que lo modifique ...
El problema etiqueta
Esta etiqueta especifica que una CA está autorizada a emitir certificados comodín para el dominio del propietario (es decir, * .example.com).
Los comodines son un tipo especial de subdominio general, y se requiere especial cuidado y atención al emitir certificados comodín. los problema La etiqueta permite al propietario del dominio definir qué CA pueden emitir certificados para comodines por separado del dominio principal u otros subdominios. problema las etiquetas tienen prioridad sobre cualquier Etiquetas Usan la misma sintaxis que el etiqueta. Algunos ejemplos:
example.com. CAA 0 problema "ssl.com" example.com. CAA 0 issuewild ";"
Lo anterior permite que SSL.com emita certificados para example.com y todos los subdominios excepto para el comodín * .example.com. (Ni SSL.com ni ninguna otra CA pueden emitir certificados comodín para example.com.)
example.com. CAA 0 problema ";" example.com. CAA 0 issuewild "ssl.com"
Este ejemplo prohíbe all CA para emitir certificados a example.com y sus subdominios, pero crea una excepción para permitir que SSL.com emita certificados comodín (y only certificados comodín) para example.com.
El yodef etiqueta
La tercera etiqueta definida es yodef. Esta etiqueta se puede utilizar para informar solicitudes de certificados no válidos al propietario del dominio, y se ven así:
example.com. CAA 0 iodef "mailto: certissues@example.com" example.com. CAA 0 iodef "certissues.example.com"
El registro superior proporciona la información de CA necesaria para enviar una notificación por correo electrónico a la dirección certificadostejidos@ejemplo.com. El segundo indica a la CA que publique un mensaje de incidente en un servicio web (configurado para este fin por el propietario del dominio) en certificados.ejemplo.com. (Se pueden usar uno o ambos métodos, dependiendo de cómo la CA y el propietario del dominio hayan configurado sus operaciones).
yodef publicar mensajes utilizan un formato estándar llamado Descripción del objeto incidente Formato de intercambio o IODEF - de ahí el nombre. (IODEF se define en RFC 6546.)
Banderas y etiquetas definidas por CA
CAA como se describe en RFC 6844 solo define específicamente dos estados de bandera (0 y 1) y tres etiquetas ( , problema yodef) Sin embargo, deja el diseño lo suficientemente abierto para que las CA puedan crear y utilizar etiquetas y banderas personalizadas para definir su proceso de emisión de certificados. Los ejemplos pueden ser:
example.com. CAA 0 problema "SSL.com; policy = ev"
Este registro usa un estándar etiqueta con un parámetro adicional que indica a la CA que use su política de Validación Extendida (EV) al emitir un certificado para este dominio.
example.com. CAA 128 pca "PCA = 12345"
El propietario del dominio podría usar este registro con un nuevo, definido por CA PCA etiqueta para mostrar que tienen una Cuenta de Cliente Preferido y establece el número de cuenta como un parámetro. (El indicador también puede ser un valor personalizado de hasta 255). Dependiendo de cómo la CA configure la cuenta, esto podría permitir métodos de facturación particulares, verificación adicional definida por la cuenta u otro manejo especial.
Pros y contras
Ventajas ...
Hay varias razones excelentes para utilizar CAA. La principal y más importante ventaja es la capacidad de la CAA para reducir en gran medida el riesgo de emisión incorrecta de certificados. Esto ayuda a proteger su dominio, su negocio y su identidad en línea. Los atacantes potenciales que puedan haber encontrado un error en el software de una CA en particular no pueden explotarlo para emitir certificados SSL para su dominio. Además, el uso de la etiqueta iodef le permite obtener un informe si se intenta una explotación.
El diseño de CAA aumenta la seguridad, pero también puede permitir una asignación más detallada de recursos; por ejemplo, una empresa podría configurar registros para permitir (o limitar) el departamento de ventas y marketing para comprar certificados SSL para sales.example.com de una fuente designada.
Además, CAA ofrece una gran flexibilidad. Para el propietario de un dominio, utiliza registros de recursos DNS que están bajo su propio control y se pueden cambiar según sea necesario, por lo que no están vinculados a una CA específica (y pueden tener más de una CA autorizada con registros de emisión para cualquier nombre de dominio dado) . Para las CA, incluso aparte de los usos personalizados, las reglas recientemente adoptadas por el Foro CA / B (el grupo que establece los estándares para las cuestiones de seguridad de la CA y del navegador) pueden permitir que los registros de la CAA se utilicen con fines de validación, proporcionando otra buena razón para utilizarlos.
... y menos
El mayor problema con CAA es que no ha sido adoptado por todas las CA. Los requisitos básicos del Foro CA / B (que cumplen todas las CA de confianza) le indican a una CA que especifique el grado en el que apoya CAA en su documentación en línea. Sin embargo, en el momento de escribir estas líneas, el uso de CAA es solo recomendado, no requerido. Las autoridades de certificación que no cumplan con CAA aún pueden ser identificadas, y hasta que CAA esté en uso más amplio, un secuestrador probablemente podrá encontrar una CA no conforme dispuesta a emitir un certificado falso.
Una desventaja relacionada es que incluso cuando se colocan registros CAA, un usuario no puede hacer cumplir su uso por una autoridad certificadora. Una CA debe cumplir con RFC 6844 para que se actúe sobre esos registros, y una CA que no cumpla con los requisitos podría simplemente ignorar los deseos expresos del propietario del dominio declarados en sus registros de CAA.
CAA también debe estar configurado correctamente tanto por el propietario del dominio como por una CA. Let's Encrypt (que es compatible con CAA) recientemente informó un problema menor con su código base lo que desafortunadamente llevó a que se ignoraran las reglas de la CAA y a la emisión incorrecta de seis certificados. Ninguna de estas fueron excepciones maliciosas (y felicitaciones al equipo de Let's Encrypt por resolver e informar el problema pocas horas después del descubrimiento). Sin embargo, esto subraya que una autoridad certificadora compatible deben implementar CAA flawlessly.
Otro problema potencial es la dependencia de CAA del DNS. A menos que el propietario de un dominio asegure sus servicios de nombres, esto puede ser un vector de ataque. RFC 6844 sugiere implementar Extensiones de seguridad del sistema de nombres de dominio (DNSSEC), que utiliza registros DNS firmados digitalmente para autenticar datos y combatir la amenaza de falsificación de DNS.
Por último, incluso con CAA en su lugar y correctamente implementado, un registro de CAA por sí solo no puede evitar por completo la emisión de certificados fraudulentos. Aunque CAA es una herramienta útil e importante para limitar las opciones de un atacante, un secuestrador con suficiente acceso (por ejemplo, controlando el DNS o mediante ingeniería social) puede ser capaz de sortearlo.
Conclusión
La autorización de la autoridad de certificación tiene un gran potencial como parte de un ecosistema de seguridad más amplio, y la adopción e implementación generalizada de CAA protegerá contra la emisión incorrecta de certificados. Si bien es lamentable que no todas las autoridades de certificación admitan actualmente la CAA, existe un debate sobre cómo hacer esto más sugerido u obligatorio para todas las CA. Aunque la CAA por sí sola no detendrá todas las emisiones incorrectas de certificados, es un buen paso en la dirección correcta, y SSL.com desea instarle a que considere utilizar los registros de la CAA usted mismo.
Referencias
- RFC6844: Registro de recursos de autorización de autoridad de certificación DNS (CAA)
- RFC5070: El formato de intercambio de descripción de objeto de incidente
- RFC6546: Transporte de mensajes de defensa entre redes en tiempo real (RID) a través de HTTP /TLS
- RFC4033: Introducción y requisitos de seguridad de DNS
- Boleta 125 del Foro CA / B - Registros CAA
- Entrada de Wikipedia sobre la Autorización de la Autoridad de Certificación DNS