05 junio 2013

En anteriores artículos, nuestro compañero Yago publicó una entrada muy interesante titulada Certificados SSL irrevocables. En esta entrada se debatía la gestión de certificados digitales, en especial la parte designada a la revocación de los mismos y cómo se comporta en este tipo de situaciones un navegador específico.

Para ello, en el artículo se plantea esta gestión desde el punto de vista del que emite un certificado (Entidad Certificadora) como del receptor del mismo (Por ejemplo un navegador a través de un sistema operativo).

Como bien se comenta en el artículo, para comprobar si un certificado es válido, existen dos mecanismos para realizarlo. O bien por listas de revocación (CRL) o a través de servicios en tiempo real como OCSP. Y aquí es donde empiezan los problemas.

Existe tanta controversia en la implementación y veracidad de estos mecanismos, que cada navegador implementa este chequeo en mayor o menor medida.

Para los más paranoicos existe el problema de la privacidad, ya que si un cliente (Un navegador por ejemplo) realiza una petición a una de estas CA para determinar si un certificado es válido o no, por el mecanismo que sea (OCSP o CRL), la CA bien podría estar almacenando las direcciones IP de quien se conecta, y a qué dirección URL está accediendo.

Otro problema bien podría ser el de la disponibilidad. Muchos navegadores realizan peticiones a una CA antes de aceptar un certificado. Esto, que en principio podría ser una buena práctica, se puede convertir en un punto de fallo para la empresa (Emisor de certificados) que disponga el servicio, pudiendo ocasionar picos elevados de consultas, con la consiguiente disminución del servicio.

El tiempo es un factor importante en el caso de que se opte por el mecanismo OCSP. Por defecto, el tiempo de espera entre una petición cliente-servicio OCSP se encuentra en torno a los 15 segundos. Si a una petición de este tipo se le aplican las velocidades de otros países, latencias en la red, caídas del servicio y una infinidad de posibles problemas de conexión, tendremos un bonito navegador que no sabrá qué hacer ante un imprevisto de esta índole.

Y la última que se me ocurre, y no menos importante, es cuando se realiza un ataque.  Hace ya tiempo, Moxie Marlinspike implementó en su archiconocida herramienta sslstrip un ataque contra OCSP conocido como el ataque del 3, el cual ya Chema Alonso anotó en su blog. A grandes rasgos, y en un ataque de tipo Man in The Middle, este ataque tenía éxito ya que enviaba a toda petición de tipo OCSP una respuesta indicando un mensaje de inténtelo más tarde (TryLater), ya que a estos campos no se le aplica la firma digital. No hay comprobación, no hay alerta.

Gracias a estos posibles problemas que una persona se puede encontrar en su día a día, los equipos de desarrollo implementan en los navegadores aquellos mecanismos de verificación que tengan un menor impacto en el usuario final, en cuanto a experiencia de usuario.

Con todo esto que hemos comentado en anteriores párrafos, me quedo con un comentario en ese mismo artículo escrito por exoddus, en el que cita que porque una CA no publique sus mecanismos de revocación para el cliente, eso no quiere decir que los certificados no se puedan revocar. Pero también me quedo con el mensaje de Yago. ¿Y los usuarios qué? ¿Qué mecanismos tiene el navegador o el sistema operativo para alertarnos cuando algo de esto pasa? ¿O es que tenemos que mirar las propiedades y extensiones de todo certificado digital?

