Nuevos certificados TLS comprometidos

Recientemente se ha vuelto a experimentar un problema importante con los certificados de seguridad en la web. Se trata de datos sensibles que indican a nuestro ordenador con qué servidores es seguro conectarse y con cuáles no.

Sergio Méndez Galindo
Sergio Méndez Galindo

21 de febrero · 694 palabras

Compartir: 𝕏 Twitter 📱 WhatsApp
Nuevos certificados TLS comprometidos - Seguridad Informática

La compañía generadora de certificados (CA) ha perdido el control de uno de sus certificados, lo que ha creado una brecha en la seguridad en internet. Este problema tiene dos tipos de problemas: uno es administrativo y el otro es técnico.

Solo la compañía que emitió el certificado puede retirarle validez posteriormente. Aunque los navegadores web tienen técnicas para verificar el estado de revocación del certificado, los errores generalmente no se consideran graves.

Una de las técnicas más antiguas es que la CA cree una lista de revocación de certificados (CRL), lo que requiere que el usuario cuestione el CRL y descargue la lista completa para verificar el estado de revocación del certificado.

El OCSP o Protocolo de estado de certificación en línea intenta solucionar este problema permitiendo que el proceso de verificación sea ejecutado en línea. Sin embargo, aún existen algunos problemas de privacidad y seguridad con este método.

En resumen, la pérdida de control de los certificados sigue siendo un problema grave de seguridad en línea.

La compañía responsable del certificado o Certificate Authority (en adelante CA) ha perdido el control de uno de sus certificados. De nuevo, hemos tenido que esperar a que la compañía que brinda el certificado o bien el navegador tape la brecha provocada en la seguridad. Este problema responde, otra vez, a dos tipos de problemas: uno de administración y otro técnico. Para empezar, solamente la compañía que ha lanzado un certificado puede revocarlo (retirarle validez) posteriormente. Segundo, aunque los navegadores web implementan algunas técnicas para comprobar el estado de revocación del certificado, los errores provocados en este proceso de comprobación generalmente no se consideran graves o "de primer nivel".

De estas técnicas, la primera (y más antigua) implica que la CA cree un CRL o Certificate Revocation List. Esto requiere que el usuario cuestione al CRL a intervalos regulares, descargue la lista completa y la emplee para verificar el estado de revocación del certificado en uso. Partiendo de la base de que, por defecto, las CRL descargadas pueden estar desfasadas hasta en 7 días (máximo período de vigencia), está claro que existe una posibilidad de que un atacante emplee contra nosotros un certificado vulnerado.

El OCSP u Online Certificate Status Protocol intenta arreglar este problema en particular. Permite que el proceso de verificación sea ejecutado online permitiendo al "cliente" comprobar la validez de un certificado cuando se establece una conexión. En lugar de recibir interminables listas CRL, el cliente tiene la posibilidad de consultar al CA directamente. Esto, sin embargo, revela al CA qué certificado en concreto está intentando ser verificado por el cliente (lo cual puede desembocar en un problema de privacidad para algunos usuarios). De hecho, al usar el método HTTP también en este proceso, sigue siendo posible ejecutar ataques de repetición (incluyendo ataques nonce contra el cifrado de la conexión en algunas implementaciones). En definitiva, el protocolo también podrá salir bastante caro por el hecho de que muchos clientes diferentes ejecuten consultas al mismo CA para todos los certificados que esa autoridad ha generado hasta la fecha.

El OCSP stapling o "grapado de OCSP" (podemos verificar aquí si nuestro navegador lo soporta) es el último intento de administrar el proceso de revocación de certificados. Para responder tanto a problemas de privacidad como de escalabilidad, este habilita al servidor para que ofrezca una garantía de la validez del certificado. El cliente ya no contacta con el CA (que almacena el certificado), sino que en su lugar es el propio servidor quien realiza ese paso, requiriendo una respuesta con firma de fecha y hora OCSP, que es posteriormente "grapada" a cualquier cliente que haya iniciado una conexión TLS (conexión segura cifrada). La única pega de este método es que dicho protocolo solo soporta una respuesta OCSP, lo cual rompe la compatibilidad con sitios web que usan diferentes certificados (para diferentes recursos o productos).

Estos tres protocolos a veces funcionan simultáneamente para ofrecer un modo de protección por fallos. El cliente comienza pidiendo un "certificate status request". Si el servidor no cumple la solicitud, el cliente traspasa la petición al CA. Si tampoco el CA cumple la solicitud se usará el CRL. Debemos tener en cuenta que esta es la mejor práctica, pero no hay un estándar que dicte cuál es el mejor método a seguir (diferentes navegadores adoptan diferentes medidas frente a estos problemas). Lo que resulta preocupante es que el cliente nunca es informado en todo el proceso. En otras palabras, el cliente podría estar usando una CRL que tiene 7 días de antigüedad, pero percibiendo el nivel de seguridad ofrecido por el método más avanzado, OCSP stapling.

Desgraciadamente, a pesar de algún intento discreto como las ARL (Authority Revocation List), no existe protocolo alguno para restablecer la confianza en una CA. Actualmente no existen datos sobre futuros parches o cambios en el sistema, pero os mantendremos informados si se producen. Mientras tanto deberemos ser precavidos al navegar.

Compara antivirus y software para acelerar el pc en nuestra web Mejor Antivirus

Sergio Méndez Galindo

Sobre el autor

Sergio Méndez Galindo

Fundador de mejor-antivirus.es

79 artículos · 60.560 lecturas

Comparte tu conocimiento con el mundo.

Publicar un artículo →