Wikipedia

Autorización de la Autoridad de Certificación

Autorización de la Autoridad de Certificación en el Sistema de Nombres de Dominio (en idioma inglés: "DNS Certification Authority Authorization"), abreviado como DNS CAA o simplemente CAA, es un mecanismo de política de seguridad en Internet que permite a los titulares de nombres de dominio indicar a las autoridades certificadoras si están autorizadas a emitir certificados digitales para un nombre de dominio particular utilizando un registro de recursos del Sistema de Nombres de Dominio (DNS). Fue redactado por Phillip Hallam-Baker y Rob Stradling en respuesta a las crecientes preocupaciones sobre la seguridad de las autoridades de certificación de confianza pública. Actualmente es un estándar propuesto de la Grupo de Trabajo de Ingeniería de Internet (IETF).

Historia editar

Una serie de certificados emitidos incorrectamente a partir de 2001 dañó la confianza en las autoridades certificadoras de confianza pública,[1]​[2]​ y aceleraron el trabajo en varios mecanismos de seguridad,[3]​ incluida la transparencia del certificado para rastrear errores de emisión, HTTP Public Key Pinning y DANE a bloquear certificados emitidos erróneamente en el lado del cliente, y CAA para bloquear la emisión errónea en el lado de la autoridad certificadora.[4]​ El primer borrador de CAA fue escrito por Phillip Hallam-Baker y Rob Stradling, y presentado como borrador de Internet del IETF en octubre de 2010.[5]​ Esto fue progresivamente mejorado por el Grupo de Trabajo PKIX,[6]​ y presentado al IESG como RFC 6844, un Estándar Propuesto, en enero de 2013. El software BIND, el cual es un estándar de facto en el campo de los DNS,[7]​ adoptó el uso de la norma CAA en la versión 9.10.1B en agosto de 2014.[8]​

La discusión en CA/Browser Forum comenzó poco después,[4]​ y en marzo de 2017 votaron a favor de que la implementación de la CAA sea obligatoria para todas las autoridades de certificación en septiembre de 2017.[9]​[10]​ Al menos una autoridad de certificación, Comodo, no implementó CAA antes de la fecha límite.[11]​ Los servidores DNS de Microsoft Azure fueron actualizados para prestar este servicio en noviembre de 2017.[12]​ Un estudio de 2017 realizado por la Universidad Técnica de Múnich encontró muchas instancias en las que las autoridades de certificación no implementaron correctamente alguna parte del estándar.[4]​ A partir de junio de 2018, Qualys informa que el 3,4% de los 150,000 sitios web más populares de TLS respaldan los registros de CAA.[13]​

Normativa editar

El registro CAA se caracteriza por tres propiedades fundamentales:[14]​

  • Bandera o indicador, flag: un valor entero sin signo, 0 para valor normal, 1 (o mayor) para representar el indicador crítico que tiene un significado específico según la norma RFC 6844.
  • Etiqueta, tag: una cadena de texto ASCII que puede albergar uno de los siguientes valores
    • issue: permite a los propietarios del dominio especificar las Autoridades de Certificación a las que se les permite emitir todos los tipos de certificados.
    • issuewild: permite a los propietarios del dominio especificar las Autoridades de Certificación a las que se les permite emitir certificados de todos los tipos (solo certificados con comodines del tipo *.example.com pero no del tipo *.mail.example.com)
    • iodef (Incident Object Description Exchange Format, RFC 5070, RFC 6685 y RFC 7970): permite a los propietarios de dominios especificar una dirección de correo electrónico (mailto:) o un nombre de anfitrión al que las Autoridades de Certificación pueden notificar las solicitudes de emisión de certificados para dominios que de otro modo no estarían autorizados a través de los registros CAA, según formato XML especificado en RFC 6546.
  • Valor: el valor asociado con la etiqueta específica utilizada.

Además se encuentran reservadas para uso futuro las siguientes tres propiedades: auth, path y policy (HB2011 RFC 6844).

Para aquellos servidores DNS que aun no hayan implementado los CAA o les sean desconocidos, deberán responder a las solicitudes con un código de NOERROR en vez de un código NOTIMP (NOT IMPlement) de acuerdo a RFC 1035.[15]​

Esta normativa es apenas un paliativo de seguridad: un atacante sofisticado podría establecer un falso servicio de DNS, por ejemplo en un lugar público ofreciendo acceso a Internet de manera inalámbrica y gratuita.[16]​