A partir de Windows Vista y a través de políticas de grupo, es posible definir, configurar y optimizar el comportamiento del sistema a la hora de realizar este tipo de comprobaciones a nivel corporativo.
A nivel de usuario, si por ejemplo accedemos a la URL que indicó Yago (https://sede.malaga.es) a través de Internet Explorer, nos encontraremos con una imagen similar a la siguiente:


Imagen 1.- Internet Explorer sin alertas aparentes con certificado no-verificable

Como bien se comentaba en el artículo anterior, a partir de Windows Vista se realizan las comprobaciones a través de los dos mecanismos citados anteriormente, pero con el consiguiente de que si no obtiene respuesta de ninguno de ellos (Sea por la causa que sea), el navegador no mostrará ningún tipo de alerta.

Este comportamiento es así por diseño del propio Internet Explorer, ya que como hemos citado anteriormente, existen tantas posibilidades de que una petición de verificación no se realice con éxito, que el sólo hecho de incluir una alerta o fallo degradaría en muchos casos la experiencia de un usuario cuando éste navegase por Internet.

Esto no quiere decir que el navegador (En el caso de Internet Explorer) no incluya este tipo de aviso o alerta. La incluye, pero hay que activarla, ya que ésta viene desactivada por defecto.
La activación de esta característica es una tarea trivial, y sólo hace falta una pequeña modificación del registro para que puedan disfrutar de ella aquellos usuarios que así lo deseen.

En el caso de que se desee configurar para un usuario en particular la recomendación es aplicar este cambio en la clave HKEY_CURRENT_USER (Perfil de usuario autenticado en la máquina).


Imagen 3.- Configuración de parámetro FEATURE_WARN_ON_SEC_CERT_REV_FAILED para avisos de fallo de chequeo

Si se desea aplicar este cambio a nivel de equipo, se puede realizar a través de la clave HKEY_LOCAL_MACHINE. Este cambio afectará a todos los usuarios que utilicen el sistema.

Una vez habilitada esta característica, y si volvemos a encontrarnos con un fallo de chequeo a nivel de revocación, el navegador Internet Explorer nos mostrará una alerta del siguiente tipo:



Imagen 4.- Activación de característica de alerta de certificado no-verificable

Un saludo a tod@s!

Juan Garrido
MVP Enterprise Security
@tr1ana

8 comments :

tayoken dijo...

Cada vez estoy más a favor del sistema de "notarías" que propone Convergence.

http://convergence.io/index.html

María García dijo...

Gracias. Muy interesante y muy bien explicado, que hasta las "Pennies" podemos hacerlo.
Pero ya podía venir por defecto. Que total, la alerta no molesta casi; si es un iconito chiquitín en la barra...

He probado en otras sedes y me da el mismo mensaje. ¿Es que la Fábrica no comprueba nada? He visto que en otros sitios (como el Mityc) usan el de la Camerfirma. Para mí, hasta ahora desconocida (me he quedado un poco atrasada).



Gracias otra vez.

Álvaro Reig González dijo...

Hola María,

El problema de la FNMT es que sus certificados raíz no vienen incluídos por defecto en el almacén de Windows (IE, Chrome), ni en el de Firefox, ni en la JDK de Java. Me consta que están en ello (https://bugzilla.mozilla.org/show_bug.cgi?id=435736) pero a día de hoy no está. Es por eso que en algunos organismos estamos optando por certificados de sede emitidos por Camerfirma. No son la panacea, pero al menos no da avisos de seguridad en los tres navegadores con Windows. Sin embargo, Firefox en Linux, Chrome en Android e iOS no incorporan el raíz de Camerfirma, y por lo tanto siguen dando alertas al entrar.

Un saludo,

Juan Garrido dijo...

Álvaro, en Windows SÍ viene por defecto el/los certificados de la FNMT, lo que ocurre es que a partir de Windows Vista los certificados se instalan mediante actualizaciones.
http://support.microsoft.com/kb/978599/es
El caso de Mozilla es diferente, ya que ellos gestionan su propio almacén de certificados (No utilizan el de Windows).
Salu2

Juan Garrido dijo...

Me auto-respondo, ya que a través de nuestro compañero Yago me he encontrado con este post de 2010 el cual contesta de manera técnica a la pregunta de Álvaro.
Salu2!

http://www.securitybydefault.com/2010/04/gestion-de-certificados-digitales-en.html

Álvaro Reig González dijo...

Hola Juan,


Gracias por el apunte, estaba equivocado. El proceso me parece muy opaco, además de que la política de actualizaciones de cada organización condicionará los certificados que ven.


No hablemos ya de usuarios domésticos, claro.


Un saludo

Álvaro Reig González dijo...

Hola de nuevo Juan,

He preguntado a compañeros de sistemas en varios organismos y parece ser que han tenido bastantes problemas en el pasado con estas actualizaciones. Les han pasado cosas como perder CRLs, que el almacén de certificados muestre todos los raíz pero que luego el servidor no confíe en realidad en todos, etc. Por ello optan por gestionarlo a mano.


De todos modos, todo usuario que no tenga en su equipo instalada esa actualización verá el aviso de seguridad al acceder a un organismo público. Me sigue pareciendo mejor opción Camerfirma. He vuelto a probar el certificado de sede de mi organismo y tanto en Firefox como Chrome en Android lo aceptan sin dar aviso, han debido de incluir el raíz en estos dos meses.


Un saludo,

Pedro dijo...

El problema creo que no está en que el certificado raíz esté incluido dentro del almacén de certificados de Windows. ADEMÁS, es necesario que un certificado en particular no esté revocado.
Por ejemplo, yo tengo un certificado de la FNMT para www.misitio.es .
El navegador, aparte de comprobar que el certificado raíz que firma ese certificado de sitio web es de una AC "buena" (vamos, que está en el almacén de certificados), deberá consultar a la autoridad de certificación el estado de revocación.
Y esto es lo que falla.