Funcionamiento de OCSP con Certificate Transparency

lunes, 20 de noviembre de 2017

Online Certificate Status Protocol (OCSP) quizás sea el protocolo menos conocido o estudiado de la infraestructura PKI, los certificados digitales y la familia SSL/TLS, ya de por sí desconocidos en su zona más "técnica" y "profunda". En este artículo, profundizaremos cómo se comporta no solo este protocolo, sino cómo interactúa con Certificate Transparency, ahora que será obligatorio en abril.
Esencialmente existen tres tecnologías que los navegadores pueden implementar para comprobar el estado de revocación de un certificado digital:
  • La lista negra de revocación descargable, conocida como Certificate Revocation List (CRL) definido en la RFC 5280. Las CRL es una lista de números de serie de certificados revocados que se descarga en un intervalo fijo de tiempo. La historia ha demostrado que no funciona. 
  • OCSP, definido en la RFC 6960. OSCP funciona con un mecanismo de pedido-respuesta que solicita la información sobre un certificado específico a la CA. 
  • CRLSets. Es un método "rápido" de revocación que utiliza solo Chrome, como ellos mismo dicen, para "situaciones de emergencia". Son un conjunto de certificados que se aglutinan de información de otros CRLs, se descargan de un servidor, y son procesados por Chrome. Aunque el método es absolutamente transparente, la gestión de qué certificados van en la lista es totalmente opaca, no se sabe con qué certificados lo actualizan (a menos que se averigüe por otro lado). 
La diferencia fundamental es que CRL proporciona la lista de certificados revocados con menor frecuencia, y por tanto, no proporciona la agilidad que se espera ante una revocación exprés. OCSP brinda información en tiempo real sobre los certificados revocados por una CA emisora. Por ejemplo, para realizar una validación manual de la CRL se puede seguir los siguientes pasos, tomando como ejemplo un Banco de Malasya (maybank.com.id)
// Descargar Certificado de Banco de Malasya openssl s_client -connect maybank.co.id:443 2>&1 < /dev/null \\ | sed -n '/-----BEGIN/,/-----END/p' > maybank.pem // Obtener URL de la CRL openssl x509 -noout -text -in maybank.pem | grep -A 4 'X509v3 CRL Distribution Points' // Obtiene el serial del certificado openssl x509 -noout -text -in maybank.pem | grep -A 4 'Serial Number' >> 52:AF:68:16:46:76:59:8D:57:57:2B:E5:F8:D2:8F:0F // Descargar archive de la CRL actual, formato binario wget http://ss.symcb.com/ss.crl // CRL en formato texto openssl crl -inform DER -text -noout -in ss.crl > ss.pem
 A través de esta verificación se puede comprobar un certificado antiguo (Serial Number: 14394B794CEBA750CE1648189AF06049) revocado en 2012:

// CRL de verisign utilizado por el banco en 2012
wget http://SVRIntl-G3-crl.verisign.com/SVRIntlG3.crl
openssl crl -inform DER -text -noout -in SVRIntlG3.crl >SVRIntlG3.pem
// Verifica la revocación de dos certificados
grep "14394B794C" SVRIntlG3.pem (revocado Sep 12 02:49:50 2012 GMT)
grep "52AF681646" SVRIntlG3.pem (actual, no revocado)

Sin embargo, uno de los problemas que surge cuando la comprobación OCSP está habilitada es el tiempo necesario para completar el Handshake SSL/TLS; a mayor número de peticiones y verificaciones, mayor es el tiempo que le lleva al navegador comprobar la validez del certificado y en mostrar el sitio… algo inaceptable para los tiempos que debe manejar un sitio importante hoy por hoy.

Por ejemplo, para que el navegador muestre la "barra verde" que distingue un certificado de Validación Extendida (EV), las solicitudes OCSP deben hacerse para todos los certificados de la cadena (en algunos casos esto puede requerir hasta tres solicitudes OCSP), y dependerá del navegador la forma de realizar dicha comprobación que puede ser secuencial, en paralelo o a través de una red de distribución de contenido o CDN. Como nota importante, el equipo de Cloudflare dice que con estas comprobaciones, puede llegar a haber hasta un 30 % adicional de tiempo en la carga de un sitio web.

Para superar los problemas de rendimiento, el grupo de trabajo TLS de Internet Engineering Task Force definió una extensión del protocolo TLS, denominado Stapled OCSP (en una mala traducción al español: OCSP grapado). Es una práctica recomendada por el consorcio CA/Browser Forums y puede ser implementado fácilmente en IIS 7+, Apache 2.4+, Nginx 1.7.3+ y Exim, siendo reconocido también por los principales navegadores del mercado.

