Privacidad de OCSP: el respondedor ve un certificado, no tu URL

Una comprobación de estado plantea una pregunta sobre un certificado, y la respuesta viaja por su propia conexión. No contiene la ruta de la página que llevó a la comprobación. Los debates sobre privacidad suelen tratar el intercambio como un flujo del historial de navegación, lo que exagera lo que lleva la solicitud y subestima lo que el respondedor puede observar. Lea la solicitud antes de decidir qué revela.

La solicitud identifica un certificado

El identificador de certificado OCSP se construye a partir de una función hash, dos hashes del emisor y el número de serie del certificado objetivo, según especifica la RFC 6960. Cada campo apunta a un certificado, no a una URL ni a una solicitud HTTP.

La ruta de la página, la cadena de consulta y cualquier contenido de formulario están ausentes del identificador estándar. La afirmación de que el respondedor recibe la URL exacta necesita pruebas de otro lugar que no sea la comprobación del certificado. La solicitud sigue nombrando un certificado y un momento, y el respondedor puede saber qué servicio lo presenta.

Lo que falta es la página, no todo el contexto. Una comprobación de certificado más un servicio conocido más una fuente repetida pueden ser más informativas que cualquiera de ellas por separado.

Lo que el respondedor puede observar realmente

El respondedor ve la conexión que le llega: dirección de origen, temporización y cualquier metadato de transporte que registre su despliegue. Si la solicitud de estado sigue la VPN, esa fuente puede ser la salida de la VPN en lugar de la red de acceso del usuario. No suponga que la solicitud de estado toma el mismo camino que la solicitud de la página solo porque ambas pertenecen a una sesión del navegador.

Compruebe el enrutamiento y el comportamiento de verificación que admite el cliente en lugar de inferirlos de un solo rastro. Un túnel dividido puede enviar las dos solicitudes en direcciones diferentes.

La respuesta engrapada es el otro patrón habitual. La extensión TLS status_request de la RFC 6066 permite que un servidor adjunte una respuesta OCSP a su propio handshake, de modo que el cliente valida lo que se le ha dado en lugar de obtener el estado para esa conexión. Ese cambio altera al observador. El lado del servidor hace la obtención, y la dirección propia del cliente nunca llega al respondedor para esa conexión.

El estado puede llegar engrapado en el handshake

Nada de esto garantiza que un cliente nunca haga otra solicitud de validación. La construcción de la cadena, la política de estado y los mecanismos admitidos varían según la implementación.

Un visor de certificados en un navegador no describe cada sistema operativo y cliente de VPN. La misma captura de red puede significar cosas distintas con ajustes de verificación distintos.

La caché rompe la suposición de una página por consulta

La caché desacopla las cargas de página de las consultas. El navegador puede reutilizar una respuesta durante un periodo, así que una visita a la página no implica una solicitud de red.

El error opuesto es igual de común. Una respuesta en caché no dice nada sobre cuándo ocurrirá la próxima actualización, y el calendario de actualización puede no tener relación con la página que se abre. Use la documentación actual del cliente y la política de verificación vigente antes de atribuir una captura a OCSP.

Una respuesta de estado válida debe cumplir las reglas de autenticidad y frescura del verificador, y un HTTP 200 no es lo mismo que un buen estado. Un tiempo de espera no es una revocación. Esos resultados llevan a comportamientos distintos del cliente y no deberían reducirse a un solo error.

Opciones de privacidad que mantienen intacta la validación

Cuando la consulta misma es sensible, hable de las opciones de entrega y caché admitidas con el propietario del sistema. No lo resuelva desactivando la comprobación de revocación o la validación de la cadena.

Un rastro más silencioso no es una conexión más segura. Mantenga intactos la identidad del par, la validación de la cadena y la política de revocación prevista, y cambie la ruta de entrega solo mediante una opción que el despliegue admita. Anote qué opción se eligió y quién es su responsable.

Cuando una consulta aparece inesperadamente, nombre el receptor, la ruta y la operación de certificado por separado. Una descarga del emisor, una consulta de estado y la solicitud de la página son tres eventos. Tratarlos como uno hace imprecisa la revisión de privacidad y oculta qué parte aprendió algo realmente. Empiece por los campos del protocolo y avance hacia fuera hasta la ruta de red.