OCSP y el depender de la profesionalidad ajena
He escrito ya antes sobre Online Certificate Status Protocol. Puedes ver el tag OCSP de este blog. En concreto en El triste estado de las revocaciones SSL en Internet expongo el hecho objetivo de que la mayoría de los navegadores web no comprueban la revocación de certificados o la comprueban de forma muy... peculiar.
Por ejemplo, con la configuración por defecto, un navegador normal que hace verificaciones OCSP hace lo siguiente:
-
Hay navegadores que no hacen comprobaciones OCSP para certificados X.509 normales, solo para los certificados EV. Por ejemplo, Apple Safari (el navegador de Mac OS X y de iOS). Ni que decir tiene que la inmensa mayoría de los certificados X.509 no son EV.
-
Supongamos que el navegador decide hacer una consulta OCSP. En este caso, si el servidor OCSP no responde en absoluto, no pasa nada. El certificado X.509 se dará por bueno. Esto es una vía de ataque evidente si nos conectamos a través de una red bajo el control de un ente malicioso.
¿Por qué se hace así? Porque no es raro que lo servidores OCSP de las entidades de certificación estén caídos o saturados. Es decir, no recibir respuesta a la petición OCSP es rutina. Como no es aceptable que el usuario del navegador reciba avisos de seguridad o se le deniegue el acceso a la mitad de la webs que visita cada día, los navegadores han sido prácticos y aceptan el hecho habitual de que no obtener una respuesta OCSP no tiene por qué indicar nada feo (al margen de la profesionalidad dudosa de esa entidad de certificación, claro).
-
Una petición OCSP supone una pérdida de privacidad para el usuario. Explico el problema y la solución en mi artículo OCSP Stapling y la privacidad de tus usuarios.
Resumiendo, el servidor web de un dominio accesible por HTTPS puede hacer una petición OCSP para su propio certificado X.509, cachear ese resultado durante unas horas e incluir esa respuesta en la negociación TLS entre el servidor HTTPS y el navegador. De esta manera el navegador se ahorra la petición OCSP y el tiempo de espera, y el usuario gana privacidad.
Una situación Win-Win de libro.
En principio con esto tenemos el problema solucionado, más o menos.
En la Semana Santa de 2015 sucedió una cosa curiosa.
Estaba yo en Italia y mi padre me envía un Whatsapp diciéndome que no podía entrar en mi página web. Cuando me fue posible me conecté desde el móvil y comprobé que mi web me funcionaba bien. Asumí que había habido un problema puntual de comunicación y se había solucionado solo. Seguí comiendo.
Poco después me llega un mensaje de un buen amigo con lo mismo. Vuelvo a probar desde mi móvil y la web me funciona bien. Le pido un pantallazo y me manda esto:
Aquí se ve claramente que se trata de un problema OCSP. Se me encendió la bombilla: yo lo veo bien desde el móvil porque el navegador Safari de iOS no hace verificaciones OCSP para certificados que no son EV. Si hay algún tipo de problema con la respuesta OCSP, no lo veré en Safari sencillamente porque no lo comprueba. Mozilla Firefox, en cambio, sí.
Me conecto a la web de SSL Labs y le pido que compruebe mi servidor. El resultado es el siguiente:
Para mi sorpresa, StartSSL, la entidad de certificación que utilizo, no es que no esté respondiendo a las peticiones OCSP sino que está diciendo EXPLÍCITAMENTE que mi certificado X.509 le es absolutamente desconocido y, por lo tanto, se trata de un certificado fraudulento.
Alucinante.
En Italia y solo con un móvil a mano no podía hacer mucho, así que escribí a la gente de StartSSL. Esta fue su respuesta:
Due to a technical issue the OCSP responders failed to update - they are syncing again and this issue should resolve itself within the next few hours if it haven't already.
On 04/05/2015 03:53 PM, Jesus Cea wrote: > blog.jcea.es is failing too :-(((( > > > Enviado desde mi iPhone > >> El 5/4/2015, a las 14:44, Jesus Cea <jcea@jcea.es> escribió: >> >> I have a valid certificate until November, but startssl OCSP is giving a "unknown certificate" error. >> >> My email is jcea@jcea.es but I am currently mostly offline and my travel email is jcea-XXXXX@jcea.es. Please, use that address if you need to contact me. >> >> I include a screenshot. >> >> Help!!!! >> >> <image1.PNG> >> >> >> Enviado desde mi iPhone -- Regards Signer: Kirill Ivanov, VO StartCom Ltd. Twitter: Follow StartSSL™ XMPP: help@startcom.org Phone: +12133410329 +13475342026 +442077934541 +97286344170 +972576315626
Es decir, debido a un fallo informático (jejeje, qué clásico), el servidor OCSP de StartSSL está rechazando certificados legítimos. ¡Madre mía!. Esto es catastrófico. Hubiera sido mucho más inteligente no responder a las peticiones OCSP en absoluto mientras se resolvía el problema.
Observemos el detalle importante: por un fallo de StartSSL los certificados X.509 de mis páginas web dejan de ser válidos temporalmente. Aunque estuviese en Madrid con mi ordenador delante no podría hacer nada. StartSSL dice que mis certificados son inválidos y no hay nada en absoluto que pueda hacer como no sea comprar certificados nuevos a otra compañía. Ni siquiera puedo desactivar el HTTPS temporalmente porque tengo activado HTTP Strict Transport Security.
La nube...
Afortunadamente el problema se solucionó en menos de 24 horas, pero durante ese tiempo estuve inaccesible en Internet. Imaginemos el coste -monetario y de reputación- que ello supondría si fuese una tienda online, una empresa, alguien "serio".
Lo malo es que no se trata de algo excepcional. He vuelto a tener el mismo problema el pasado 17 de junio de 2015.
Lecciones aprendidas
-
Como explico en OCSP Stapling y la privacidad de tus usuarios, si activamos OCSP Stapling en el servidor web de Apache, este va haciendo peticiones OCSP a la entidad de certificación de forma periódica. Si en algún momento el servidor OCSP no responde, Apache lo reintentará cada cierto tiempo. Bien.
El problema es que si la respuesta OCSP es negativa para nuestro certificado X.509, Apache la cachea internamente y la sirve en la negociación TLS durante horas o días.
Es evidente que en una situación así lo inteligente sería repetir la consulta OCSP cada pocos minutos, hasta conseguir un certificado OCSP "bueno". Esto no es una carga apreciable para la entidad de certificación ya que usando OCSP Stapling se ahorran todas las peticiones OCSP enviadas por los navegadores.
Ahora mismo la única forma de deshacernos de una respuesta OCSP incorrecta de forma rápida es reiniciar el servidor Apache para que vuelva a repetir la petición OCSP. La otra opción es esperar a que caduque, lo que puede llevar días. Una posibilidad es limitar artificialmente la duración de la respuesta OCSP en Apache. Eso se puede hacer con la directiva SSLOCSPResponseMaxAge.
-
Emplear HTTP Strict Transport Security limita tus opciones y hay que entender su impacto. A pesar de lo cual, yo recomiendo usar HSTS encarecidamente.
-
El modelo de negocio de las entidad de certificación X.509 merece la muerte. Debe desaparecer.
Ahora mismo veo dos tecnologías con buenas posibilidades de conseguirlo:
- DNSSEC y DANE.
- Let's Encrypt.
Escribiré más sobre ambos temas en el futuro.