Certificate Transparency: El qué, el cómo y el porqué

lunes, 7 de noviembre de 2016

Se acercan tiempos interesantes para el ecosistema TLS. Certificate Transparency será obligatorio en Chrome para los nuevos certificados (de cualquier tipo) emitidos a partir de octubre de 2017. Es una medida interesante y revolucionaria por varias razones. Principalmente, porque muchos administradores se preguntan a estas alturas qué es eso de Certificate Transparency y cómo les afecta, a menos de un año de que sea prácticamente obligatorio. Se ha hablado muy tibiamente del asunto porque hasta ahora no parecía encontrarse muy maduro el concepto (solo hay que darse un paseo por su lista pública de discusión para ver cuestiones que hasta hace poco se encontraban "suspendidas"). Vamos a intentar ahondar un poco.

El qué

Encontraréis varios artículos sobre Certificate Transparency, pero no demasiada información que permita entender todos sus aspectos prácticos. Certificate Transparency es un mecanismo ideado y apoyado desde Google para luchar contra el problema que más preocupa desde hace tiempo en el mundo web: el asunto de los certificados falsos o emitidos erróneamente en nombre de otro. Como ya se han dado varios casos graves de emisión de certificados fraudulentos por parte de autoridades comprometidas (o con políticas de creación "relajadas"), con Certificate Transparency se intenta atajar el problema. Se podía decir que es un método alternativo o complementario al Certificate Pinning (en todas sus variantes), a DANE, Convergence, TACK... pero con muchas más posibilidades que el resto de implantarse como estándar. En ningún momento desplaza a otras soluciones conocidas. No se emplaza por tanto dentro del conjunto global de soluciones de Certificate Pinning (EMET, CertPatrol, HPKP…)… es algo totalmente aparte.

Un ejemplo de bloqueo (por cierto, correspondiente a un fallo en Chrome) de cómo bloqueará Chrome las páginas

Hay ejemplos en los que aplicaría esta técnica para todos los gustos. De hecho, "sospechosamente", Google es quien ha alertado más y mejor en los últimos tiempos sobre certificados robados o creados para un uso sospechoso. El primero en enterarse. ¿Por qué? Porque Certificate Transparency ya lleva en pruebas desde hace algunos años, y porque para eso Chrome es suyo y les permite impulsar estándares a los que al resto no le queda más remedio que implementar. Tener un navegador propio con tanta cuota de mercado ha sido fundamental para impulsar tanto la política de mejora criptográfica de certificados, como Certificate Transparency, HPKP (donde va por delante del resto)… y muchos otros estándares que está liderando. Chrome les ha sido muy rentable. Por ejemplo, al hacer que Chrome bloquee los certificados no "declarados", consigue que el protocolo sea adoptado en buena parte, y que su navegador se encuentre siempre a la vanguardia. No hay duda de que tanto en medidas de seguridad incorporadas como en la implementación de protocolos de seguridad tanto activos como pasivos, es el navegador que marca el ritmo.

El cómo

¿Y qué aproximación ofrece Certificate Transparency para solucionar el problema de los certificados robados? Una muy sencilla en teoría. Como su propio nombre indica: se trata de ser absolutamente transparentes con la emisión de certificados. El principal problema de los certificados falsos emitidos es que el atacante podía usarlos sin que nadie más se diese cuenta y sin que saliesen de su entorno de acción. Podían montar una web fraudulenta con ese certificado falso, redirigir a la víctima, y nadie más tendría conocimiento del ataque.

Así se ve ahora la información sobre Certificate Transparency en Chrome.
En este caso chromium.org utiliza una extensión TLS


La idea por tanto es simple: hagamos que todos los certificados deban estar dados de alta en un gran escaparate. Que se muestren tal y como son y dejando bien claro para quién están emitidos en un servidor público y consultable. Un enorme repositorio de certificados al que llaman "logs". Hasta aquí, esto se parece mucho al proyecto PULSE que recorría internet buscando certificados. Pero es que si lo dejamos “hasta aquí” esto no ayudaría a combatir el fraude. Hay algo más. El navegador, consultará que todos los certificados que visita tengan una prueba de que están esa base de datos y si el certificado no demuestra estar publicado en ese escaparate universal, no dejará ver la página.

