Privadesa d’OCSP: el responedor veu un certificat, no la vostra URL

Una comprovació d’estat fa una pregunta sobre un certificat, i la resposta viatja per la seva pròpia connexió. No conté el camí de la pàgina que va portar a la comprovació. Les discussions sobre privadesa sovint tracten l’intercanvi com un fil d’historial de navegació, cosa que exagera el que porta la sol·licitud i subestima el que el responedor pot observar. Llegeixi la sol·licitud abans de decidir què revela.

La sol·licitud identifica un certificat

L’identificador de certificat OCSP es construeix a partir d’una funció hash, dos hash de l’emissor i el número de sèrie del certificat objectiu, tal com especifica la RFC 6960. Cada camp apunta a un certificat, no a una URL ni a una sol·licitud HTTP.

El camí de la pàgina, la cadena de consulta i qualsevol contingut de formulari són absents de l’identificador estàndard. L’afirmació que el responedor rep la URL exacta necessita proves d’algun lloc que no sigui la comprovació del certificat. La sol·licitud encara anomena un certificat i un moment, i el responedor pot saber quin servei el presenta.

El que falta és la pàgina, no tot el context. Una comprovació de certificat més un servei conegut més una font repetida poden ser més informatives que qualsevol d’ells per separat.

Què pot observar realment el responedor

El responedor veu la connexió que li arriba: adreça d’origen, temporització i qualsevol metadada de transport que registri el seu desplegament. Si la sol·licitud d’estat segueix la VPN, aquest origen pot ser la sortida de la VPN i no la xarxa d’accés de l’usuari. No assumeixi que la sol·licitud d’estat pren el mateix camí que la sol·licitud de la pàgina només perquè totes dues pertanyen a una sessió del navegador.

Comprovi l’encaminament i el comportament de verificació que admet el client en lloc d’inferir-los d’un sol rastre. Un túnel dividit pot enviar les dues sol·licituds en direccions diferents.

La resposta engrapada és l’altre patró habitual. L’extensió TLS status_request de la RFC 6066 permet que un servidor adjunti una resposta OCSP al seu propi handshake, de manera que el client valida el que se li ha donat en lloc d’obtenir l’estat per a aquella connexió. Aquest canvi altera l’observador. És el costat del servidor qui fa l’obtenció, i l’adreça pròpia del client mai no arriba al responedor per a aquella connexió.

L’estat pot arribar engrapat al handshake

Res d’això no garanteix que un client no faci mai cap altra sol·licitud de validació. La construcció de la cadena, la política d’estat i els mecanismes admesos varien segons la implementació.

Un visor de certificats en un navegador no descriu cada sistema operatiu i client de VPN. La mateixa captura de xarxa pot significar coses diferents amb configuracions de verificació diferents.

La memòria cau trenca la suposició d’una pàgina per consulta

La memòria cau desacobla les càrregues de pàgina de les consultes. El navegador pot reutilitzar una resposta durant un període, així que una visualització de pàgina no implica una sol·licitud de xarxa.

L’error oposat és igual de comú. Una resposta en memòria cau no diu res sobre quan es farà la propera actualització, i el calendari d’actualització pot no tenir relació amb la pàgina que s’obre. Utilitzi la documentació actual del client i la política de verificació vigent abans d’atribuir una captura a OCSP.

Una resposta d’estat vàlida ha de complir les regles d’autenticitat i frescor del verificador, i un HTTP 200 no és el mateix que un bon estat. Un temps d’espera no és una revocació. Aquests resultats porten a comportaments diferents del client i no s’han de reduir a un sol error.

Opcions de privadesa que mantenen la validació intacta

Quan la consulta mateixa és sensible, parli de les opcions de lliurament i memòria cau admeses amb el propietari del sistema. No ho resolgui desactivant la comprovació de revocació o la validació de la cadena.

Un rastre més silenciós no és una connexió més segura. Mantingui intactes la identitat del parell, la validació de la cadena i la política de revocació prevista, i canviï el camí de lliurament només mitjançant una opció que el desplegament admeti. Anoti quina opció s’ha triat i qui en és responsable.

Quan una consulta apareix inesperadament, anomeni el receptor, la ruta i l’operació de certificat per separat. Una descàrrega d’emissor, una consulta d’estat i la sol·licitud de la pàgina són tres esdeveniments. Tractar-los com un de sol fa imprecisa la revisió de privadesa i amaga quina part va aprendre realment alguna cosa. Comenci pels camps del protocol i avanci cap a fora fins al camí de xarxa.