La clave para un mejor rendimiento es deshacerse de las solicitudes adicionales hacia la CA, y la respuesta OCSP debe ser incluida directamente en el saludo inicial del protocolo SSL/TLS. De este modo, el Stapled utiliza el servidor TLS como proxy para que solicite la respuesta OCSP y la envíe al cliente como parte del handshake TLS. Como la respuesta se obtiene directamente desde el servidor, el cliente no necesita solicitar información a la CA emisora, lo que resulta en un mayor rendimiento del sitio. Sin embargo, la práctica demuestra falta de implementación de servidores con Stapling OCSP habilitado. Este comportamiento puede deberse principalmente a tres factores:
  • Falta de conocimiento del protocolo, mencionado al comienzo.
  • Falsa creencia actual de que los tiempos de sobrecarga no son importantes.
  • Baja tasa de certificados revocados (0,3 % según este estudio) que se ven en la actualidad, lo cual invalida la necesidad de verificarlos.
Por lo antes expuesto, cuando se trata de validar implementaciones de seguridad sobre la base del uso de OCSP, el análisis resulta incómodo y hasta a veces puede parecer innecesario o inútil. Esto también nos sucedió en ElevenPaths cuando nos encontrábamos desarrollando el plugin de Firefox y SCT Checker para detectar Transparencia de Certificados sobre OCSP. Recordemos que, como ya mencionamos, existen tres formas de ubicar físicamente el registro SCT que acompaña al certificado: como extensión X.509v3, como extensión del protocolo TLS (extensión 18) y en respuesta de OCSP. En este último caso, la baja tasa de implementación atentaba contra nuestras pruebas llegando a resultar (casi) imposible encontrar CT sobre OSCP.

Ejemplo de obtención del registro OCSP sobre el dominio de Google (sin resultados) y el de la entidad certifidora Digicert:

openssl s_client -connect google.com:443 -status | \\
  grep -A 4 "OCSP response:" (no muestra OCSP response)
openssl s_client -connect digicert.com:443 -status | \\
  grep -A 4 -B 4 "OCSP Response Data:" (muestra OCSP response)

De acuerdo a lo anterior, para realizar pruebas de obtención del registro SCT sobre OCSP, se buscó un sitio web que lo tuviera implementado y a partir de allí se realizó el siguiente análisis:

// Obtener el certificado de "sslanalyzer.comodoca.com", con SCT sobre OCSP
openssl s_client -connect sslanalyzer.comodoca.com:443 2>&1 < /dev/null \\
| sed -n '/-----BEGIN/,/-----END/p' | cat > comodo.pem
// Obtener la cadena de certificados. 

//El primero se descarta porque es el ya descargado antes
openssl s_client -connect sslanalyzer.comodoca.com:443 2>&1 -showcerts < \\
   /dev/null | sed -n '/-----BEGIN/,/-----END/p' | \\

   perl -0777 -pe 's/.*?-{5}END\sCERTIFICATE-{5}\n//s' | cat > chain_comodo.pem
// Obtener la dirección OCSP del certificado
openssl x509 -noout -ocsp_uri -in comodo.pem
>> "http://ocsp.comodoca.com", 
// Ejecutar la validación OCSP
openssl ocsp -issuer chain_comodo.pem -cert comodo.pem -url \\

   http://ocsp.comodoca.com -header "HOST=ocsp.comodoca.com" \\

   -VAfile chain_comodo.pem
openssl ocsp -issuer chain_comodo.pem -cert comodo.pem -text \\

  -url http://ocsp.comodoca.com -header "HOST=ocsp.comodoca.com" \\

   -VAfile chain_comodo.pem
Efectivamente, con estas consultas se obtienen los registros SCT y Log ID del dominio analizado:


A modo de control, se puede tomar el primer Log ID en hexadecimal, convertirlo a BASE64 y verificarlo contra el listado público de Logs de Transparencia de Certificados.

echo "56:14:06:9A:2F:D7:C2:EC:D3:F5:E1:BD:44:B2:3E:C7:46:76:B9:BC:99:\\
  11:5C:C0:EF:94:98:55:D6:89:D0:DD" | tr -d : | xxd -r -p | base64
>> VhQGmi/XwuzT9eG9RLI+x0Z2ubyZEVzA75SYVdaJ0N0=

De acuerdo al listado de Certificate Transparency, este ID corresponde a: ct1.digicert-ct.com/log
Esta información también puede visualizarse fácilmente desde Chrome, al acceder al sitio web (sslanalyzer.comodoca.com) y, mediante la visualización de los eventos de conexión en el momento del Handshake TLS:

