En el mundo de los sitios web protegidos por TLS (antiguamente llamado SSL) hay dos temas polémicos. El primero es el mercado comercial de los certificados digitales, donde por un lado tenemos unos muy caros que hacen prohibitivo activar https para un sitio pequeño (que tiene un hosting compartido por unos pocos dólares), y por otro lado los certificados baratos/gratuitos que, o bien no son soportados por todos los navegadores, o tienen prácticas dudosas (como no chequear bien los titulares de los sitios), que han tenido bastante mal la reputación del sistema PKI.
El segundo tema polémico, aunque no tan visible, es el de la revocación.
Un certificado digital normalmente se emite (es decir, es firmado por la Autoridad Certificadora (CA)), con una validez de 1 o 2 años. Pero ¿qué pasa si la llave se compromete en ese tiempo? ¿O la roban? ¿O la empresa quiebra y el dominio es comprado por un especulador? Es muy importante que una CA sea capaz de revocar (invalidar) un certificado ya emitido, aunque esté correctamente firmado y esté dentro del plazo de validez.
Un navegador tiene 3 tareas muy claras al conectarse a un sitio web protegido con https y recibir el certificado:
Este último paso ha sido siempre el polémico. En los inicios de PKI, se utilizaron las CRL, “Certificate Revocation List”. Esto es, un archivo de texto que indica una lista de qué certificados están revocados. Muy simple.
El problema fué (y es) la disponibilidad de estas CRLs. Se transforman en un punto crítico de fallas. Yo mismo recuerdo hace años que de vez en cuando, al abrir mi Firefox, se quedaba en blanco, pegado hasta el infinito. Me costó darme cuenta que era cuando alguna CA tenía abajo su CRL. Firefox, al abrir las (decenas) de pestañas que tenía, chequeaba los CRL de todos estos sitios. Y por supuesto, esa acción es bloqueante: no puedo conectarme al sitio hasta tener la CRL.
Mi solución en ese tiempo, y que luego fue la práctica normal en las distribuciones era obvia: desactivar el chequeo CRL en tiempo real. Y quedar a merced de certificados revocados. La CRL se descargaba en background, o bien venía en actualizaciones del navegador, de vez en cuando.
Para solucionar esto, vino una segunda tecnología: OCSP. Esta segunda generación estaba optimizada para consultas en tiempo real. Se trataba de llamadas API a un servicio de la CA al cual uno le preguntaba por un serial del certificado (un número único), y respondía simplemente “OK” o “Revocado”. Fue una gran mejora, hasta que vino la época de optimización de los sitios web al microsegundo, y hacer una llamada a una API externa fue vista como un gran problema de OCSP. Lamentablemente poner ese requisito al momento de la conexión significaba un ida y vuelta de chequeos extra que no fue bien vista por los fanáticos del microsegundo.
Llegamos finalmente a lo nuestro. “OCSP Stapling”. Acá, la CA entrega un pequeño mensaje al estilo OCSP que asegura que un certificado sigue válido (esta vez por un período de tiempo mucho menor, días o semanas), pero esta vez ese pequeño mensaje puede ser solicitado por un servidor web, el que puede guardarlo mientras sea válido, y entregárselo al navegador web en el mismo momento que se conecta, junto con el propio certificado digital. Entonces, ¡el navegador no tiene que conectarse con nadie más!
Esta técnica lleva algunos años. Ya fue estandarizada por IETF en el RFC6961, y es soportado por Apache2, nginx, IIS, HAProxy y otros, por el lado del servidor; y Firefox, Internet Explorer, Chrome por el lado del navegador. A comienzos de febrero la “Internet Architecture Board” recomendó su uso, lo que sumado a la recomendación de usar TLS siempre y en todo lugar, está llevando a mejorar la seguridad y privacidad de Internet para todos. Además suma puntos en el famoso ranking de Qualys Labs para sitios web ;)
Activar OCSP Stapling en Apache, usando un certificado de Globalsign, son 4 líneas nuevas en httpd.conf y un reinicio.