Privatnost OCSP-a: odgovarač vidi certifikat, a ne vaš URL
OCSP zahtjev identificira certifikat i trenutak u vremenu, a ne putanju stranice. Ugrađivanje, keširanje i politika klijenta odlučuju ko posmatra provjeru.
Provjera statusa postavlja jedno pitanje o jednom certifikatu, a odgovor putuje vlastitom vezom. Ona ne sadrži putanju stranice koja je dovela do provjere. Rasprave o privatnosti često tretiraju tu razmjenu kao tok historije pregledanja, što precjenjuje šta zahtjev nosi i podcjenjuje šta odgovarač može posmatrati. Pročitajte zahtjev prije nego što odlučite šta on otkriva.
Zahtjev identificira jedan certifikat
Identifikator certifikata OCSP gradi se od hash funkcije, dva hasha izdavaoca i serijskog broja ciljnog certifikata, kako je navedeno u RFC 6960. Svako polje pokazuje na jedan certifikat, a ne na URL ili HTTP zahtjev.
Putanja stranice, upitni niz i bilo koji sadržaj obrasca izostaju iz standardnog identifikatora. Tvrdnja da odgovarač prima tačan URL zahtijeva dokaz odnekud drugdje, ne iz provjere certifikata. Zahtjev i dalje imenuje certifikat i trenutak, a odgovarač može znati koja usluga ga predstavlja.
Ono što nedostaje je stranica, a ne cijeli kontekst. Provjera certifikata plus poznata usluga plus ponovljeni izvor mogu biti informativniji od bilo čega od toga pojedinačno.
Šta odgovarač zapravo može posmatrati
Odgovarač vidi vezu koja do njega stiže: izvorišnu adresu, tajming i sve transportne metapodatke koje njegovo postavljanje bilježi. Ako zahtjev za status ide kroz VPN, taj izvor može biti VPN izlaz, a ne korisnikova pristupna mreža. Ne pretpostavljajte da zahtjev za status ide istim putem kao zahtjev za stranicu samo zato što oba pripadaju jednoj sesiji preglednika.
Provjerite podržano usmjeravanje i ponašanje pri verifikaciji na klijentu umjesto da to zaključujete iz jednog traga. Podijeljeni tunel može poslati dva zahtjeva u različitim smjerovima.
Ugrađeni odgovor je drugi uobičajen obrazac. TLS ekstenzija status_request iz RFC 6066 omogućava serveru da prikači OCSP odgovor na vlastito rukovanje, pa klijent verificira ono što mu je dato umjesto da sam pribavlja status za tu vezu. Ta promjena mijenja posmatrača. Pribavljanje radi serverska strana, a klijentova vlastita adresa nikada ne stiže do odgovarača za tu vezu.
Status može stići ugrađen u rukovanje
Ništa od ovoga ne garantuje da klijent nikada neće uputiti još jedan zahtjev za verifikaciju. Izgradnja lanca, politika statusa i podržani mehanizmi razlikuju se po implementaciji.
Pregled certifikata u jednom pregledniku nije opis svakog operativnog sistema i VPN klijenta. Isti mrežni snimak može značiti različite stvari pod različitim postavkama verifikacije.
Keširanje ruši pretpostavku jedna stranica jedno traženje
Keširanje razdvaja učitavanje stranica od traženja. Preglednik može ponovno koristiti odgovor neko vrijeme, pa jedan pregled stranice ne znači jedan mrežni zahtjev.
Suprotna greška je jednako česta. Keširani odgovor ne govori ništa o tome kada će se dogoditi sljedeće osvježavanje, a raspored osvježavanja može biti nepovezan sa stranicom koja se otvara. Koristite trenutnu dokumentaciju klijenta i važeću politiku verifikacije prije nego što snimak pripišete OCSP-u.
Valjan odgovor statusa mora zadovoljiti pravila autentičnosti i svježine verifikatora, a HTTP 200 nije isto što i dobar status. Istek vremena nije opoziv. Ti ishodi vode različitom ponašanju klijenta i ne treba ih svoditi na jednu grešku.
Izbori privatnosti koji čuvaju verifikaciju netaknutom
Tamo gdje je samo traženje osjetljivo, razgovarajte o podržanim opcijama dostave i keširanja sa vlasnikom sistema. Ne rješavajte to isključivanjem provjere opoziva ili verifikacije lanca.
Tiši trag nije sigurnija veza. Sačuvajte netaknutima identitet druge strane, verifikaciju lanca i predviđenu politiku opoziva, a put dostave mijenjajte samo kroz opciju koju postavljanje podržava. Zabilježite koja je opcija odabrana i ko je vlasnik.
Kada se traženje pojavi neočekivano, imenujte primaoca, rutu i operaciju s certifikatom odvojeno. Preuzimanje od izdavaoca, upit statusa i zahtjev za stranicu tri su događaja. Tretiranje ih kao jednoga čini pregled privatnosti netačnim i skriva koja je strana zapravo nešto saznala. Pođite od polja protokola i radite prema van ka mrežnoj putanji.