Confidențialitate OCSP: respondența vede un certificat, nu URL-ul dvs.

O verificare de stare pune o întrebare despre un certificat, iar răspunsul călătorește pe propria conexiune. Nu conține calea paginii care a dus la verificare. Discuțiile despre confidențialitate tratează adesea schimbul ca un flux al istoricului de navigare, ceea ce supraestimează ce transportă cererea și subestimează ce poate observa respondența. Citiți cererea înainte de a decide ce dezvăluie.

Cererea identifică un certificat

Identificatorul de certificat OCSP este construit dintr-o funcție hash, două hashuri ale emitentului și numărul de serie al certificatului țintă, conform RFC 6960. Fiecare câmp indică un certificat, nu un URL sau o cerere HTTP.

Calea paginii, șirul de interogare și orice conținut de formular lipsesc din identificatorul standard. Afirmația că respondența primește URL-ul exact necesită dovezi din altă parte decât verificarea certificatului. Cererea numește în continuare un certificat și un moment, iar respondența poate ști ce serviciu îl prezintă.

Ceea ce lipsește este pagina, nu întregul context. O verificare de certificat plus un serviciu cunoscut plus o sursă repetată pot fi mai informative decât oricare dintre ele singură.

Ce poate observa de fapt respondența

Respondența vede conexiunea care ajunge la ea: adresa sursă, momentul și orice metadate de transport pe care le înregistrează implementarea sa. Dacă cererea de stare urmează VPN-ul, acea sursă poate fi ieșirea VPN, nu rețeaua de acces a utilizatorului. Nu presupuneți că cererea de stare urmează aceeași cale ca cererea paginii doar pentru că ambele aparțin aceleiași sesiuni de browser.

Verificați rutarea și comportamentul de validare acceptate de client în loc să le deduceți dintr-o singură urmă. Un tunel divizat poate trimite cele două cereri în direcții diferite.

Răspunsul fixat este celălalt model obișnuit. Extensia TLS status_request din RFC 6066 permite unui server să atașeze un răspuns OCSP la propriul handshake, astfel încât clientul validează ce i s-a dat în loc să obțină singur starea pentru acea conexiune. Această schimbare schimbă observatorul. Partea serverului face obținerea, iar adresa proprie a clientului nu ajunge niciodată la respondență pentru acea conexiune.

Starea poate sosi fixată în handshake

Nimic din toate acestea nu garantează că un client nu va face niciodată altă cerere de validare. Construirea lanțului, politica de stare și mecanismele acceptate variază în funcție de implementare.

Un vizualizator de certificate dintr-un browser nu descrie fiecare sistem de operare și client VPN. Aceeași captură de rețea poate însemna lucruri diferite cu setări de verificare diferite.

Stocarea în cache sparge presupunerea o pagină o căutare

Stocarea în cache decuplează încărcările de pagină de căutări. Browserul poate reutiliza un răspuns pentru o perioadă, deci o vizualizare de pagină nu implică o cerere de rețea.

Greșeala opusă este la fel de frecventă. Un răspuns din cache nu spune nimic despre când va avea loc următoarea reîmprospătare, iar programul de reîmprospătare poate să nu aibă legătură cu pagina care se deschide. Folosiți documentația actuală a clientului și politica de verificare în vigoare înainte de a atribui o captură OCSP.

Un răspuns de stare valid trebuie să îndeplinească regulile de autenticitate și prospețime ale verificatorului, iar un HTTP 200 nu este același lucru cu o stare bună. Un timeout nu este o revocare. Aceste rezultate duc la comportamente diferite ale clientului și nu ar trebui reduse la o singură eroare.

Opțiuni de confidențialitate care păstrează validarea intactă

Acolo unde căutarea în sine este sensibilă, discutați opțiunile de livrare și cache acceptate cu proprietarul sistemului. Nu o rezolvați dezactivând verificarea revocării sau validarea lanțului.

O urmă mai silențioasă nu este o conexiune mai sigură. Păstrați intacte identitatea partenerului, validarea lanțului și politica de revocare vizată, și schimbați calea de livrare doar printr-o opțiune acceptată de implementare. Notați ce opțiune a fost aleasă și cine este responsabil de ea.

Când o căutare apare neașteptat, numiți separat destinatarul, ruta și operația asupra certificatului. O descărcare de la emitent, o interogare de stare și cererea paginii sunt trei evenimente. Tratarea lor ca unul singur face evaluarea confidențialității inexactă și ascunde ce parte a aflat cu adevărat ceva. Începeți cu câmpurile protocolului și mergeți spre exterior până la calea de rețea.