¿Cómo trata (o tratará) Certificate Transparency la privacidad de los dominios?… Mal

Primero fue octubre de 2017 y después abril de 2018, aunque ahora parece que va en serio. En breves, Certificate Transparency será obligatorio en Chrome. ¿Están preparados los actores? Respuesta corta: no. Y algo muy importante no resuelto es qué ocurre con la privacidad de los dominios. Tema espinoso que intentamos aclarar.

Antes de empezar, recordad qué es eso de Certificate Transparency. Ya era improbable que estuvieran listos todos los “actores” para octubre. Lo confirmó la propia Google con la “patada hacia adelante” anunciada hasta abril de 2018. En la Rooted de Valencia de 2017, presentamos una investigación que analizaban todos estos aspectos que parecían justificar el “retraso”. Y no solo eso, en esa investigación, conseguimos pasar desapercibidos para ciertos monitores de Certificate Transparency y “colarnos” en dos logs de confianza. Pero eso no era ni siquiera lo más relevante. Cabeceras como “Expect-CT” diseñadas para prepararse para octubre de 2017 y “entrenar” los certificados y escenarios, no fueron realmente puestas en producción hasta septiembre de ese mismo año… No es mucho margen cuando se supone que servían de entrenamiento para un evento que se lanzaría en octubre, ¿verdad? Igualmente, el código relativo a Certificate Transparency en Chrome parecía estar en desarrollo, con líneas que parecían más a una zona de DEBUG y funciones que siempre devuelven que todo está bien en las cabezas de los logs…

Implementación actual en Chrome sobre algunos aspectos de Certificate Transparency que no ofrece demasiada confianza sobre su madurez

También quizás resulte curioso saber que existe una versión 2 de la API Certificate Transparency desde hace muchísimo tiempo… que nadie usa todavía, y CT saldrá a producción apoyado principalmente en la primera versión que ya se detectó como obviamente mejorable. Lo curioso es que, hoy por hoy, a pocos días de pasar a producción… siguen así. Quizás no sean vitales, y no impedirán que el funcionamiento sea correcto, pero desde luego no ofrecen justo lo que pretenden: una sólida confianza.

En el informe que recientemente hemos redactado, se demuestra que se puede mejorar hasta un 10% la fase de reconocimiento de un pentesting gracias a Certificate Transparency. Quizás este no sea el único problema, sino que también se desvelen dominios que no se desean. Nadie espera que sus subdominios privados se almacenen en los logs. Esto no tiene una fácil solución, ni siquiera una fácil explicación de todas las variantes posibles, por ello iremos paso a paso.

Certificate Transparency (CT) se basa en probar que el certificado esté incluido (en principio, parece que tres serían suficientes, aunque luego descendieron a dos) en logs de confianza. El navegador deberá hacer su trabajo a partir de abril y no dejar pasar a los certificados que no se encuentren en los logs. Con los certificados con subdominios privados que provengan de CAs privadas incrustadas a mano en el sistema operativo, no habrá excesivo problema. CT no aplica sobre ellas (para estar en los logs, la cadena debe validar sobre las CA de confianza típicas que puede contener y elegir el log). Pero para los dominios “secretos” que vengan de CAs públicas, existe un doble aspecto de privacidad a tener en cuenta.

• Para el usuario, porque el navegador, para “chivarse” de algún problema en CT, podría enviar el SCT (la prueba de inclusión, falsa o no) del certificado al propio “fabricante” del navegador para que compruebe si algo falla en sus logs. O sea, se podría enviar a terceros la información de por dónde navega el usuario. Esto ya ocurría con HPKP y su “report-uri” pero tampoco es que le dieran demasiada importancia.

• Para el dueño de los certificados, que acaba publicitando o necesitando incluir en un log dominios con, potencialmente, subdominios que no quiere que sean conocidos.

Para paliar estos problemas, se han propuesto soluciones de protocolos sobre las especificaciones actuales de CT, que ni siquiera han sido implementadas por ahora.

Tema que todo el mundo se pregunta. En noviembre de 2017 todavía se andaba dando vueltas al asunto en discusiones y recontra-argumentaciones públicas de todos los involucrados. Un debate “apasionante” que ha llevado horas y horas de discusión… y todavía sigue sin estar resuelto. De hecho, solo parece existir un draft que aborde el problema, además del RFC, (una tiempo, estuvieron estas ideas incluidas pero se separaron en un borrador aparte). El draft ha expirado a mediados de 2017, y la discusión, como mencionábamos arriba, sigue viva.

