Más certificados falsos de Google: Y van tres veces en poco más de un año

miércoles, 25 de marzo de 2015

Adam Langley, el experto en SSL y criptografía residente de Google, anunciaba hace unos días que se han vuelto a emitir certificados para dominios pertenecientes a Google, pero que no son oficiales. Es necesario revocarlos y dar una explicación de cómo y por qué se han emitido, pues según se mire, puede quedarse en una anécdota o convertirse en un desastre. Pero en cualquier caso, siempre es un problema y acentúa la sospecha sobre el modelo de confianza que se arrastradesde hace tiempo. Veamos los detalles.

Qué ha pasado

Según Langley, la empresa egipcia MCS Holdings, que opera bajo la China Internet Network Information Center (CNNIC) estaba emitiendo estos certificados. Cualquiera puede emitir certificados para cualquier dominio, el problema es que en este caso, cualquier navegador va a confiar en estos en concreto porque ese certificado CNNIC viene incrustado como raíz de confianza en Windows y otros sistemas operativos. ¿Resultado? El navegador no se quejará si eres redirigido y se va a un  (por ejemplo) google.com falso.

Certificado de CNNIC entre los certificados raíz de confianza, último responsable de los certificados falsos

¿Seguro que no se quejará?

Bueno, esto no es del todo cierto. Aquí es donde empiezan a ser útiles las tecnologías de certificate pinning que están empezando a desarrollar todos los navegadores. Si la implementan, sí que se quejarían, porque recordarían que la cadena de confianza ha cambiado. En un sistema "interceptado", la cadena de confianza, en vez de apuntar al proveedor raíz de Google "habitual", ahora lo haría a la entidad China... y ante ese cambio, no dejaría pasar al usuario.

Y es bajo estas circunstancias donde el pinning como capa de seguridad adicional está demostrando ser más que útil. Porque este es un incidente muy parecido al que ocurrió en julio de 2014, también con dominios de Google y la la organización gubernamental National Informatics Centre (NIC) de India, que manejaba varias CA intermedias. También es muy similar a la situación que ocurrió con el gobierno francés en enero de 2014. De hecho, es la sexta vez desde 2011 que ocurre algo parecido y la tercera en poco más de un año.

¿Qué explicaciones se han dado?

En general, "las de siempre": se quería espiar a ciertas personas bajo control, y se dispuso un proxy intermedio. Pero se configuró mal. Cuando se pidió explicaciones al CNNIC, respondió que el acuerdo con MCS Holdings incluía simplemente creación de certificados para dominios generados por la propia MCS Holdings, o sea, el uso normal. Pero no se quedaron ahí. Al parecer han emitido certificados para otros dominios y configurado un proxy para espiar a los usuarios que pasen con él (no se sabe en qué entorno). Para colmo, la clave privada quedó en el proxy para generar nuevos dominios. Esto no está permitido. ¿Y si alguien tiene acceso a ese sistema? Las claves de generación se deben almacenar en hardware especial seguro. Pues no se aclara si a través de un robo, descuido, o si ha sido intencional, pero alguien con acceso a ese proxy ha emitido certificados para Google y probablemente otros dominios.

Certificado intermedio que emitió los certificados hoja falsos

En resumen, CNNIC confió en alguien que obviamente no estaba ni técnica ni "moralmente" capacitado para custodiar un certificado intermedio. Y ese será siempre el problema.

¿Es grave?

Detalle de uno de los certificados falsos emitidos

Es posible que esos certificados nunca hayan salido de su entorno. De lo contrario, ese sería el problema. Si han salido,en todo caso, ya hemos hablado que el pineo podría venir al rescate. Además, los certificados están revocados y Google ha emitido CRLSets actualizados para Chrome que actúan automáticamente sobre el navegador. Los CRLSets son un método "rápido" de revocación que utiliza Chrome, como ellos mismos dicen, para"situaciones de emergencia". Son un conjunto de certificados que se aglutinan de información de otros CRLs, se descargan de un servidor, y son procesados por Chrome. Aunque el método es absolutamente transparente, la gestión de qué certificados van en la lista es totalmente opaca. No se sabe con qué certificados lo actualizan (a menos que se averigüe por otro lado). Para saber qué conjunto de CRLSets está descargando Chrome en este momento, lo más cómodo es usar este programa, creado en el lenguaje Go.

También hay que tener en cuenta que el certificado intermedio caduca en pocos días, el 4 de abril. Por último, si eres paranoico, deja de confiar en CNNIC y mueve su certificado a la parte de "no confiable". Seguro que no lo notas.

Sergio de los Santos
ssantos@11paths.com

No hay comentarios:

Publicar un comentario