OCSP Stapling y la privacidad de tus usuarios

En un artículo anterior titulado El triste estado de las revocaciones SSL en Internet comento que Online Certificate Status Protocol (OCSP) tiene varios problemas:

  1. Un serio problema de privacidad para el usuario final: cada vez que entras es una página web HTTPS, tu navegador hará una consulta OCSP, filtrando el hecho de que estás entrando en esa web en concreto. Esa información llega a la entidad de certificación que "avala" el certificado SSL de ese servidor y, naturalmente, es accesible también para todas las redes intermedias entre ella y tu ordenador
  2. El volumen de tráfico en la entidad de certificación es proporcional al volumen de usuarios de una web determinada. Si una web tiene éxito, la entidad de certificación tendrá un coste adicional, sin ningún beneficio.
  3. Para el usuario final, la consulta OCSP supone añadir latencia, porque el navegador tiene que saber que el certificado SSL no ha sido revocado antes de mostrarte el contenido de la web.
  4. Si la entidad de certificación no responde a la petición OCSP, el navegador debe elegir qué hacer. Ahora mismo, la configuración por defecto suele ser soft-fail. Es decir, si la respuesta OCSP es "certificado revocado" o "certificado desconocido", el navegador nos denegará el acceso, pero si no nos llega ninguna respuesta OCSP, el navegador considerará que todo ha ido bien. Evidentemente, si estamos sufriendo un Man in the Middle o una impersonación, el atacante nos filtrará OCSP.

El último punto se puede solucionar con OCSP Must Staple, aunque parece que no hay avances recientes en esa iniciativa. Consiste en añadir una extensión más al certificado SSL firmado por la entidad de certificación que indica que el certificado solo es válido si se verifica conjuntamente con una respuesta OCSP. En este caso, si el atacante no incluye una respuesta OCSP reciente, el navegador consideraría que el certificado es inválido.

Los otros tres puntos tienen también una solución simple: OCSP Stapling. Explico Online Certificate Status Protocol y OCSP Stapling en un artículo anterior.

Para mí el punto 1 es muy importante. Puede ser que estemos empleando SSL para, precisamente, proporcionar privacidad a nuestros visitantes. Y al hacerlo, inadvertidamente, estamos comprometiendo su privacidad.

Afortunadamente los servidores web modernos soportan OCSP Stapling, solucionando los puntos 1, 2 y 3 de un plumazo.

(Dado que el soporte de revocación de certificados en los navegadores es bastante surrealista, estos problemas son menos importantes de lo que debieran, pero cuesta muy poco hacer las cosas bien en el extremo del servidor web)

Ventajas de emplear OCSP Stapling

Si el servidor web hace OCSP Stapling, las consultas OCSP las realiza él periódicamente, e incluirá esas respuestas en la negociación SSL con los navegadores. Revisando la lista de problemas de más arriba, tenemos:

  1. No hay problema de privacidad, ya que la consulta a la entidad de certificación la realiza el servidor web por su cuenta. Los navegadores de los usuarios no necesitan realizar consultas OCSP porque el servidor ya les envía una respuesta Online Certificate Status Protocol reciente.

  2. El volumen de tráfico OCSP en la entidad de certificación es proporcional al número de servidores web a los que ha firmado certificados SSL (y, por tanto, han cobrado dinero por ello), tengan mucho o poco tráfico.

  3. Dado que el navegador ya recibe una respuesta OCSP durante la negociación de la conexión con el servidor web, no necesita hacer una consulta OCSP a la entidad de certificación.

    Esto no es completamente cierto. La respuesta OCSP Stapling del servidor solo certifica la no revocación de su certificado SSL personal, pero no de toda la cadena X.509 hasta la raíz. Por suerte, los niveles superiores no comprometen la privacidad, y el navegador podría tener ya cacheada esa información, ya que las entidades de certificación intermedias firman muchos otros certificados no relacionados.

    Actualización 2014-06-11: El RFC 6961: The Transport Layer Security (TLS) Multiple Certificate Status Request Extension, publicado en junio de 2013, define una extensión de TLS que permite solicitar OCSP Stapling para toda la cadena de certificados del servidor.

Verificación de que nuestro servidor web NO emplea OCSP Stapling

Para ver si nuestro servidor devuelve información OCSP Stapling escribimos el siguiente comando (en entornos Unix y similares):

$ openssl s_client -connect www.XXX.org:443 -servername www.XXX.org -tls1 -tlsextdebug -status
CONNECTED(00000003)
TLS server extension "renegotiate" (id=65281), len=1
0001 - <SPACES/NULS>
TLS server extension "server ticket" (id=35), len=0
OCSP response: no response sent

La clave es la última línea. Nos dice que nuestro servidor no está enviando información OCSP en la negociación SSL.

Hay que usar el parámetro servername si el servicio SSL que queremos probar no tiene una IP dedicada y necesita SNI.

Configuración de nuestro servidor web para realizar OCSP Stapling

Apache HTTP 2.4.x

Una de las mejoras de la versión 2.4 de Apache HTTP es el soporte nativo de OCSP Stapling. Pero hay que activarlo. Para ello añadimos las siguientes directivas en la configuración (sirvan de referencia, no tienen que ser exactamente iguales):

SSLUseStapling on
SSLStaplingCache shmcb:/home/apache2/ocsp_stapling(512000)

Hay bastantes más parámetros que afectan a la configuración OCSP Stapling de Apache HTTP. Por ejemplo, con la configuración por defecto, Apache HTTP refrescará su respuesta Online Certificate Status Protocol cada hora, pero si no obtiene actualizaciones mantendrá en caché la última respuesta OCSP válida hasta que caduque. Echad un vistazo a las posibilidades de configuración.

Actualización 20151228: Echa un vistazo también al artículo OCSP Stapling y no cachear errores OCSP en Apache.

Verificación de que nuestro servidor web YA emplea OCSP Stapling

Volvemos a ejecutar el comando de antes, pero ahora veremos la información OCSP:

$ openssl s_client -connect www.XXX.org:443 -servername www.XXX.org -tls1 -tlsextdebug -status
CONNECTED(00000003)
TLS server extension "server name" (id=0), len=0
TLS server extension "renegotiate" (id=65281), len=1
0001 - <SPACES/NULS>
TLS server extension "server ticket" (id=35), len=0
TLS server extension "status request" (id=5), len=0
depth=1 /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
verify error:num=20:unable to get local issuer certificate
verify return:0
OCSP response:
======================================
OCSP Response Data:
  OCSP Response Status: successful (0x0)
  Response Type: Basic OCSP Response
  Version: 1 (0x0)
  Responder Id: C = IL, O = StartCom Ltd. (Start Commercial Limited), CN = StartCom Class 1 Server OCSP Signer
  Produced At: May 28 16:55:36 2014 GMT
  Responses:
  Certificate ID:
    Hash Algorithm: sha1
    Issuer Name Hash: 6568874F40750F016A3475625E1F5C93E5A26D58
    Issuer Key Hash: EB4234D098B0AB9FF41B6B08F7CC642EEF0E2C45
    Serial Number: 10A215
  Cert Status: good
  This Update: May 28 16:55:36 2014 GMT
  Next Update: May 30 16:55:36 2014 GMT

Podemos ver que el certíficado no está revocado y que la respuesta OCSP tiene una validez de 48 horas.

Misión cumplida.