Esto deja al atacante en una posición compleja. Si quiere engañar a alguien, tiene dos opciones: o publica su certificado falso en el repositorio universal y aumentan muchísimo sus posibilidades de ser cazado, o bien no publica ese certificado falso y la víctima no caerá en la trampa porque el navegador se negará a entrar en la página. ¿Sencillo? Desde el punto de vista logístico parece simple y eficaz, desde el punto de vista práctico conlleva varios inconvenientes. Sobre todo… ¿cómo sabes si un certificado que se hace "público" es falso o no? ¿quién lo vigila? ¿cada cuánto? ¿cómo se sabe si ese escaparte contra el que comparas es falso o no? ¿quién se encarga de dar de alta los certificados? Son preguntas sobre las que se ha debatido bastante. Incluso alguna no está totalmente resuelta o no se sabe cómo será aplicada finalmente.

Por qué

¿Por qué se considera que ya está maduro el ecosistema como para que sea obligatorio? (siempre pensando en que obligatorio para Google, significa que Chrome lo impone y otros le siguen, como siempre). Lo cierto es que Certificate Transparency ya era obligatorio… pero solo para los certificados con Extended Validation emitidos desde el uno de enero de 2015, así que el siguiente paso era lógico. También parece que la infraestructura necesaria ya está madura. Para montar un sistema de Certificate Transparency, como se ha mencionado, hace falta una figura fundamental que se llama "logs". Certificate logs: Serán servidores que escuchan, graban y firman. Se les proporciona certificados recopilados por Google (nadie tiene una visión más amplia de Internet) y lo almacenan en una estructura de árbol Merkel. Esto significa que cada certificado es una hoja (en realidad, cada cadena válida de certificados), y la raíz se firma. Nada se borra nunca (están en modo "append-only"), todo queda grabado. Dan fe de todo lo que ha ocurrido criptográficamente, que no fue nunca modificado, y se comprometen a añadir cada certificado que se le ofrece. Es una especie de BlockChain, si queremos verlo así. Existen dos logs principales de Google por ahora, y otros que tienen menos información. Los "oficiales" se llaman "aviator" y "pilot", anque aquí se pueden consultar todos, además de los incluidos en Chrome actualmente.

Al certificado que se introduce en el árbol se le da un "Signed Certificate Timestamp" o SCT que viene a ser un puñado de bytes que significan que "quedas añadido al log, fue en este instante". En realidad se añade un poco después (el tiempo que tardar el árbol Merkel en "reconfigurarse" y refirmar su raíz), y el SCT viene a ser una "promesa" de que se añade en un intervalo de tiempo, pero a efectos prácticos es un ticket que garantiza haber entrado en el log en un momento dado. Este ticket debe ir con el certificado todo el tiempo, para que allá donde se presente el certificado (cada vez que se visita una web) el navegador o cliente pueda "echarle un ojo" y comprobar que todo está correcto.
La lista de logs a consultar están en el navegador. Por ahora Google tiene varios montados y existen otros (de CAs principalmente) que consulta Chrome, pero cualquiera podría montar alguno… el asunto sería si te puedes fiar de ellos. Los logs pueden ser operados por cualquiera que lo desee. Siempre que mantenga su "reputación" será tan válido como los oficiales de Google. Se opera con ellos gracias a una API a través GET y POST, y no tienen por qué interactuar ni replicarse entre ellos. Cualquiera puede enviar certificados a los servidores de logs, pero se supone que serán las CA las que los "registren". Ojo, no se consulta a los logs antes cada certificado para ver si ha sido incrustado, sino que se aprovecha su SCT, como si de un OCSP stapling se tratase.

En el caso de ElevenPaths, el SCT está en el propio certificado incrustado


