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ículoescrito 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!
0 comentarios:
Publicar un comentario