Transparencia del certificado

Como no puedo comentar, al parecer, quiero aclarar un par de puntos.

• CT no requiere que todos los navegadores lo utilicen: existe una inmunidad de grupo, incluso si solo un navegador lo hace. Y, por cierto, la próxima versión de Chrome incluye compatibilidad con CT.

• Los servidores web no tienen que cambiar para admitir CT - CA pueden incluir los SCT en certificados emitidos. Algunas CA ya lo hacen y otras están trabajando en ello.

• CT no presenta una nueva entidad de confianza: los registros de CT prueban su propia operación correcta y cualquier desviación deja evidencia firmada de su infracción.

• El objetivo de CT es permitir que las partes interesadas (propietarios de dominios, investigadores, etc.) tengan una visibilidad completa de la PKI pública, de modo que sea fácil detectar la pérdida de los certificados. DigiNotar, por ejemplo, se habría descubierto en horas en lugar de meses en que se hubiera implementado CT.

Transparencia del certificado es un mecanismo de defensa heurística que no detecta certificados perdidos; en su lugar, se esfuerza por permitir una detección más rápida de certificados perdidos.

La idea central es la de Glasnost . Sucede que los ataques más exitosos se basan en una asimetría de información. Supongamos que quiero suplantar el servidor de Google. A través del engaño, el soborno, la incompetencia y / o la suerte, obtengo un certificado falso con "www.google.com" escrito en él. Luego lo usaré para un servidor falso que responde solo a mis víctimas objetivo (por ejemplo, todos los empleados de una empresa donde tengo algunas capacidades de administrador de sistemas). Mi interés, como atacante, es que nadie en el exterior notifique la existencia de ese certificado falso, en particular el propio Google. Si la gente de Google se da cuenta de este certificado que lleva su nombre, pero no es uno de los suyos, hablará inmediatamente con la CA emisora y solicitará la revocación inmediata. Se pueden esperar palabras duras.

La transparencia del certificado es un registro público de certificados. Este es un sistema por el cual un cliente SSL / TLS (un navegador web) puede estar configurado para aceptar un certificado solo si viene con una prueba verificable (el "Certificado firmado Marca de tiempo ") que el certificado se ha agregado a un registro donde será visible para todos, en particular el supuesto titular del certificado (Google, en mi ejemplo anterior). Esto no garantiza la detección; De hecho, el certificado es técnicamente completamente válido. Lo que CT garantiza es que cualquier certificado que vea el cliente está en vista simple y, por lo tanto, supuestamente , pronto se detectará si es fraudulento.

(Uno puede notar que los registros de CT incluyen marcas de tiempo firmadas por ... ¿una entidad de confianza? Como de costumbre, nunca se crea , simplemente se mueve alrededor de . )

La parte débil de la TC es que solo funciona si todos participan. CT ofrece mejoras reales de seguridad siempre y cuando los clientes SSL / TLS (es decir, los navegadores web) rechacen debidamente los certificados de servidor que no vienen con el SCT. Esto funciona solo si todas las siguientes afirmaciones son verdaderas:

• Todos los CA participan, por lo que se puede esperar que cada certificado "normal" esté en un registro de CT en algún momento.
• Todos los navegadores web admiten CT y rechazan los certificados que no están en el registro.
• Todos los servidores web son compatibles con CT y envían los objetos de marca de tiempo de certificado firmado a los navegadores con las extensiones SSL / TLS especificadas.

Estimo que las posibilidades de que este sistema complete su fase de arranque a menos del 10%.

PKI tiene dos elementos: los protocolos técnicos y los procedimientos que desarrollamos en torno a ellos.

En el ámbito técnico, las cosas son bastante claras: tiene un mecanismo que le permite decidir en qué confiar, cuándo y en qué condiciones y cómo comunicar (la mayoría) los cambios en ese sistema de confianza (CRL, OCSP, etc.).

Sin embargo, estos elementos técnicos no cubren los procedimientos: ¿cómo sabemos que se puede confiar en tal o cual raíz? Como usuario, generalmente porque confía (implícitamente) en la compañía que crea y mantiene su lista de CA raíz (Microsoft, Mozilla, Google, Apple, etc.). Como actor, porque revisa la forma en que estas raíces se han validado o las valida usted mismo (por ejemplo, si está utilizando raíces privadas, es importante realizar una investigación adecuada sobre cómo se gestionan).

Entonces, ¿cómo se sabe que una CA (intermedia o raíz) ha sido comprometida? Puede deberse a que detecta un uso indebido de esa CA (por ejemplo, encontrar un certificado en hoja firmado por un certificado que no tiene derecho a firmar claves) pero lo más probable es que siempre se deba a algún elemento de procedimiento: alguien lo hizo una auditoría y notó un uso inapropiado de dicho certificado.

En el caso específico que vinculó, el problema era realmente de esa naturaleza: el ANSSI hizo algo que realmente no debía hacer (emitir un certificado en nombre de una entidad a otra entidad no relacionada) y es por eso que El certificado fue revocado por Google y Mozilla.

Esto resalta el problema con todo el sistema público de PKI: hay demasiados actores que deben seguir demasiadas reglas que no son triviales de entender y aún menos fáciles de seguir. Y solo hace falta uno de los actores para que la seguridad de todo el sistema se desmorone: todo es increíblemente frágil.