Hay detalles más técnicos "escabrosos", como por ejemplo dónde estará físicamente ese SCT que acompaña al certificado todo el rato y que es su garantía de estar expuesto en el escaparte que suponen los logs. Podrá hacerlo de tres formas diferentes: como una extensión X.509v3. Quizás esto sea lo más cómodo para los certificados recién creados. La extensión elegida (OID 1.3.6.1.4.1.11129.2.4.3 para el precertificado y 1.3.6.1.4.1.11129.2.4.2 para la prueba final) e implica "incrustarlo" en el momento de la creación y esto implica a su vez otras complicaciones adicionales en las que no entraremos pero que se apoyarán en el concepto de "precertificados"; Otra fórmula sería añadirlo a través de una extensión del proprio protocolo TLS (0x0012) aunque esto implica que el dueño del servidor debe enviar el SCT a quien le visite desde las extensiones TLS del protocolo y por tanto, debe reconfigurar su servidor… algo quizás engorroso; La última opción es reaprovechar una respuesta OCSP (con OID 1.3.6.1.4.1.11129.2.4.5) para incrustar ahí el SCT, pero teniendo en cuenta que OCSP ya tiene sus propios problemas, quizás sea la opción menos elegida.

Sea como sea, el navegador consultará gracias al SCT si el certificado se encuentra en los logs. El RFC recomienda que se consulte en al menos tres logs diferentes.

De las tres posibilidades, la red muestra que este sitio tiene el SCT incrustado en el navegador
 
¿Quién vigila al vigilante?

Otra figura dentro del ecosistema de Certificate Transparency podrán ser los monitores de esos servidores. Serán los policías de los logs. Se conectan para ver las nuevas entradas y comprobar la validez criptográfica. Las CA estarán interesadas sin duda en funcionar como monitores… pero cualquiera podría hacerlo. A la última figura del esquema la llaman "Auditores". Típicamente serán los navegadores. Verificarán si un certificado concreto aparece en un log, y actuarán en consecuencia. Pueden pensar que el no aparecer es ya de por sí sospechoso (esto es lo que harán a partir de octubre de 2017). También deben valorar que el log que consultan es de fiar y no se ha modificado nada en ellos, verificando su consistencia criptográfica. Estos serán los chivatos que alertarán cuando un certificado tenga indicios de estar haciendo algo raro.

El navegador aceptando la respuesta SCT de un certificado

En resumen

Esto vuelve a tener sus puntos ciegos. Un atacante puede enviar a los logs un certificado falso y obtener su SCT. Hemos hablado de que existe un tiempo medio en el que los logs recomponen su árbol con los nuevos logs y firman su raíz (se le llama MMD). Si los clientes no rechazan los certificados con un SCT pero que aún no han sido incluidos oficialmente, si aceptan ese tiempo de gracia (que suele ser 24 horas), el atacante tiene una oportunidad de actuar. A partir de que se incluya formalmente en el árbol, se supone que pueden ser públicamente auditados y el atacante sería cazado… pero de nuevo… ¿cuánto puede tardar en auditarse? Si no hay nadie mirando, todo el tiempo que sea necesario, por lo que la potencial ventana de ataque se agranda en mínimo 24 horas y máximo el tiempo de auditoría.

Aunque ya fuese obligatorio para los EV, pocos esperaban que estuviera listo para el resto de certificados en octubre de 2017. Se presentan nuevas oportunidades donde un atacante podrá montar logs falsos, insertar certificados no válidos, se detectarán sin duda fallos en el protocolo, situaciones no previstas, denegaciones de servicio... Sin contar con que, una vez detectado un mal uso gracias a Certificate Transparency, los mecanimos de revocación serán los mismos con sus mismos problemas... CRL, OCSP, CRLSets... tiempos interesantes, como anunciábamos al principio.

Obviamente esto obliga al resto de navegadores a reaccionar. Chrome ha sido el primero, pero probablemente el resto deberán ponerse al día. Esta iniciativa no está solo apoyada e impulsada por Chrome, sino por el CA/Browser Forum. No sería raro ver a Firefox usando los logs de Chrome, pero Edge/Internet Explorer quizás no lo tengan tan claro y monten sus propios logs. Por ahora no mantienen ninguno. Aunque teniendo en cuenta que todavía Microsoft no utiliza ni implementa HPKP, tendrán tiempo para pensárselo.

Por último, solo un apunte: es probable que pronto tengamos una cabecera HTTP relacionada con Certificate Transparency. Lo va a proponer Google para quien quiera optar a estar en Certificarte Transparency incluso antes de octubre de 2017.

Sergio de los Santos
ssantos@11paths.com

No hay comentarios:

Publicar un comentario