Probablemente, la primera vez que oyo hablar de Certificate Transparency (CT) hace algunos años cuando Google anunció que sería un nuevo requisito para todos los certificados SSL/TLS con validación ampliada (EV) emitidos tras el 1 de enero de 2015. Desde entonces, Google ha ampliado dicho requisito a todos los tipos de certificados SSL, y recientemente ha fijado abril de 2018 como fecha límite para su cumplimiento. Por tanto, Chrome no confiará en ningún certificado emitido tras dicha fecha que no reúna los requisitos de CT.
En GlobalSign, hemos estados trabajando intensamente en un segundo plano para asegurarnos de que todos nuestros certificados cumplen los requisitos de CT (validación ampliada (EV) desde 2015, validación de dominio (DV) desde agosto de 2016, y validación de organización (OV) a partir de octubre de 2017) y, de esta forma, garantizar que nuestros clientes están preparados para la fecha límite fijada por Google el año próximo.
Entretanto, animamos a todos aquellos que sigan preguntándose en qué consiste esto de CT a que se tomen este artículo como una especie de curso preparatorio.
Nota: en aras de una mayor claridad, utilizaremos el término SSL en lugar de TSL en todo el post (con una excepción), ya que su uso se encuentra más extendido. Para obtener más información acerca de este tema, le animamos a que lea nuestro post relacionado.
¿Qué es Certificate Transparency?
Certificate Transparency es un marco abierto para la supervisión de certificados SSL que los propietarios de dominios pueden utilizar para supervisar la emisión de certificados para sus dominios y detectar certificados emitidos erróneamente. Antes de la aparición de CT, no existía un método eficiente que le permitiese obtener una lista exhaustiva de los certificados emitidos para su dominio.
Sin embargo ahora, todos los certificados pasan a figurar en una lista pública que proporciona un mayor conocimiento y transparencia sobre el ecosistema de PKI de la Web en su conjunto. El proyecto Certificate Transparency persigue la consecución de tres objetivos:
- Imposibilitar (o, como mínimo, complicar en la mayor medida posible) que una CA emita un certificado SSL para un dominio sin que este sea visible para el propietario de dicho dominio.
- Proporcionar un sistema de auditoría y supervisión abierto que permita a cualquier propietario de dominio o CA determinar si sus certificados se han expedido por error o con fines malintencionados.
- Proteger a los usuarios frente a engaños perpetrados mediante certificados emitidos por error o con fines malintencionados.
A diferencia de lo que sucedía con el antiguo sistema –en el que los certificados malintencionados podían acampar a sus anchas sembrando el caos durante semanas o meses antes de descubrirse–, el marco de Certificate Transparency permite detectarlos de forma rápida y eficiente. La detección precoz de certificados sospechosos posibilita que tanto las CA como los propietarios de dominios reaccionen rápidamente y revoquen los certificados.
¿Cómo funciona Certificate Transparency?
Los dos principales componentes de CT son los registros y los monitores.
Los registros de CT conforman listas de certificados SSL emitidos. Estos registros son de "solo anexo", lo cual implica que las entradas no pueden eliminarse ni alterarse en forma alguna una vez que un certificado ha sido añadido un registro. Los certificados y precertificados (de los cuales hablaremos más detenidamente a continuación) pueden publicarse en registros de CT. Tras la recepción de un certificado o precertificado SSL válido, el registro devuelve un "sello de hora de certificado firmado" (SCT, por sus siglas en inglés) que acredita que el registro ha recibido la correspondiente solicitud. Los registros de CT emplean un mecanismo de cifrado denominado "árbol hash de Merkle" que evita que las entradas que se introducen en ellos se modifiquen o eliminen, de forma que una vez que han sido publicadas se vuelven permanentemente visibles para el público. Al procesar certificados SSL durante el establecimiento de una sesión TLS, los navegadores pueden solicitar SCT (que indiquen que el certificado ha sido revelado públicamente), la cual son una característica cada vez más importante en la PKI de la Web. Retomaremos este asunto más adelante.
Los monitores consultan los registros de CT y pueden descargar y almacenar certificados para elaborar informes sobre ellos en momentos posteriores. Su funcionamiento consiste en analizar los certificados y dividirlos en subcampos, y también permiten a los usuarios crear y ejecutar consultas sobre dichos certificados. Gracias a ello, pueden satisfacer las necesidades de aquellos propietarios de dominios interesados en recibir avisos sobre los certificados que se emiten para sus dominios o cuyo nombre coincide con el de su organización, o de los departamentos de cumplimiento que quieren garantizar la observación de los Requisitos Básicos del Foro de Navegadores y Autoridades de Certificación o del programa Root Trust. Sea como fuere, las utilidades que ofrecen los monitores son muchas y variadas. Algunos servicios terceros ya han publicado herramientas de monitor de CT o comenzado a incorporarlas a sus paquetes de soluciones existentes. Un ejemplo de ello es Facebook, que a finales del pasado año lanzó su propio servicio de monitor gratuito.
¿Qué son los precertificados?
Tal y como se mencionó anteriormente, los registros de CT aceptan precertificados y certificados SSL. Un precertificado contiene exactamente los mismos datos que el certificado "real", pero incluye además una extensión adicional que lo hace inutilizable. Dicha extensión se denomina "extensión venenosa" y se utiliza para distinguirlo del certificado "real". Puesto que todos los certificados emitidos por una CA deben contener números de serie únicos –y dado que tanto el certificado como el precertificado asociado poseen el mismo número de serie– es importante garantizar la invalidez o inutilizabilidad de uno de ellos, y esta es precisamente la razón de ser de dicha "extensión venenosa".
¿Para qué sirven los precertificados?
Aunque existen varios métodos para proporcionar SCT a los navegadores para su procesamiento, el más fiable y útil consiste en incluir dichos SCT en los certificados. Para poder obtener los SCT antes de la emisión (a fin de que puedan incluirse en el certificado), la CA debe crear un precertificado, publicarlo en registros de CT, recibir los SCT y, finalmente, incluirlos en el certificado final.
Antes de emitir un certificado, la CA tiene la posibilidad de enviar un precertificado a los registros de CT en señal de su intención de emitir el certificado "real" correspondiente. De hecho, la creación y publicación de certificados que no han sido correctamente validados o formateados se considera una emisión errónea en sí misma.
¿Quién puede enviar certificados a los registros de CT?
Aunque cualquiera puede enviar certificados a los registros de CT, solo las CA pueden remitir precertificados. Los motores de búsqueda y los operadores de sitios web también publican certificados en registros de CT de manera frecuente.
Determinados operadores de registros de CT únicamente aceptan certificados bajo determinadas raíces, de modo que no admiten certificados caducados, y todos los certificados (o precertificados) deben haberse desarrollado para utilizarse como certificados SSL (es decir, no es posible publicar certificados S/MIME o de firma de código en registros de CT).
Utilización de los SCT
Los SCT –que acreditan que un determinado certificado ha sido incluido en un registro– deben proporcionarse al navegador web para que este pueda evaluar correctamente el certificado SSL. El comportamiento y los requisitos exactos del navegador en relación con los SCT varían de unos casos a otros, pero este debe recibirlos invariablemente. Aunque en teoría el navegador podría publicar certificados SSL en los registros al crear una sesión TSL para obtener los SCT, el costo de dicho proceso resultaría prohibitivo. Existen tres métodos principales para entregar SCT a un navegador:
1. Extensión del certificado
El método más común y fiable para entregar los SCT a un navegador consiste en que la CA los incluya en el propio certificado. Puesto que el navegador necesita el certificado SSL para establecer la sesión TLS, de esta forma se garantiza que certificado está presente y puede utilizarse siempre para la lectura de los SCT.
No obstante, existe la posibilidad de que algunos propietarios de sitios web no quieran dar a conocer las URL de sus páginas antes de lanzarlas, en cuyo caso no estarían dispuestos a publicar anticipadamente sus certificados en registros de CT. Cuando se dan estas circunstancias, se puede optar por otra de las siguientes opciones de entrega.
2. Extensión TLS (SSL)
Una opción para la entrega de los SCT es que el operador del sitio web los proporcione al navegador dentro del protocolo TLS. En este modelo, el operador del sitio web/el servidor web envía el certificado a los registros de CT y obtiene los SCT. Los SCT se incluyen en el handshake TLS a través de una extensión TLS denominada "signed_certificate_timestamp". La "desventaja" de este método de entrega es que los operadores del servidor web deben modificar las configuraciones predeterminadas de sus servidores web, y no todos los servidores web son compatibles con esta opción.
3. Grapado de OCSP
Otra alternativa posible para la distribución de SCT entre los navegadores es utilizar mensajes OCSP, método para el que son necesarios dos elementos:
- El operador del sitio web debe utilizar un servidor web compatible con el grapado de OCSP y debe configurar dicho servidor para que solicite y descargue una respuesta OCSP válida. Si no se sigue este proceso, no existen garantías de que el navegador vaya a recibir el mensaje OCSP que contiene los SCT (puesto que muchos navegadores no son compatibles con este protocolo, este no constituye un mecanismo de entrega fiable a menos que la respuesta OCSP se incluya en el protocolo TLS).
- Además, la CA debe configurar su servicio OCSP para que sea compatible con el grapado de SCT. Una vez que se ha emitido el certificado, la CA lo publicará en varios registros y recibirá los SCT. Cuando se generen las respuestas OCSP, la CA adjuntará los SCT al mensaje OCSP y, posteriormente, el navegador dispondrá tanto del estado de revocación como de los SCT necesarios.
Aunque los métodos 2 y 3 requieren configuraciones específicas en los servidores, pueden ofrecer una mayor flexibilidad que la opción 1 anterior en caso de que los registros de certificados pierdan la confianza de los navegadores, ya que el operador del sitio web y la CA pueden reconfigurar dichos registros de una forma más dinámica.
La política de CT de Google
Para considerar que un certificado "reúne los requisitos de CT", Google exige que este figure en varios registros (como mínimo uno de Google y otro de otro servicio), dependiendo el número de SCT necesarios del periodo de validez del certificado. Para obtener más información, consulte el artículo Certificate Transparency in Chrome (Certificate Transparency en Chrome) de Google.
Puede consultar una lista de registros haciendo clic aquí.
Entonces, ¿qué necesita para reunir los requisitos de CT?
¡Ya conoce los principios básicos de CT! La mejor solución para asegurarse de que reúne los requisitos de CT es optar por una CA que añada SCT a los certificados emitidos de acuerdo con lo establecido en la política de CT de Google. La gran mayoría de certificados SSL de GlobalSign ya cumplen la política de Google, y dentro de poco todos los certificados de la marca lo habrán hecho cinco meses antes de la fecha límite de abril de 2018 fijada por Google.
Hasta el momento, Google ha sido el único navegador en establecer fechas límite para el cumplimento de los requisitos de CT. Aunque Mozilla también ha publicado un borrador de política, aún no ha anunciado ninguna fecha, y se prevé que sus requisitos serán compatibles con los de Google. Si lo desea, puede seguir el debate sobre esta cuestión aquí. Actualizaremos este post a la luz de cualquier anuncio futuro que se publique.
¿Tiene alguna pregunta sobre Certificate Transparency o sobre si sus certificados reúnen sus requisitos? Póngase en contacto con nosotros en cualquier momento; ¡estaremos encantados de ayudarle!
