Confía pero asegúrate – la verdad sobre los certificados seguros TLS

0

Recientemente se ha vuelto ha experimentar un problema importante con certificados de seguridad en la web. 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”. 

Enlace que apunta a la dirección del CA

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. 

Para empeorar aún más la situación, las CA’s normalmente diseminan las CRLs mediante protocolo HTTP, por lo que son posibles los ataques de repetición. Más aún, incluso aunque los estándares digan otra cosa, los navegadores web a veces consideran que el fallo en la descarga del CRL es un mero error de software (no un ataque) y eso implica que la conexión no será terminada (lo cual sería recomedable como medida de seguridad ante posibles cuelgues o problemas imprevistos) 

Enlace que apunta a la respuesta OCSP

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. 

Respuesta OCSP "grapada" a la respuesta del servidor

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.

Si nos basamos en lo que hemos descrito, sería de sentido común pensar que desarrollar un estándar propio, actualizando todas las implementaciones y asegurando todas las posibles brechas en la seguridad de alguna forma mitigará el riesgo de ataques contra certificados TLS. Desgraciadamente esto es es casos aislados. El problema fundamental no tratado por ninguno de estos protocolos es que, en algunas circunstancias, deberíamos dejar de confiar (al menos temporalmente) en un CA completo (y no solo en un certificado en concreto). Esto podría pasar en dos escenarios:

1. Un certificado ha sido compromemtido, pero el CA no ha revocado el certificado aún.

2. Todo el CA ha sido puesto en peligro y deberemos por tanto perder la confianza en todos los certificados generados por él.

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. Todo el problema es derivado a la aplicación o sistema operativo que será el encargado de iniciar y actualizar la cadena segura de los certificados CA de confianza. El escenario es peor considerando que estas actualizaciones no se apoyan en un mecanismo de distribución “fuera de línea” (como el protocolo OCSP) y en su lugar solicitan al usuario la actualización de la aplicación al completo. Es por ello que en todos los fiascos recientes de CAs los usuarios han permanecido desprotegidos durante semanas. Mas aún, aunque los sistemas operativos modernos ofrecen galerías centralizadas de certificados, cada aplicación (con alguna excepción notable como la de Google Chrome) normalmente descansa sobre su propio repositorio. Acabamos por tanto es un escenario bastante surrealista: si un CA es comprometido el usuario no se puede considerar protegido hasta que se lancen los correspondientes parches y estos alcancen el equipo en cuestión. 

Almacenes de certificados de Chrome y Firefox

Es triste tener que reconocer que no hay solución alguna para este problema, por el momento. Se nos ha dicho que los incidentes son tan raros (relevantes, pero muy excepcionales) que se torna poco justificable cambiar todo el sistema implementado actualmente. Personalmente solo estamos de acuerdo conformes con dicha aseveración, porque pensamos que sería viable ofrecer algun parche o actualización incremental. Esperaremos a que haya posibles soluciones y os informaremos de ello. Mientras tanto ¡navegad con precaución!

Compartir.

Sobre el Autor

Alejandro es técnico micro-informático, experto en seguridad de las TIC y apasionado de la tecnología. Colabora habitualmente en diferentes publicaciones de seguridad, software y análisis de hardware entusiasta.

Dejar una Respuesta

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.

ACEPTAR