Con el lío que se ha montado con los certificados digitales falsos creados de Comodo ha habido mucho ruido y mucha información, con lo que probablemente todos estéis ya informados de que un hacker iraní consiguió hacerse con certificados falsos de Gmail, Live, etcétera. En Una al día, como suelen hacer con estas noticias desde hace más de 12 años [guiño, guiño], lo explican de maravilla, y Yago, de Security By Default, amplía la información en Me inComodo - me encanta el título -.
Sin embargo, hay un aspecto que me no he leído en casi ningún sitio y es la vulnerabilidad de OCSP frente a ataques Man In The Middle, que ya demostró Moxie Marlinspike en 2009.
El asunto radica en que, para mitigar el impacto que puedan tener en la seguridad los certificados digitales, en casi todos los sitios se habla de tener activado OCSP (que Firefox lo trae por defecto) o activarlo en el resto de navegadores. Sin embargo, Microsoft ha optado por aplicar Security Fix con una descarga de la CRL en cada equipo. ¿Por qué ha hecho esto?
El protoolo OCSP (Online Certicate Status Protocol), como su propio nombre indica, es un sistema de consulta online para saber si un determinado certificado digital ha sido revocado o no. Para ello, el cliente envía la petición a la ubicación de la CRL (Certificate Revocation List), que viene indicada en el propio certificado digital. Si quieres saber más de certificados digitales, no dudes en comprarte el libro del DNI-e de Rames Sarwat [guiño, guiño]
Ahora viene el problema. Si un atacante está haciendo un ataque de Man in The Middle para utilizar uno de estos certificados digitales, entonces también puede interceptar las peticiones OCSP. Estas peticionees, aunque van firmadas en su cuerpo, no van firmadas en su cabecera y hay una respuesta especial que puede mandar el atacante para hacer que se de siempre por bueno un certificado digital, y es el número que llevaba Roberto Carlos en el Real Madrid.
Como explicaba Moxie en sus charlas, OCSP tiene una respuesta válida que puede devolver un servidor que es Try Later. Esta contestación, que tiene asignado el código 3, le dice al cliente que ahora no puede atender su peticion, que lo siente mucho. Así, la mayoría de los clientes, ante esta situación, aceptan el certificado digital o, en algunos casos, muestran una alerta totalmente distinta a la típica de los ataques Man in the Middle.
Lo cierto es que basta con conectar un Proxy en medio cancelar todas las peticiones OCSP que hace el cliente (yo lo he hecho con Firefox 4 y Gmail) y el navegador, no comprueba si está revocado o no el certificado y NO da niguna alerta.
Figura 1: Peticiones OCSP dropeadas en Firefox 4
Conocido el ataque de Roberto Carlos al protcolo OCSP, y el comportamiento de no generar alertas ante la imposibilidad de conectarse al servidor OCSP, es por lo que Microsoft, aka Spectra, ha optado por el security update, que yo tengo instalada en mi Windows Raúl.
Saludos Malignos!
Sin embargo, hay un aspecto que me no he leído en casi ningún sitio y es la vulnerabilidad de OCSP frente a ataques Man In The Middle, que ya demostró Moxie Marlinspike en 2009.
El asunto radica en que, para mitigar el impacto que puedan tener en la seguridad los certificados digitales, en casi todos los sitios se habla de tener activado OCSP (que Firefox lo trae por defecto) o activarlo en el resto de navegadores. Sin embargo, Microsoft ha optado por aplicar Security Fix con una descarga de la CRL en cada equipo. ¿Por qué ha hecho esto?
El protoolo OCSP (Online Certicate Status Protocol), como su propio nombre indica, es un sistema de consulta online para saber si un determinado certificado digital ha sido revocado o no. Para ello, el cliente envía la petición a la ubicación de la CRL (Certificate Revocation List), que viene indicada en el propio certificado digital. Si quieres saber más de certificados digitales, no dudes en comprarte el libro del DNI-e de Rames Sarwat [guiño, guiño]
Ahora viene el problema. Si un atacante está haciendo un ataque de Man in The Middle para utilizar uno de estos certificados digitales, entonces también puede interceptar las peticiones OCSP. Estas peticionees, aunque van firmadas en su cuerpo, no van firmadas en su cabecera y hay una respuesta especial que puede mandar el atacante para hacer que se de siempre por bueno un certificado digital, y es el número que llevaba Roberto Carlos en el Real Madrid.
Como explicaba Moxie en sus charlas, OCSP tiene una respuesta válida que puede devolver un servidor que es Try Later. Esta contestación, que tiene asignado el código 3, le dice al cliente que ahora no puede atender su peticion, que lo siente mucho. Así, la mayoría de los clientes, ante esta situación, aceptan el certificado digital o, en algunos casos, muestran una alerta totalmente distinta a la típica de los ataques Man in the Middle.
Lo cierto es que basta con conectar un Proxy en medio cancelar todas las peticiones OCSP que hace el cliente (yo lo he hecho con Firefox 4 y Gmail) y el navegador, no comprueba si está revocado o no el certificado y NO da niguna alerta.
Figura 1: Peticiones OCSP dropeadas en Firefox 4
Conocido el ataque de Roberto Carlos al protcolo OCSP, y el comportamiento de no generar alertas ante la imposibilidad de conectarse al servidor OCSP, es por lo que Microsoft, aka Spectra, ha optado por el security update, que yo tengo instalada en mi Windows Raúl.
Saludos Malignos!
Buena entrada!
ResponderEliminarSin embargo, lo que entiendo es lo siguiente:
Por un lado, estás utilizando un certificado válido, pero revocado. Para que no se de cuenta el navegador que está revocado, utilizas esta técnica.
Pero me surgen dos dudas:
- Por un lado, los navegadores ya llevan los certificados por defecto (al menos unos cuantos), por lo que a no ser que sea un cert. revocado muy nuevo, no debería importar mucho este ataque, no?
- Por otro lado, cómo has conseguido un certificado que tú puedes firmar válido? Porque es fácil conseguir inválidos, pero aunque no estén revocados el navegador no "se los traga".
Supongo que en algún punto falla mi teoría, y es que por lo que me imagino, además también se comprueban los certificados raiz que han firmado a estos online. Pero... entonces para qué sirve que tengan unos certificados instalados en el navegador?
Algo no me cuadra :S
@Alberto, los Navegadores traen los Certificados de las CA de confianza. Si eres capaz de conseguir un certificado fraudulento firmado por una CA de confianza (ataque nullbyte, robo de passwords, colisiones de hashes, robo de cuenta de email del DNS admin, etc...) entonces la única forma de eliminarlos es revocándolos.
ResponderEliminarEsta revocación puede ser un fichero CRL (que se descargue en local) o una comprobación en linea con OCSP.
Y de esto va este post...
Saludos!
Hola Chema,
ResponderEliminarmuy bueno el post :), pero considero que hay que hacer una matización. En la prueba que has hecho no realiza la comprobación OCSP, pero eso es porque no has indicado en la configuración de Firefox que trate el certificado como inválido si falla la conexión OCSP.
Supongo que lo que quieres resaltar es que por defecto esta opción no se utiliza, y por lo tanto no se hace la comprobación si la conexión OCSP falla.
Por cierto, ¿qué proxy utilizas? Así si estoy inspirado luego hago una prueba rápida :)
Me resulta muy raro este post ya que firefox por defecto, en cuanto no recibe respuesta de un servidor OCSP valido te salta mensaje de no validación.
ResponderEliminarSino ahí tienes los ejemplos de los certificados generados por la fnmt...
@Iñigo, estás confundiendo la validación de la CA de confianza con el protocolo OCSP. Son cosas distintas. La alerta de la fnmt se produce poque el certificado está firmado por una entidad en la que por defecto no confía (ya que no viene de serie en el almacén de CAs de confianza) mientras que OCSP es un protocolo para comprobación en línea del estado de un certificado concreto, es decir, para saber si está revocado. Se supone que es una alternativa rápida a la descarga del fichero con la CRL de la entidad.
ResponderEliminarSaludos!
@damontero, el proxy que usé es Burp.
ResponderEliminarFirefox 4, por defecto, valida el certificado OCSP, como han dicho muchos medios, pero si no puede, como tu bien dices, no da error por defecto, ya que el usuario debería seleccionar la opción de "Marcar certificado como inválido". Luego, en definitiva, por defecto no da error si se dropean las peticiones y, en el caso de que se marque esa opción, con enviar un "Try later" de respuesta... traga. Es lo que quería decir.
Saludos!
Gracias por la aclaración :)
ResponderEliminarHola Chema
ResponderEliminarLo que quieres decir es que IE pasa del protocolo y hace lo que le parece mas oportuno, no? (qeu raro con lo comprometida qeu esta siempre spectra con los estandares ;P )
Es decir qeu si comunico que mi certificado de la FMNT o del DNI ha sido comprometido, mi CA lo incluye en su lista de revocación, pero desde IE hasta qeu no tenga a bien actualizar las CRL no se enterará, no??.
Y por otro lado esto de bajarse todas las CRLs de todos los CAs del mundo cada cuanto lo hace y qeu tráfico incorpora (supongo qeu es poco pero pensaba en el tráfico de datos limitado de mi móvil ;)
Saludos!
@Inma, Microsoft implementa OCSP también, pero, al igual que en Firefox hay que configurarlo para que sea útil.
ResponderEliminarRespecto a lo que ha hecho ha sido importar la CRL de los certificados en local para no depender de OCSP. Vamos, para que estén seguros los clientes Internet Explorer de verdad de la buena }:))
Como dijo Moxie n su charla "the answer is 3"
ResponderEliminarP.
@Sorian, me llegó!! Lo tengo escaneado y listo para publicar (quería que fuera por sorpresa) }:))
ResponderEliminarEs una pasada!!! Mil gracias!
Como siempre, clarinete!!! y con recuerdos madridistas!!!! que mas se puede pedir..
ResponderEliminarLo enlazo!
Esta solución no sólo la ha puesto en práctica Microsoft:
ResponderEliminarhttp://www.debian.org/security/2011/dsa-2203
Seguro que el gran Luciano te puede dar detalles.
@anónimo, sí, Debian la puso un día después que Microsoft porque confiar en OCPS es, cuanto menos "risky business".
ResponderEliminar}:))
@Maligno perdona que discuta contigo, pero el motivo por el que Firefox considera como "CA no autorizadas" a izenpe, fnmt es por no recibir respuesta del servidor OCSP de las mismas.
ResponderEliminarHaz una prueba: Intenta acceder por http al OCSP de verisign y recibirás respuesta. Haz lo mismo con servidores OCSP de la fnmt, izenpe y veras que no responden.
De ahí que no los considere válidos
@Iñigo, nada que ver. FNMT da un problema de confianza porque la CA no está en el almacén de CAs de confianza. OCSP no tiene nada que ver aquí. Puedes deshabilitar OCSP en Firefox y todos los certificados que están generados por CAs que aparecen el almacén de confianza seguirán sin dar ningún problema, mientras que la FNMT seguirá dándolo. Nada que ver con OCSP.
ResponderEliminarSaludos!
@Maligno
ResponderEliminar¿Pero porque no está la FNMT en la lista de CA de confianza? ¿Porque Firefox no considera esta entidad estatal como un emisor de CA valido?
El motivo es que no pasan los requerimientos que solicita Mozilla y en muchos casos, está en el servidor OCSP.
[Aquí los requisitos para los navegadores]
http://technet.microsoft.com/es-es/library/cc751157(en-us).aspx
http://www.mozilla.org/projects/security/certs/policy/
El tema de las CA's en firefox es muy cañero, aunque los requisitos para ser aceptado por los navegadores es parecído, en Mozilla, son super serios con las CA's que admiten (excepto alguna que se les coló que no sabían de qué era, y desde entonces están en modo paranoíco).
http://threatpost.com/en_us/blogs/mozilla-warns-unknown-root-certificate-authority-firefox-040610
De las más comunes que yo sepa que no están por este motivo son:
* FNMT no ha estado nunca en ffox.
* ipsCA, no está desde Nov ffox.
* Izenpe (AC del gov. vasco) tampoco ha estado nunca en ffox.
El caso más extendido igual es el de la ipsCA, que se utiliza mucho en .edu ya que daba certificados gratis para dos años.
Los motivos por los que no pasa esta entidad (entre los que se incluye la no respuesta del servidor OCSP):
https://bug529286.bugzilla.mozilla.org/attachment.cgi?id=413220
Saludos!!
@Maligno
ResponderEliminarSe me olvidaba comentar que en el tema de los OCSP ha habido discusiones con bastante mala leche:
"Lets make something crystal clear! We are not baby-sitting CAs nor interested in yanking any roots, however I think their attitude and performance has been below any reasonable MINIMAL expectations. I mean, how long can this take to bring an OCSP responder up and running? One day? Two days? A week? But heck, this has been going on for months.... "
http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/e4e5906fc5b1d956?pli=1
@Iñigo, entiendo que en Firefox no esté por que no tengan OCSP. Pero en cualquiera caso, aunque lo tuvieran, seguiría funcionando igual, ya que OCSP es poco menos que inutil, por desgracia, en entornos de Man In the Middle.
ResponderEliminarAcabo de llegar de la Troopers, y se la ha dedicado mucho tiempo a esto, y una de las cosas que se ha dicho es que, al final, OCSP, cuando se ha necesitado (con lo de Comodo) no ha servido para lo que estaba pensado... y hay que cambiarlo.
Sea como fuera, el que la FNMT no esté en FF por defecto creo que es algo que ambos, tanto la FNMT como la gente de FF deberían solucionar para dar soluciones a los ciudadanos, que es de lo que se trata.
Saludos!
@Maligno
ResponderEliminarAhí que si estoy de acuerdo contigo.
Un OCSP no tiene ninguna utilidad si se realiza un Man In the Middle y el usuario no tiene configurado firefox para que rechace el certificado si recibe un "Try Later".
Y son cosas que hay que cambiar, como bien dices.
Lo que comentaba es que es de vergüenza que entidades públicas estén en esta situación por cosas como los OCSP...
así que lo que hace totalmente inútil a OCSP es que el "Try later" no debería poder ir en una cabecera no firmada...
ResponderEliminarQue cambien eso y volverá a ser útil :-); ¿no?
@Anónimo, es más sencillo, que cuando salga un try later o no hay respuesta, que se tome por malo. Y listo!
ResponderEliminar