El engrapado del Protocolo de estado de certificado en línea (OCSP) , formalmente conocido como la extensión de solicitud de estado de certificado TLS , es un estándar para verificar el estado de revocación de los certificados digitales X.509 . [1] Permite al presentador de un certificado asumir el costo de recursos involucrado en proporcionar respuestas del Protocolo de estado de certificado en línea (OCSP) al agregar ("engrapar") una respuesta OCSP con marca de tiempo firmada por la CA (autoridad de certificación) al protocolo de enlace TLS inicial , eliminando la necesidad de que los clientes se comuniquen con la CA, con el objetivo de mejorar tanto la seguridad como el rendimiento.
La implementación original de OCSP tiene varios problemas.
En primer lugar, puede suponer un coste significativo para las autoridades de certificación (AC), ya que les obliga a proporcionar respuestas a todos los clientes de un certificado determinado en tiempo real. Por ejemplo, cuando se emite un certificado para un sitio web con mucho tráfico, es probable que los servidores de las AC se vean afectados por enormes volúmenes de solicitudes OCSP que consultan la validez del certificado. [2]
Además, la verificación OCSP potencialmente daña la privacidad de los usuarios y ralentiza la navegación, ya que requiere que el cliente contacte a un tercero (la CA) para confirmar la validez de cada certificado que encuentra. [2] [3]
Además, si el cliente no logra conectarse a la CA para recibir una respuesta OCSP, entonces se ve obligado a decidir entre: (a) continuar la conexión de todos modos, frustrando el propósito de OCSP, o (b) terminar la conexión basándose en el supuesto de que hay un ataque, pero lo que podría resultar en advertencias falsas y bloqueos excesivos. [4]
El grapado de OCSP tiene como objetivo abordar estos problemas con la implementación original de OCSP. [5] [6]
El encuadernado OCSP resuelve ambos problemas de una manera que recuerda al ticket Kerberos . En un escenario de encuadernado, el propio titular del certificado consulta al servidor OCSP a intervalos regulares, obteniendo una respuesta OCSP firmada y con marca de tiempo . Cuando los visitantes del sitio intentan conectarse al sitio, esta respuesta se incluye ("encuaderna") con el protocolo de enlace TLS/SSL a través de la respuesta de extensión de Solicitud de estado del certificado (nota: el cliente TLS debe incluir explícitamente una extensión de Solicitud de estado del certificado en su mensaje de protocolo de enlace TLS/SSL ClientHello). [7]
Si bien puede parecer que permitir que el operador del sitio controle las respuestas de verificación permitiría que un sitio fraudulento emita una verificación falsa para un certificado revocado, las respuestas grapadas no se pueden falsificar ya que deben estar firmadas directamente por la autoridad de certificación , no por el servidor. [6] Si el cliente no recibe una respuesta grapada, simplemente se comunicará con el servidor OCSP por sí mismo. [4] Sin embargo, si el cliente recibe una respuesta grapada no válida, abortará la conexión. [1] El único riesgo aumentado del grapado OCSP es que la notificación de revocación de un certificado puede retrasarse hasta que caduque la última respuesta OCSP firmada.
Como resultado, los clientes siguen teniendo la garantía verificable de la autoridad de certificación de que el certificado es válido en ese momento (o lo era hace poco), pero ya no necesitan ponerse en contacto individualmente con el servidor OCSP. Esto significa que la mayor parte de la carga de recursos recae ahora sobre el titular del certificado. También significa que el software del cliente ya no necesita revelar los hábitos de navegación de los usuarios a ningún tercero. [2]
El rendimiento general también mejora: cuando el cliente obtiene la respuesta OCSP directamente de la CA, generalmente implica la búsqueda del nombre de dominio del servidor OCSP de la CA en el DNS, así como el establecimiento de una conexión con el servidor OCSP. Cuando se utiliza el encadenamiento OCSP, la información del estado del certificado se envía al cliente a través de un canal ya establecido, lo que reduce la sobrecarga y mejora el rendimiento. [5]
La extensión de solicitud de estado de certificado TLS se especifica en RFC 6066, Sección 8.
RFC 6961 define una extensión de solicitud de estado de certificado múltiple, que permite a un servidor enviar múltiples respuestas OCSP en el protocolo de enlace TLS.
Una propuesta preliminar para un campo de extensión X509v3, que expiró en abril de 2013, especificaba que un servidor compatible que presenta un certificado que lleva la extensión debe devolver un token OCSP válido en su respuesta si la extensión status_request se especifica en el saludo del cliente TLS. [8] La versión actual de la propuesta se ha ampliado para admitir extensiones TLS adicionales. [9] El desarrollador de TLS Adam Langley analizó la extensión en un artículo de abril de 2014 tras la reparación del error Heartbleed OpenSSL. [10]
La compatibilidad con el encuadernado de OCSP se está implementando progresivamente. El proyecto OpenSSL incluyó compatibilidad en su versión 0.9.8g con la ayuda de una subvención de la Fundación Mozilla .
Apache HTTP Server admite el encuadernado OCSP desde la versión 2.3.3, [11] el servidor web nginx desde la versión 1.3.7, [12] LiteSpeed Web Server desde la versión 4.2.4, [13] IIS de Microsoft desde Windows Server 2008 , [14] HAProxy desde la versión 1.5.0, [15] F5 Networks BIG-IP desde la versión 11.6.0, [16] KEMP LoadMasters desde la versión 7.2.37.1 y lighttpd desde la versión 1.4.56. [17]
Si bien muchos servidores web anuncian su compatibilidad con el grapado OCSP, las implementaciones no siempre son confiables. [18] Por ejemplo, cuando Apache consulta al servidor OCSP, en caso de una falla temporal, descartará la respuesta correcta almacenada en caché de la solicitud anterior y comenzará a brindar una respuesta incorrecta. [19] Nginx realiza una carga diferida de las respuestas OCSP, lo que significa que para las primeras solicitudes web no puede agregar la respuesta OCSP. [20]
En el lado del navegador, el grapado OCSP se implementó en Firefox 26, [4] [21] en Internet Explorer desde Windows Vista , [22] y Google Chrome en Linux, ChromeOS y Windows desde Vista. [23]
Para SMTP, el agente de transferencia de mensajes Exim admite el grapado OCSP tanto en modo cliente [24] como en modo servidor [25] .
El encadenamiento de OCSP está diseñado para reducir el costo de una validación de OCSP, tanto para el cliente como para el respondedor de OCSP, especialmente para sitios grandes que atienden a muchos usuarios simultáneos. Sin embargo, el encadenamiento de OCSP solo admite una respuesta de OCSP a la vez, lo que es insuficiente para cadenas de certificados con certificados de CA intermedios. [26] [27]
Esta limitación ha sido abordada por la Extensión de solicitud de estado de certificado múltiple, especificada en RFC 6961. Agrega soporte para enviar múltiples respuestas OCSP. [28]
TLSv1.3 elimina automáticamente esta limitación, lo que hace que la compatibilidad del navegador con RFC 6961 sea irrelevante, ya que cada vez más servidores web dejan de admitir TLS 1.2. Con TLS 1.2, un servidor solo puede enviar una respuesta encapsulada, la respuesta OCSP asociada con el certificado final. Con TLS 1.3, un servidor puede enviar múltiples respuestas OCSP, normalmente una para cada certificado de la cadena de certificados. [29]