Ejemplos editar

 
Ejemplo de consulta con el comando dig de la Autorización de la Autoridad de Certificación en el Sistema de Nombres de Dominio (en idioma inglés: "DNS Certification Authority Authorization" o CAA) para el dominio Wikipedia.org

Para informar a las autoridades de certificación que solo la autoridad de certificación identificada por ca.example.net está autorizada para emitir certificados para example.com y todos los subdominios, y que las autoridades de certificación deben informar de las solicitudes de certificado no válidas a seguridad@example.net, uno puede usar este registro CAA: 

example.com.  IN  CAA 0 issue "ca.example.net"
example.com.  IN  CAA 0 iodef "mailto:security@example.com"

Para rechazar cualquier emisión de certificado, uno puede permitir la emisión solo a una lista de emisor vacía: 

example.com.  IN  CAA  0 issue ";"

Al usar un subdominio, las autoridades de certificación escalan el árbol de nombres DNS buscando un registro CAA hasta que encuentran uno o alcanzan el dominio de segundo nivel, en este ejemplo la Autoridad Certificadora permitirá avalar certificados para example.com y certs.nocerts.example.com pero no para nocerts.example.com: 

example.com.  IN  CAA  0 issue "ca.example.net"
nocerts.example.com.  IN  CAA  0 issue ";"
certs.nocerts.example.com.  IN  CAA  0 issue "ca.example.net"

Si un registro está vacío, cualquier registro CNAME se verifican para un registro CAA antes de pasar a un subdominio superior: 

example.net.  IN  CAA  0 issue "ca.example.net"
example.com.  IN  CAA  0 issue ";"
certs.example.com.  IN  CNAME  example.net

Autorizar la emisión de certificados normales, mientras se restringe la emisión de certificado comodín: 

example.com.  IN  CAA  0 issue "ca.example.net"
example.com.  IN  CAA  0 issuewild ";"

Para autorizar la emisión de example.com pero no de nocerts.example.com: 

example.com.  IN  CAA  0 issue "ca.example.net"
nocerts.example.com.  IN  CAA  0 issue ";"

Para usar una extensión futura del protocolo, por ejemplo, una que defina una nueva propiedad futura, que debe ser entendida por la autoridad certificadora antes de que puedan proceder de manera segura, se puede configurar la bandera emisor crítico (128): 

example.com.  IN  CAA  0 issue "ca.example.net"
example.com.  IN  CAA  128 future "value"

Véase también editar

