Confía pero verifica: cuando los CAs no son suficientes

Hemos vuelto a experimentar otro caso de una Autoridad de Certificación raíz (CA a partir de ahora) que pierde control de sus propios certificados. Y una vez más, hemos esperado que la CA o el navegador hagan algo al respecto. Todo este lío se origina, nuevamente, en un problema técnico y de gobernanza. Primero, sólo la misma CA que emitió el certificado puede revocarlo posteriormente. Segundo, aunque los navegadores web implementan varias técnicas para verificar el estado de revocación de un certificado, los errores en el procedimiento no suelen considerarse como fallas graves.

Enlace al CRL de la CA.

De estos, la primera técnica (la más antigua) implica que la CA cree una Lista de Revocación de Certificados (CRL, por sus siglas en inglés). Esto requiere que el usuario consulte la CRL regularmente, descargue la lista completa (una revisión de la RFC permitida para actualizaciones delta), y la use para verificar el estado de revocación de un certificado. Debido a que, por política predeterminada, las CRLs pueden tener una antigüedad de hasta siete días, resulta obvio que un ciberdelincuente tiene la posibilidad de usar un certificado comprometido. Para empeorar las cosas, los CAs suelen propagar CRLs a través del protocolo HTTP, lo que significa que es posible repetir los ataques. Además, incluso si la regla dicta lo contrario, los navegadores web suelen considerar que la descarga fallida de una CRL actualizada es un error menor, lo que significa que la conexión no termina (lo que hace que todo el proceso de verificación sea tan útil como un cinturón de seguridad que falla en el impacto.

Enlace al respondedor OCSP del CA

El OCSP (Online Certificate Status Protocol) intenta arreglar esta falla. Permite que le proceso de verificación se realice online, lo que a su vez permite que el cliente verifique la validez de un certificado cuando se establece una conexión. En lugar de descargar largas listas CRL, el cliente tiene la posibilidad de solicitar directamente el CA. Sin embargo, esto revela al CA qué certificado está tratando de verificar el cliente (lo que fácilmente puede ser un tema delicado de privacidad para algunos usuarios). Asimismo, ya que se sigue usando el HTTP, en alguna medida sigue siendo posible repetir los ataques (es posible incluir un nonce o semilla en la petición pero aún no es compatible con todas las implementaciones). En conclusión, el protocolo puede ser también bastante caro ya que muchos clientes ahora buscan el mismo CA para todos los certificados que ha emitido la CA (como en este ejemplo).

Respuesta OCSP enganchado a la respuesta del servidor

Este OCSP enganchado (verifica aquí si es compatible con tu navegador) es el último intento para mejorar el proceso de revocación de un certificado. Para responder a las cuestiones de privacidad y mejora, permite que el mismo servidor provea al cliente una declaración verificada de la validez del certificado. El cliente ya no vuelve a contactar con la CA, y en lugar de ello, el servidor (poseedor del certificado) solicita a la CA una respuesta OCSP con marca de tiempo, que se “engancha” a la conexión TLS iniciada por el cliente. El único problema es que el protocolo permite una sola respuesta OCSP, lo que hace que esta solución sea incompatible con las páginas web que usan diferentes certificados (para diferentes recursos).

Estos tres protocolos suelen cooperar en la recuperación de fallos. El cliente comienza solicitando una ”petición de estado de certificado”. Si el servidor no responde, el cliente busca el CA. Nuevamente, si el CA no responde, recurre al CRL. Hay que mencionar que esto se trata sólo de una mejor práctica y que ninguna regla indica cuál debe ser el comportamiento adecuado en caso de una falla (distintos navegadores adoptan diferentes recursos, como se menciona aquí). Lo terrible es que durante todo el proceso nunca se le informa al cliente. Es decir, el cliente puede estar usando una CRL de siete días de antigüedad, pero sigue percibiendo el mismo nivel de seguridad que le ofrece un enganchado OCSP mucho más avanzado.

En base a lo que hemos tratado, el sentido común dicta que la elaboración una regla adecuada, la actualización de todas las implementaciones, y la reconsideración de las fallas graves de alguna manera mitigarían el riesgo que conllevan los certificados TLS comprometidos. Por desgracia, esto no sucede. El problema central que ninguno de los protocolos considera es que, en algunas circunstancias, debemos dejar de confiar, aunque sea temporalmente, en la CA en su conjunto (y no sólo en un certificado). Esto puede darse en dos escenarios relacionados:

• Un certificado está comprometido, pero la CA no lo ha revocado todavía.
• La CA en su conjunto está comprometida, entonces hay que revocar la confianza en todos los certificados emitidos.

Por desgracia, además de un discreto intento conocido como Authority Revocation List, no existe ningún protocolo que revoque la confianza en una CA. En realidad, todo el asunto está delegado por completo a la aplicación (o sistema operativo) designada para configurar y actualizar el llavero de certificados CA confiables. El escenario se complica aún más si consideramos que estas actualizaciones no dependen de mecanismos de distribución fuera de banda (como el protocolo OCSP), sino que requieren que el usuario actualice toda la aplicación (mira las mejores prácticas de la NSA en este tema para tener una idea general). En todos los recientes fiascos de CAs, los usuarios quedaron desprotegidos por varias semanas a causa de esta limitación. Además, aunque los sistemas operativos modernos ofrecen tiendas centralizadas de certificados, cada aplicación (con algunas notables excepciones como Google Chrome) suele depender de su propia tienda de certificados. El escenario resultante es casi surrealista: si un CA está comprometido, el usuario no está seguro hasta que los fabricantes de la aplicación publiquen las respectivas actualizaciones, que deben distribuirse e instalarse en el equipo del usuario.

Tiendas de certificados de Mozilla Firefox y Google Chrome

Por desgracia, todavía no existe una solución práctica. Nos han dicho que estos incidentes son tan inusuales (muy publicitados, pero inusuales), que no se justifica remplazar el sistema actual, tal como lo conocemos. Personalmente, no estoy del todo de acuerdo con esto, ya que considero que son posibles algunas actualizaciones incrementales, especialmente en la fase de mitigación posterior a los incidentes. En un futuro artículo analizaremos una solución tentativa y el coste de su instalación. ¡Hasta entonces!