chrome://net-internals/#events



scts_from_ocsp_response = "AO8AdQBWFAaaL9fC7NP14b1Esj7HRna5vJkRXM \\
  DvlJhV1onQ3QAAAVF7xvsQAAAEAwBGMEQCIGOBoDxxtb/VoujmQ3WH2u4T1jF3Ri \\
  KNlSEK+MLg9dA0AiATrA9czgxAZsPtoiGuSBHnfSv014jJJSgvtvq3ambrEgB2AGj\\
  2mPgfZIK+OozuuSgdTPxxUV1nk9RE0QpnrLtPT/vEAAABUXvG/WAAAAQDAEcwRQIhA\\
  Oum7vph1pHy8AIxobtkDD5ZE6SkroxzSdC6bmZoX9WDAiBTmudcU6U+4lvVXqgxmHFw\\
74kjvEHfCq4oK40jgvw+dw==" 
 
Log ID = "VhQGmi/XwuzT9eG9RLI+x0Z2ubyZEVzA75SYVdaJ0N0="

Ahora, transformando la primera cadena a hexadecimal, podemos conocer los detalles de cada uno de los registros SCT:
 
echo "AO8AdQBWFAaaL9fC7NP14b1Esj7HRna5vJkRXMDvlJhV1onQ3QAAAVF7xvsQA \\
  AAEAwBGMEQCIGOBoDxxtb/VoujmQ3WH2u4T1jF3RiKNlSEK+MLg9dA0AiATrA9czgx \\
  AZsPtoiGuSBHnfSv014jJJSgvtvq3ambrEgB2AGj2mPgfZIK+OozuuSgdTPxxUV1nk9\\ 
  RE0QpnrLtPT/vEAAABUXvG/WAAAAQDAEcwRQIhAOum7vph1pHy8AIxobtkDD5ZE6Skro\\
  xzSdC6bmZoX9WDAiBTmudcU6U+4lvVXqgxmHFw74kjvEHfCq4oK40jgvw+dw==" |   \\
  base64 -d | xxd -p | tr -d '\n'
>> 00ef0075005614069a2fd7c2ecd3f5e1bd44b23ec74676b9bc99115cc0ef949855d \\
   689d0dd000001517bc6fb10000004030046304402206381a03c71b5bfd5a2e8e6437 \\
   587daee13d6317746228d95210af8c2e0f5d034022013ac0f5cce0c4066c3eda221a \\
   e4811e77d2bf4d788c925282fb6fab76a66eb1200760068f698f81f6482be3a8ceeb \\
   9281d4cfc71515d6793d444d10a67acbb4f4ffbc4000001517bc6fd60000004030047\\ 
   3045022100eba6eefa61d691f2f00231a1bb640c3e5913a4a4ae8c7349d0ba6e66685 \\
   fd5830220539ae75c53a53ee25bd55ea831987170ef8923bc41df0aae282b8d2382fc3e77 

Analizando y separando apropiadamente esta cadena, se puede obtener los detalles de cada uno de los registros SCT:



Como puede comprobarse a través del análisis de la cadena OSCP, se puede ver cada uno de los registros SCT implementados.

Desde hace no mucho, también se puede realizar mediante el nuevo modificador "-ct" en OpenSSL:


openssl s_client -ct -connect sslanalyzer.comodoca.com:443

Para esto se debe crear el archivo "/usr/lib/ssl/nano ct_log_list.cnf" con la lista de servidores de transparencia que puedes ver aquí.

Destacamos que la verificación manual de OCSP no es sencilla y no ayuda a intentar convencer a los administradores a su adopción.

Sin embargo, y desde el punto de vista de seguridad OCSP resulta útil si un atacante intenta realizar un ataque MitM contra los certificados digitales y permite detectarlo a tiempo. Por eso, en nuestras soluciones antifraude, creemos necesarios la inclusión de mecanismos de revocación como CRL y OCSP/OCSP Stapling y transparencia de certificados que faciliten la detección de certificados revocados y permita la rápida detección de sitios fraudulentos.

También te puede interesar:
» Certificate Transparency
» Nueva herramienta: PySCTChecker
» Una aproximación práctica al Certificate Transparency
» Certificate Transparency Known Logs
» Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.0 
» Nginx: Enabling OCSP Stapling on Your Server
» Windows: Enabling OCSP Stapling on Your Server
» Why OCSP Stapling is the Best Method for Checking Certificate Validity

Cristian Borghello
Equipo de Innovación y Laboratorio de ElevenPaths
cristian.borghello@11paths.com
@crisborghe

2 comentarios: