Sí, ha vuelto a suceder: Otra vez una CA ha vuelto a saltar a la luz pública por haber protagonizado un mini escándalo de certificados fraudulentos.
En este caso, la protagonista ha sido 'TurkTrust' entidad de certificación Turca que, tal y como reflejamos en otro artículo donde se analizó en manos de quién está la seguridad, es junto a ANCE las dos únicas CAs cuyo origen es un país musulmán.
En este caso el problema no ha sido un hackeo (como en el caso comodo y diginotar), mas bien un uso indebido de dicha CA.
Se puede encontrar en internet mucha información del asunto, pero tal vez la fuente mas expeditiva sea nakedsecurity donde explican lo sucedido realmente,
Resumido queda en esto:
1- A mitad de 2011, en teoría debido a un error interno y supuestamente no malintencionado, TurkTrust emitió dos certificados de CA subordinada en vez de un certificado normal a dos clientes (nótese que un certificado de CA subordinada permite, a la postre, crear certificados válidos para identificar hosts en internet sin control alguno)
2- Uno de esos certificados 'erróneos' fue revocado porque el cliente al que se le dio informó del error (es extraño que a raíz de ese error no se investigase si existían más certificados así). El otro certificado que se emitió a EGO (autoridad gubernamental del transporte) siguió activo.
3- Alguna mente iluminada en EGO que se dio cuenta del error (ellos dicen que no, pero yo no me lo creo) instaló este certificado mágico en un dispositivo CheckPoint que, entre otras capacidades, tiene la habilidad de interceptar tráfico SSL mediante MitM creando certificados al vuelo a partir de un certificado CA (el cómo usan estos dispositivos las organizaciones que no tienen uno de esos certificados mágicos da para otro post y ahora mismo como explicación, sobra).
4- A finales de 2012, la gente de EGO creó un certificado 'wildcard' para *.google.com
5- Un usuario de la red de EGO estaba empleando Chrome como navegador y Chrome, resulta que usa Public key pinning que, muy groso modo, significa que Chrome sabe de que CAs puede esperar certificados para sitios como www.google.com y de cuales no.
6- A partir de ahí saltó la chispa que prendió todo este escándalo.
En mi humilde opinión, la historia de los certificados 'erróneos' que terminan en un dispositivo CheckPoint para interceptar tráfico SSL me suena excesivamente obvia como para creerme la explicación oficial de TurkTrust en la que tratan de explicar todo esto como un cúmulo de infortunios.
A partir de esto, me gustaría reflexionar sobre varias cosas. Mucha gente, a raíz de estos escándalos están poniendo en tela de juicio el modelo tradicional PKI / CAs.
Tal vez el más notable intento sea Convergence, que propone una ruptura con el modelo tradicional para cambiarlo por otro.
A mi modo de ver, pasado un tiempo de su lanzamiento, opino que no es el camino, el modelo tradicional de las CAs no es un modelo 'malo', simplemente el tiempo lo ha 'prostituido', se han admitido un desproporcionado número de CAs de confianza, los procesos de auditoría son excesivamente laxos y al final se confía más de la cuenta.
Frente a eso, hay otras propuestas que proponen mejorar el sistema, Google apuesta por el pinning y también proponen 'Certificate Transparency [PDF]' que, básicamente es un gran log público donde cada CA debe registrar cada certificado que emita, de esa forma si tu eres el dueño de ejemplo.com puedes consultar periódicamente que certificados para tus dominios hay en circulación.
Mi pequeña aportación a todo esto fue 'SSLCop' que tuve el placer de presentar en la pasada rootedcon, y que pretende ser una forma de reducir el número de CAs en las que confía tu navegador eliminado CAs por procedencia geográfica asumiendo, por ejemplo, que tu, si no eres Turco, no necesitas confiar en las CAs de ese país
0 comments :
Publicar un comentario