Resumen

  • OCSP stapling incorpora a la negociación TLS una prueba firmada sobre el estado del certificado y evita una consulta adicional del cliente al respondedor.
  • El estado good tiene un significado deliberadamente limitado, mientras que thisUpdate, nextUpdate y producedAt delimitan la vigencia de la afirmación.
  • Una firma válida y una respuesta todavía aceptable no indican cuándo la obtuvo cada punto de terminación ni si todos han instalado información de revocación posterior.
  • La operación necesita un registro verificable de actualización de la revocación que una el certificado y el respondedor con los tiempos de estado, la cohorte desplegada y el momento de la decisión del cliente.

Pensemos en un incidente hipotético, sin atribuirlo a un proveedor ni presentarlo como un hecho ocurrido. Una autoridad de certificación produce una respuesta OCSP firmada con estado good. Un punto de terminación la recupera y la guarda en caché. Más tarde se revoca el certificado. Un segundo punto recibe una respuesta nueva, mientras el primero sigue presentando la anterior dentro de su intervalo temporal. El cliente puede validar ese objeto antiguo conforme a su política y, aun así, saber menos de lo que el operador quiere decir cuando afirma que «la revocación ya se aplica en todas partes».

La distinción empieza en el propio protocolo. El RFC 6960 define OCSP como un mecanismo para conocer el estado de un certificado sin descargar una lista completa de revocación. Las respuestas definitivas están firmadas, identifican al respondedor y contienen un estado para un certificado concreto. Es una prueba sustancialmente mejor que una señal sin autenticar. Pero sigue siendo una afirmación sobre un objeto, un contexto emisor y una ventana temporal determinados.

La palabra good se presta especialmente a conclusiones excesivas. En su alcance mínimo indica que no figura como revocado ningún certificado con el número de serie consultado y situado en ese momento dentro de su período de validez. La norma limita de inmediato esa interpretación: no significa necesariamente que el certificado se haya emitido alguna vez ni que el momento de producción de la respuesta se encuentre dentro de la validez del certificado. Las extensiones pueden aportar afirmaciones adicionales, pero el estado básico no certifica por sí solo que el certificado, el servidor, la cuenta y la autoridad actual del servicio sean correctos.

Tres tiempos hacen visible este límite. thisUpdate señala el instante más reciente en que el respondedor sabía que el estado indicado era correcto. nextUpdate indica cuándo, como máximo, habrá información nueva. producedAt registra cuándo se firmó la respuesta. No son valores intercambiables. Una respuesta firmada hace poco puede describir un estado conocido anteriormente, y un nextUpdate futuro no prueba que un cambio operativo posterior ya haya llegado a todas las cachés y puntos de terminación.

Antes de aceptar una respuesta firmada, la parte que confía en ella debe comprobar que corresponde al certificado solicitado, validar la firma, establecer que el firmante está autorizado, considerar thisUpdate suficientemente reciente y, cuando exista, verificar que nextUpdate sea posterior a la hora actual. Estos controles demuestran que el objeto es auténtico y aceptable según la política local. No proporcionan un inventario del camino de distribución que llevó el objeto hasta el servidor que lo presenta.

El RFC 6066 describe la extensión TLS status_request, con la que el servidor puede enviar una respuesta OCSP junto a su certificado. El estado llega dentro de la negociación y el cliente no necesita contactar al respondedor durante ese proceso. Si recibe la respuesta, debe comprobarla e interrumpir la negociación cuando no sea satisfactoria. OCSP stapling mejora la entrega de la prueba; no amplía el significado original de esa prueba.

La separación se vuelve crítica en un servicio distribuido. Un mismo certificado puede estar desplegado en numerosas entradas, clústeres de terminación o regiones de entrega. Cada grupo puede recuperar, almacenar y sustituir sus objetos de estado a través de un camino operativo diferente. La respuesta OCSP contiene el conocimiento y los tiempos del respondedor, no la lista completa de puntos activos, su versión de configuración, el resultado de la última descarga ni la confirmación de que el reemplazo terminó. «La respuesta valida» y «el estado de revocación más reciente se aplica en todos los puntos» son afirmaciones distintas.

El RFC 7633 añade otro mecanismo de control. Un certificado puede declarar una función TLS obligatoria, entre ellas status_request. Un cliente compatible puede rechazar una configuración que no suministre el estado requerido. Esto resuelve una ambigüedad importante: sin la declaración, la ausencia de una respuesta OCSP incorporada no permite concluir si el servidor legítimo no admite la función o si la está omitiendo. En los supuestos definidos por la norma, la validación aún puede apoyarse en otra fuente. Must-Staple exige que se entregue una prueba, pero no rejuvenece una respuesta antigua, no evita toda emisión fraudulenta y no demuestra que el operador siga controlando la aplicación situada detrás del certificado.

El error operativo consiste en resumir cuatro estados en un único indicador verde. La cadena del certificado puede validar. La firma OCSP puede validar. La respuesta puede cumplir la política temporal del cliente. Aun así, un punto de terminación puede encontrarse por detrás del estado disponible más reciente o fuera de la cohorte que el operador cree actualizada. Un panel que solo registra «respuesta OCSP presente» no distingue esas situaciones.

Un recibo útil de frescura de revocación conservaría la cadena completa. Identificaría el número de serie y la cadena de certificados completa, la identidad del respondedor, el estado devuelto, thisUpdate, nextUpdate, producedAt, la hora de recuperación, la cohorte que instaló el objeto, la política de validación y el momento de la decisión. También registraría fallos de sustitución y mantendría separadas la autenticación del transporte y la autorización actual de la aplicación.

Esto no convierte OCSP stapling en una defensa débil. Aclara su alcance operativo. Puede reducir la exposición de privacidad del cliente, la latencia y la dependencia de una consulta a un tercero en tiempo real. Must-Staple puede hacer accionable la ausencia de prueba. La firma y los controles de tiempo autentican una afirmación acotada. El fallo aparece cuando esas ventajas se transforman en una garantía que el objeto nunca contenía.

La decisión no consiste, por tanto, en confiar o no en OCSP como concepto. Consiste en decidir qué afirmación operacional puede satisfacer una respuesta OCSP incorporada. Para validar una negociación, una respuesta auténtica y suficientemente reciente puede resultar decisiva. Para asegurar que la revocación alcanzó todos los puntos activos, el operador necesita además evidencia de despliegue. Para autorizar una acción de aplicación, el servicio necesita su propia decisión vigente de identidad y política, no una autoridad prestada por el objeto de estado del certificado.

Fuentes

RFC 6960 — Online Certificate Status Protocol; RFC 6066 — extensiones TLS; RFC 7633 — extensión TLS Feature.