Las grandes CA ya se planteaban el problema en 2016… ya ofrecían la posibilidad (la más simple de todas) de no incluir por defecto en los logs los subdominios que el dueño no deseara. Pero, por aquel entonces, se temía incluso que Chrome diera por erróneos sus certificados (así lo indicaron públicamente). Desde entonces, el asunto tampoco ha avanzado tanto. De parte de Mozilla, lo más reciente que encontramos es este draft analizando pros y contras de cada solución, pero sin llegar a ofrecer ninguna solución concreta o dirección.

En cualquier caso, repasemos desde el punto de vista técnico las propuestas “oficiales” de la IETF para lidiar con la privacidad de los subdominios:

• Usar wildcard *.ejemplo.com. Obviamente, no es la mejor solución, nunca lo ha sido pero ahora impide el uso de dominios de tercer nivel, por ejemplo, y no sería válido (no lo son por definición) para certificados EV.
• Revivir y reutilizar un viejo truco que pocos usan: las CA intermedias “limitadas”. Se ha propuesto añadir a este truco un “flag” OID 1.3.101.76 que indique que los certificados emitidos por esta CA intermedia tienen permitido no estar en logs. Para listar dentro del certificado de la CA intermedia cuáles están exentos, además del flag, se utilizarían las extensiones X.509 
  permittedSubtrees y excludedSubtrees. Funcionan como una especie de wildcards más específicos, con los que se crea una serie de reglas blancas y negras que hay que satisfacer para indicar qué subdominios de un dominio podrían llegar a estar exentos de Certificate Transparency, y ser emitidos por esa subCA. En principio, se usaban antes de CT para limitar el poder de una subCA pero con el flag mencionado se ha pensado que pueden solucionar esto. Por supuesto, aunque buena idea, está lejísimos de ser soportada por los navegadores. Por si tenéis curiosidad, aquí está el código Python para realizar pruebas de estas cabeceras en el motor de Chronium. Esto tiene más complejidad de la que parece ya que luego, esta modificación en los certificados debe venir acompañada de cómo los navegadores entienden y notifican a los logs de esta exención.
• Ocultar directamente los subodminios en los precertificados. Como sabéis, CT incluye el “precertificado” como método de inclusión del SCT en la petición de firma. Durante este proceso, se podría crear una extensión específica para X.509 que sea redactedSubjectAltName y que tendrá “ofuscado” los dominios. Se trata de “hashear” ciertos dominios e incrustarlos en el certificado y esto es lo que quedaría en los logs. En el certificado real, habría un subjectAltName con el mismo número de dominios en claro, y el cliente (navegador) podría comprobar el hash de cada uno. Por cierto, estaría codificado en base32 y la función de hash está el aire aún, lo que podría ser inseguro por la facilidad que podría llevar un ataque por diccionario, fuerza bruta o por la posibilidad de deducir dominios (suelen tener pocas letras). ¿Os resulta complejo todo esto? En la propia especificación aclaran que todo el ecosistema podría dañarse si se usa mucho esta opción.

Certificado de prueba creado por nosotros mismos con las extensiones (poco comunes) de organizaciones con restricciones

En el aspecto más mundano, leer a fondo no solo esta entrada de blog, sino todas sus referencias para ver cuál de las múltiples posibilidades se ajusta a cada necesidad. Después, escoger alguna de estas estrategias:

• Implementar CAs propias
• Usar CAs públicas pero confiar en que no se envíen los certificados con dominios privados a los logs, por ejemplo desactivando en los empleados la función
• Usar política de wildcards…
• Armarte de esperanza y/o palomitas y esperar

El problema que subyace de fondo, realmente, es que al ocultar subdominios sensibles se pretende y espera en realidad crear una capa de “ocultación” en un sistema transparente por definición. Ahí está la controversia y el problema fundamental del asunto, y precisamente, por tratarse de un problema “radical” y opuesto a la solución inicial, es difícil de solucionar.

A todo esto, ya podréis usar nuestro plugin para FireFox (puesto que aunque están en ello, no llegarán a tiempo) que permite comprobar el SCT incrustado en los dominios.