Certificate Transparency se retrasa hasta abril, y con razón

lunes, 23 de octubre de 2017

Chrome lidera la iniciativa, pero ¿está siendo demasiado ambicioso? Hemos hablado en más de una ocasión de que en octubre de 2017 sería el momento en el que Chrome forzaría la adopción de Certificate Transparency en los nuevos certificados emitidos. Pero ni siquiera el propio Chrome ha podido adoptar a tiempo la tecnología que, según la fuerza de impulso que ha tomado, terminará imponiéndose. Pero desde luego no ahora. Veremos en abril y reflexionemos mientras sobre las razones.

Mensaje de error (no muy popular aún)
para cuando la comprobación del CT falle en Chrome


El anuncio se hizo en octubre de 2016, y se dio un año de plazo para que los certificados fueran emitidos con su SCT, o sea, con el añadido de saberse en el "gran escaparate" de Certificate Transparency. Luego Chrome, se entiende, iría degradando poco a poco la visibilidad de los certificados visitados desde su navegador si no disponían de ese SCT. Se acercaba octubre de 2017 y se echaron atrás... o movieron el problema hacia adelante.

Errores esporádicos en la validación del SCT en Chrome
han causado ya algunos "problemas" a bancos

En febrero se realizó una conferencia sobre CT. 55 personas que representaban a los logs, CDN, CAs, académicos, PKIs gubernamentales y navegadores. Prácticamente todo el ecosistema representado en medio centenar de personas. Se supone que de ahí salió reforzada la idea... y así lo intentan describir, con reservas, aunque en positivo ("...han avanzado pero..."). Sin embargo la realidad es que los navegadores, el RFC, y los operadores de logs tienen un peso muy específico, y todo debe funcionar como un reloj sincronizado. Google no puede imponerse por sí mismo y tirar del carro solo. Y parece que nadie ha hecho sus deberes a tiempo.

Navegadores

Chrome lo hace bien, qué menos. Está perfectamente preparado... aunque no del todo en todos los aspectos. Como presentamos en la Rooted Valencia, si miramos el código todavía vemos situaciones cuando menos... extrañas. Sin ahondar demasiado, la implementación de Chrome, si nos fijamos, tampoco era la mejor hasta el momento (aunque sea en código abierto, no es tan sencillo entender los flujos sin un estudio que requeriría muchísimo más tiempo). Algunas de las fórmulas de Chrome despiertan algunas dudas. Por ejemplo, por un lado parece que la lista de logs de confianza están "incrustados" en el propio código. Por el otro, existe un código como "de prueba" con logs dinámicos a los que está constantemente comprobando su cabecera (su integridad).




Pero no se sabe muy bien su función... porque encontramos que realmente, da igual el resultado. De hecho, si la ruta de lo que tiene que comprobar ni siquiera existe o está vacía, el proceso se omite y no comprobación más allá.




Parece que está en modo "Log", como si algo de código se hubiera quedado ahí "olvidado" en pruebas.

Firefox todavía no ha podido implementar nada. De hecho, hemos realizado en ElevenPaths un plugin antes que la propia Firefox. No hemos abarcado todas las posibilidades que cubre el viaje del SCT, pero es más de lo que han implementado oficialmente.

Internet Explorer/Edge ni está ni se le espera en este cuadro. Todavía no ha implementado el HPKP... y quizás incluso sea buena idea, porque está agonizando si no espabila.

RFCs

El RFC de CT es un draft, pero está en la versión 2 desde principios de junio. Lo curioso es que hay versiones de las API de la versión 2 que no usa literalmente, nadie todavía. Es más, uno de los mayores problemas de CT, que podría ser la revelación de dominios internos, solo fue abordada a través de un RFC que tiene una versión de marzo y otra de julio de este año, por lo que aún necesita bastante rodaje.  Existen otros problemas:

Se introdujo una cabecera, Expect-CT, simplemente para ayudar a saber si se estaba preparado para este "deadline" de octubre. Así, quien pensara emitir certificados con el SCT, podría al menos tener algo de feedback del navegador (solo Chrome, por supuesto), sobre si hubiera ido todo bien o no, o sea, si el SCT validaba bien en los logs correspondientes. Esa cabecera no se incluyó en Chrome hasta mediados de agosto en su versión 61... Un poco tarde para tratarse de una cabeceras de pruebas hacia una situación que ocurriría en octubre. Por supuesto el resto de navegadores no la han implementado aún.

Logs

Evolución de la cantidad de certificados en cada uno de los logs conocidos

La gestión de logs es un poco caótica. Hay logs congelados, con "tirones" donde durante un tiempo se almacenan muchos certificados, otras veces se congelan... La CA Let’s Encrypt, por sus peculiaridades, sigue una dinámica diferente...

Tampoco está muy estructurada la salida de los propios logs o estandarizado quién confía en quién. Ya estudiamos eso en un informe anterior. Pero si miramos la salida (con la versión 1 de las APIs, nadie usa la 2), de algunos, vemos como por ejemplo, ni siquiera el Log del gobierno chino confía en los propios logs de Google.

Para el CNIC chino, el certificado CA de Google (autofirmado) no es de confianza...

Otra curiosidad, es que Chrome exige unos "uptime" de los logs muy altos como una especie de demostración de compromiso por parte de los que los mantienen. Pero a veces no todos pueden cumplir (en rojo en la imagen). Aun así se les mantiene en el código por ahora.

Cert.ch recopila información sobre los logs, cuándo se introdujeron, uptime...







Conclusión

Con implementaciones que no llegan, o cabeceras que se adoptan con tan poco margen, RFCs que se comienzan este mismo año... ¿Cómo se pretendía hacer obligatorio el uso de SCTs en octubre de 2017? Podría haber sido, pero la realidad ha pesado más. Es necesario más tiempo. En concreto, han pensado que 6 meses más. ¿Será suficiente? Personalmente, no pensamos que Certificate Transparency goce de mala salud (al menos no tan mala como HPKP), solo que Google ha sido excesivamente ambicioso con la propuesta. Poner de acuerdo a tantos actores es complicado, y más aún en entorno tan crítico como el de la seguridad TLS.


Sergio de los Santos
Innovación y laboratorio
ssantos@11paths.com

Jose Torres
Innovación y laboratorio
jose.torres@11paths.com

No hay comentarios:

Publicar un comentario