Privacy OCSP: il responder vede un certificato, non il tuo URL

Un controllo di stato pone una domanda su un certificato, e la risposta viaggia su una connessione propria. Non contiene il percorso della pagina che ha portato al controllo. Le discussioni sulla privacy trattano spesso lo scambio come un flusso della cronologia di navigazione, il che sopravvaluta ciò che la richiesta trasporta e sottovaluta ciò che il responder può osservare. Leggi la richiesta prima di decidere cosa rivela.

La richiesta identifica un certificato

L’identificatore del certificato OCSP è costruito da una funzione hash, due hash dell’emittente e il numero di serie del certificato di destinazione, come specificato nella RFC 6960. Ogni campo punta a un certificato, non a un URL o a una richiesta HTTP.

Il percorso della pagina, la stringa di query e qualsiasi contenuto di modulo sono assenti dall’identificatore standard. L’affermazione che il responder riceva l’URL esatto richiede prove da altrove e non dal controllo del certificato. La richiesta nomina ancora un certificato e un istante, e il responder può sapere quale servizio lo presenta.

Ciò che manca è la pagina, non l’intero contesto. Un controllo del certificato più un servizio noto più una fonte ripetuta possono essere più informativi di ciascuno di essi da solo.

Cosa il responder può davvero osservare

Il responder vede la connessione che lo raggiunge: indirizzo di origine, temporizzazione e qualsiasi metadato di trasporto che la sua implementazione registri. Se la richiesta di stato segue la VPN, quella origine può essere l’uscita della VPN invece della rete di accesso dell’utente. Non dare per scontato che la richiesta di stato segua lo stesso percorso della richiesta della pagina solo perché entrambe appartengono alla stessa sessione del browser.

Controlla l’instradamento e il comportamento di verifica supportati dal client invece di dedurli da un’unica traccia. Un tunnel diviso può inviare le due richieste in direzioni diverse.

La risposta agganciata è l’altro schema comune. L’estensione TLS status_request della RFC 6066 consente a un server di allegare una risposta OCSP al proprio handshake, così il client convalida ciò che gli è stato dato invece di recuperare da sé lo stato per quella connessione. Quel cambiamento sposta l’osservatore. È il lato server a effettuare il recupero, e l’indirizzo del client non raggiunge mai il responder per quella connessione.

Lo stato può arrivare agganciato nell’handshake

Niente di tutto questo garantisce che un client non faccia mai un’altra richiesta di convalida. La costruzione della catena, la politica di stato e i meccanismi supportati variano secondo l’implementazione.

Un visualizzatore di certificati in un browser non descrive ogni sistema operativo e client VPN. La stessa cattura di rete può significare cose diverse con impostazioni di verifica diverse.

La cache infrange l’ipotesi di una pagina per una ricerca

La cache disaccoppia i caricamenti delle pagine dalle ricerche. Il browser può riutilizzare una risposta per un certo periodo, quindi una visualizzazione di pagina non implica una richiesta di rete.

L’errore opposto è altrettanto comune. Una risposta in cache non dice nulla su quando avverrà il prossimo aggiornamento, e il calendario degli aggiornamenti può non avere relazione con la pagina che si apre. Usa la documentazione attuale del client e la politica di verifica in vigore prima di attribuire una cattura a OCSP.

Una risposta di stato valida deve rispettare le regole di autenticità e freschezza del verificatore, e un HTTP 200 non è la stessa cosa di un buono stato. Un timeout non è una revoca. Questi esiti portano a comportamenti del client diversi e non dovrebbero essere ridotti a un solo errore.

Scelte di privacy che mantengono intatta la convalida

Quando la ricerca stessa è sensibile, discuti le opzioni di consegna e cache supportate con il proprietario del sistema. Non risolverlo disattivando il controllo di revoca o la convalida della catena.

Una traccia più silenziosa non è una connessione più sicura. Mantieni intatti l’identità del peer, la convalida della catena e la politica di revoca prevista, e cambia il percorso di consegna solo tramite un’opzione supportata dall’implementazione. Annota quale opzione è stata scelta e chi ne è responsabile.

Quando una ricerca compare inaspettatamente, nomina separatamente il destinatario, la rotta e l’operazione sul certificato. Un download dall’emittente, una query di stato e la richiesta della pagina sono tre eventi. Trattarli come uno solo rende imprecisa la revisione della privacy e nasconde quale parte ha davvero appreso qualcosa. Parti dai campi del protocollo e procedi verso l’esterno fino al percorso di rete.