Referencias editar

  1. ↑ Ristić, Ivan (10 de octubre de 2017). «SSL/TLS and PKI History» (html). Feisty Duck (en inglés). Archivado desde el original el 11 de marzo de 2018. Consultado el 16 de junio de 2018. «January 2001 Fraudulent Microsoft certificates Someone calls VeriSign claiming to be from Microsoft, pays $400, and gets away with two code-signing certificates. The certificates have no special powers, but the owner name is misleading and potentially dangerous.» 
  2. ↑ Bright, Peter (29 de agosto de 2011). «Another fraudulent certificate raises the same old questions about certificate authorities» (html). Ars Technica (en inglés). Archivado desde el original el 10 de febrero de 2018. Consultado el 16 de junio de 2018. «Earlier this year, an Iranian hacker broke into servers belonging to a reseller for certificate authority Comodo and issued himself a range of certificates for sites including Gmail, Hotmail, and Yahoo! Mail. With these certificates, he could eavesdrop on users of those mail providers, even if they use SSL to protect their mail sessions.» 
  3. ↑ Ruohonen, Jukka (20 de abril de 2018). «An Empirical Survey on the Early Adoption of DNS Certification Authority Authorization» (en en). arXiv:1804.07604  [cs.CR]. 
  4. ↑ a b c Scheitle, Quirin; Chung, Taejoong; Hiller, Jens; Gasser, Oliver; Naab, Johannes; van Rijswijk-Deij, Roland; Hohlfeld, Oliver; Holz, Ralph; Choffnes, Dave; Alan, Mislove; Carle, Georg (11 de abril de 2018). «A last Look at Certification Authority Authorization (CAA)» (pdf). ACM SIGCOMM Computer Communication Review (en inglés). Consultado el 16 de junio de 2018. 
  5. ↑ Phillip Hallam-Baker; Rob Stradling; Ben Laurie. «DNS Certification Authority Authorization (CAA) Resource Record draft-hallambaker-donotissue-04» (html). IETF (en inglés). Archivado desde el original el 16 de junio de 2018. Consultado el 16 de junio de 2018. «This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at https://www.ietf.org/archive/id/draft-hallambaker-donotissue-04.txt». 
  6. ↑ «DNS Certification Authority Authorization (CAA) Resource Record draft-ietf-pkix-caa-00» (html). IETF (en inglés). 2 de junio de 2011. Archivado desde el original el 16 de junio de 2018. Consultado el 16 de junio de 2018. 
  7. ↑ Sisson, Geoffrey (30 de noviembre de 2010). «DNS Survey: October 2010» (pdf). The Measurement Factory (en inglés). Archivado desde el original el 14 de agosto de 2016. Consultado el 17 de junio de 2018. «This study, commissioned by Infoblox, undertakes to measure the number of DNS servers on the Internet and to quantify their various DNS behaviors and configuration choices.» 
  8. ↑ Risk, Vicky (29 de agosto de 2014). «Certificate Authority Authorization Records» (HTML). Internet Systems Consortium (en inglés). Archivado desde el original el 23 de agosto de 2017. Consultado el 17 de junio de 2018. «Support for the CAA record was added to BIND with the 9.10.1B release, after Rick Andrews of Symantec approached us at an IETF meeting and asked why we didn’t have it already. Rick is an expert and evangelist for the use of certificates, so we invited Rick to explain why people should use CAA records.» 
  9. ↑ Hall, Kirk (8 de marzo de 2017). «Results on Ballot 187 - Make CAA Checking Mandatory» (html). CA/Browser Forum (en inglés). Consultado el 16 de junio de 2018. 
  10. ↑ Beattie, Doug (22 de agosto de 2017). «What is CAA (Certificate Authority Authorization)?» (html). GlobalSign (en inglés). Consultado el 16 de junio de 2018. 
  11. ↑ Cimpanu, Catalin (11 de septiembre de 2017). «Comodo Caught Breaking New CAA Standard One Day After It Went Into Effect» (html). Bleeping Computer (en inglés). Consultado el 16 de junio de 2018. 
  12. ↑ Sarma, Subra (16 de noviembre de 2017). «Azure DNS Updates – CAA Record Support and IPv6 Nameservers» (html). Microsoft (en inglés). Archivado desde el original el 24 de noviembre de 2017. Consultado el 17 de junio de 2018. «We are pleased to announce a couple of updates to Azure DNS that have been long awaited by our customers: * Support for Certificate Authority Authorization (CAA) Records * IPv6 Nameservers». 
  13. ↑ «SSL Pulse». SSL Labs. 3 de junio de 2018. Consultado el 16 de junio de 2018. 
  14. ↑ Mattias, Geniar (8 de abril de 2017). «CAA checking becomes mandatory for SSL/TLS certificates» (html) (en inglés). Archivado desde el original el 9 de abril de 2017. Consultado el 17 de junio de 2018. «The CAA record is a new resource record, next to the usual A, CNAME, MX, TXT, ... records you might already know. The syntax is as follows; CAA <flags> <tag> <value> Which translates to; flag: An unsigned integer between 0-255. tag: An ASCII string that represents the identifier of the property represented by the record. value: The value associated with the tag». 
  15. ↑ «Certificate Authority Authorization (CAA)» (html). Let's encrypt (en inglés). 27 de julio de 2017. Archivado desde el original el 2 de agosto de 2017. Consultado el 17 de junio de 2018. «Some DNS providers that are unfamiliar with CAA initially reply to problem reports with “We do not support CAA records.” Your DNS provider does not need to specifically support CAA records; it only needs to reply with a NOERROR response for unknown query types (including CAA). Returning other opcodes, including NOTIMP, for unrecognized qtypes is a violation of RFC 1035, and needs to be fixed.» 
  16. ↑ Wolber, Andy (17 de junio de 2018). «How to add a Certificate Authority Authorization record in Google Domains» (html). TechRepublic (en inglés). Archivado desde el original el 29 de nobviembre de 2017. Consultado el 17 de junio de 2018. «As with most security measures, problems may still arise. A security failure at either your certificate provider or your domain name registrar could produce problems. And a sophisticated attacker might still be able to serve false DNS data designed to deceive. Think of a CAA record as a way to apply an additional layer of protection to your organization's online presence. If you've taken the time to obtain a certificate for your site, take the time to create a CAA record, too.» 

Enlaces externos editar

Obtenido de «https://es.wikipedia.org/w/index.php?title=Autorización_de_la_Autoridad_de_Certificación&oldid=157934152»