OCSP Stapling y Certificate Transparency

Las listas de revocación de certificados (CRL) son archivos publicados por las CA que enumeran todos los certificados revocados. Las CRL presentan varios problemas: aumentan de tamaño con el tiempo, los clientes deben descargarlas por completo, tienen una vigencia limitada (se publican según un calendario) y, cuando fallaba la descarga de la CRL, los navegadores históricamente ignoraban el error y aceptaban los certificados, lo que hacía que la revocación no fuera fiable en la práctica.

El protocolo de estado de certificados en línea (OCSP, RFC 6960) permite a los clientes consultar en tiempo real el respondedor OCSP de una CA para conocer el estado de revocación de un certificado concreto. Una respuesta OCSP indica que el certificado está en estado "good", "revoked" o "unknown" y está firmada por la CA. Esto resulta más eficiente que descargar una CRL completa.

El OCSP estándar presenta un problema importante de privacidad: el cliente debe ponerse en contacto con el respondedor OCSP de la CA e indicar el número de serie del certificado que se está comprobando. Esto revela a la CA, o a un observador de la red, qué sitios web visita el usuario y cuándo. Se crea así un mecanismo de vigilancia que vulnera la privacidad del usuario en el nivel de la autoridad certificadora.

El OCSP stapling (RFC 6066) resuelve el problema de privacidad haciendo que el servidor obtenga por adelantado la respuesta OCSP de la CA y la almacene en caché. Durante el handshake TLS, el servidor incorpora esta respuesta almacenada en el handshake y la entrega directamente al cliente. El cliente obtiene un estado de revocación actualizado sin ponerse en contacto directamente con la CA.

La configuración de OCSP stapling en Nginx requiere incluir: "ssl_stapling on; ssl_stapling_verify on; resolver 8.8.8.8;" en el bloque del servidor. La directiva ssl_certificate_by_lua_block o la directiva ssl_trusted_certificate proporciona la cadena para la verificación. Apache requiere "SSLUseStapling on" en el VirtualHost. Ambos servidores almacenan la respuesta en caché y la actualizan antes de que expire.

La extensión OCSP Must-Staple de X.509 (RFC 7633) indica a los navegadores que el servidor de este certificado siempre incluirá una respuesta OCSP. Si un navegador se conecta al servidor y no recibe una respuesta adjunta, rechaza la conexión. Esto impide que un atacante que posee un certificado revocado bloquee las respuestas OCSP para forzar un comportamiento de soft-fail.

La Transparencia de certificados (CT) es un sistema en el que todas las CA de confianza pública deben registrar cada certificado que emiten en registros públicos, auditables y de solo adición antes de entregar el certificado. Estos registros permiten a los propietarios de dominios, investigadores y servicios de monitorización detectar certificados emitidos incorrectamente u obtenidos de forma fraudulenta para cualquier dominio.

Cuando una CA envía un certificado a un registro de CT, el registro devuelve una marca de tiempo de certificado firmado (SCT). La SCT es una promesa firmada criptográficamente de que el certificado se ha registrado. Las SCT se incluyen en el propio certificado, se envían mediante una extensión TLS o se adjuntan en la respuesta OCSP. Chrome exige al menos dos SCT para confiar en el certificado.

Google Chrome exige la Transparencia de certificados para todos los certificados TLS de confianza pública desde abril de 2018. Chrome rechaza los certificados sin SCT válidas con un error de certificado. Este requisito impone de forma efectiva el registro en CT a todas las CA principales, ya que una CA cuyos certificados Chrome rechaza no puede operar como CA pública.

Los registros de CT permiten a cualquiera monitorizar los certificados emitidos para su dominio. Servicios como crt.sh y CT Monitor de Facebook permiten a los propietarios de dominios buscar en todos los registros de CT certificados que contengan su dominio en los campos subject o SAN. La emisión no autorizada de certificados (por ejemplo, por una CA comprometida o mediante un secuestro de BGP) puede detectarse en cuestión de horas.

Los registros de CT son operados por varias organizaciones independientes, como Google (Argon, Xenon), Cloudflare (Nimbus), DigiCert, Sectigo y otras. La existencia de varios operadores de registros impide que una sola entidad suprima un certificado registrado. Los navegadores exigen SCT de registros incluidos en su lista aprobada, lo que mantiene el control de calidad sobre los registros en los que se confía.

Las CRL son grandes y se quedan obsoletas; OCSP proporciona una revocación en tiempo real, pero filtra datos de navegación a las CA. El OCSP stapling entrega el estado de revocación obtenido por adelantado durante el handshake TLS, preservando la privacidad. OCSP Must-Staple impide eludir la comprobación mediante soft-fail. La Transparencia de certificados registra todos los certificados emitidos y permite detectar certificados emitidos incorrectamente mediante SCT. Chrome exige CT desde 2018.