29 mayo 2013

Certificados SSL irrevocables

Uno de los pilares básicos en el 'mundo SSL/PKI' es la posibilidad de beneficiarse de poder contar con una entidad certificadora que, aparte de asegurar la identidad, sea capaz de gestionar posibles desastres revocando los certificados emitidos.

Esto, que parece algo obvio, se sigue haciendo mal en pleno 2013. Seguimos suspendiendo en algo que debería estar totalmente estandarizado y ser cumplido con la máxima rigurosidad.

Según leo de un artículo recientemente publicado por netcraft, algunas CAs reconocidas (aprobadas por Microsoft, Mozilla, etc) emiten certificados que son virtualmente irrevocables.

Veamos porque:

De entrada los navegadores hacen de su capa un sayo y cada uno verifica el estado de los certificados como le da gana.

Existen dos formas de verificar si un certificado está vigente o ha sido revocado:

-Usando CRLs: son ficheros donde aparecen los certificados revocados, el navegador debería descargar ese fichero y comprobar

-Usando servicios OCSP: Mucho más óptimo que lo anterior, se lanza una llamada a un servicio OCSP preguntando por un certificado y el servicio responde si es o no es válido.

Para implementar cualquiera de las formas anteriores, una CA debe poner esa información como parte del certificado que emite en el campo (extensión) apropiado. De esa forma, cuando se presenta un certificado al navegador, este tiene a mano alguno de estos dos métodos para verificar.

Como decía al principio, cada navegador tiene su propia forma de comprobar la validez de un certificado:

Firefox solo usa OCSP para comprobar la validez de los certificados digitales salvo que sea un certificado EV. Esto significa que si solo hay disponible CRLs, no se valida nada. Además solo valida el certificado del servidor, no comprueba la validez de toda la cadena

Explorer hace mejor las cosas y en este caso si comprueba tanto uno como otro método.

Google Chrome no implementa ninguno de los métodos estándar (salvo para certificados EV) y apuesta por gestionar una lista de certificados revocados propia que mantiene a base de updates. (Obvio pensar que esto funciona para grandes CAs pero habría que ver que sucede con otras locales)

Safari por defecto directamente no comprueba nada salvo que sea un certificado EV

Por si esto no fuese ya alarmante, algunas CAs directamente emiten certificados en los que no añaden ninguno de los métodos anteriores. Directamente generan un certificado totalmente irrevocable. Esto, que ya resulta poco aceptable para una implementación PKI 'casera', no tiene disculpa posible a nivel profesional.

Netcraft cita varios ejemplos de certificados así, y uno de ellos, el de https://sede.malaga.es/ ha sido emitido por la FNMT

Otro ejemplo de certificado 'casi' irrevocable es el de https://accounts.google.com en este caso es solo 'casi' porque al menos implementa el sistema de CRLs, lo que significa que Explorer sí lo puede verificar pero Firefox no.

[Referencias]



7 comments :

hcn dijo...

La situación es algo más compleja de lo que planteas, ya que no funciona
igual en las versiones de escritorio que en las móviles. Por ejemplo,
en el caso de Safari, la situación que se indica en el artículo sólo es
aplicable en la versión de Safari para iOS, donde no existe la llamada "Sec­TrustEvaluate­Async"
utilizada por la versión original de Safari para Mac OS X (donde, por
cierto, el comportamiento es diferente, ya que la validación es
gestionada por los llaveros del sistema operativo).

exoddus dijo...

Un apunte gramatical/léxico (hacia el artículo original): **desde mi punto de vista**, aún no siendo falso, entiendo que seria más conveniente llamarlos certificados in-comprobables o in-validables ya que no incluyen ninguna ruta ni a OCSP ni a CRL, pero siendo estrictos, que no emitan sus certificados con esa información no significa que no se pueda revocar (cada prestador tiene sus mecanismos para revocar los certificados).


La CRL o la respuesta OCSP se construye en base a un directorio que cada prestador mantiene (y estrictamente no depende si los certificados tienen o no esa información añadida), y que no lo publiquen en una CRL o OCSP, no es lo mismo que no se genere el proceso de revocación (aunque ciertamente si no lo publican/responden al ocsp no tiene mucho sentido nada de todo esto).


Saludos!

rvasquezgt dijo...

Los temas de verificacion de certificados estan aun en pañales bueno mas bien todo el tema de certificados, esto es porque el mundo aun no lo adopta, incluso hay paises que sus servicios gubernamentales aun no son electronicos, considero que en unos 5 años mas tendremos soluciones mas completas, por todo lo anterior es que las compañias hacen lo que se les da la gana, para mi el mejor metodo es verificacion contra el OCSP

Tomy dijo...

Cuanto falta por avanzar en este campo

Ignacio Agulló Sousa dijo...

Noticia inédita: por primera vez Internet Explorer hace algo mejor que los demás.

María García dijo...

Sí. Pero "algo". Habría que usar un navegador distinto para según qué cosas... :-(

ohú vieho dijo...

Te has intentado saltar el filtro XSS de IE?