Nuevos Certificados Tls Comprometidos

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

Sergio Méndez Galindo
Sergio Méndez Galindo
21 de February · 678 palabras.
x

🕘 Resumen

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. Y, 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′s decargadas 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 que 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 ceritificado. 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 soporte una respuesta OCSP, lo cual rompe la compatilidad con sitios web que usan diferentes certificados (para diferentes recursos o productos)

Estos 3 protocolos a veces funcionan simultáneamente para ofrecer un modo de protección de 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 cual 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 antiguedad, 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

Comparte tu conocimiento y tus intereses con el mundo.

Publica un artículo →