Zasebnost pri OCSP: odzivnik vidi potrdilo, ne vašega URL

Preverjanje stanja postavi eno vprašanje o enem potrdilu, odgovor pa potuje po svoji povezavi. Ne vsebuje poti strani, ki je pripeljala do preverjanja. Razprave o zasebnosti to izmenjavo pogosto obravnavajo kot tok zgodovine brskanja, kar preceni, kaj zahteva nosi, in podceni, kaj lahko odzivnik opazuje. Preberite zahtevo, preden se odločite, kaj razkriva.

Zahteva prepozna eno potrdilo

Identifikator potrdila OCSP je sestavljen iz zgoščevalne funkcije, dveh zgoščenih vrednosti izdajatelja in serijske številke ciljnega potrdila, kot določa RFC 6960. Vsako polje kaže na eno potrdilo, ne na URL ali zahtevo HTTP.

Pot strani, poizvedbeni niz in morebitna vsebina obrazca v standardnem identifikatorju manjkajo. Trditev, da odzivnik prejme natančen URL, potrebuje dokaz od drugod, ne iz preverjanja potrdila. Zahteva še vedno imenuje potrdilo in trenutek, odzivnik pa lahko ve, katera storitev ga predstavi.

Manjka stran, ne celoten kontekst. Preverjanje potrdila skupaj z znano storitvijo skupaj s ponavljajočim se virom lahko pove več kot katero koli od njih samo.

Kaj lahko odzivnik v resnici opazuje

Odzivnik vidi povezavo, ki pride do njega: naslov vira, čas in vse transportne metapodatke, ki jih zabeleži njegova namestitev. Če zahteva za stanje sledi VPN, je ta vir lahko izhod VPN, ne uporabnikovo dostopovno omrežje. Ne predpostavljajte, da zahteva za stanje poteka po isti poti kot zahteva za stran, samo zato ker obe pripadata eni seji brskalnika.

Preverite podprto usmerjanje in vedenje preverjanja pri odjemalcu, namesto da bi ju sklepali iz ene sledi. Razdeljeni tunel lahko pošlje obe zahtevi v različnih smereh.

Pripet odgovor je drug pogost vzorec. Razširitev TLS status_request iz RFC 6066 omogoča strežniku, da pritrdi odgovor OCSP na svoj rokovanje, zato odjemalec preveri, kar je prejel, namesto da bi sam pridobil stanje za to povezavo. Ta premik spremeni opazovalca. Pridobivanje opravi strežniška stran, lastni naslov odjemalca pa za to povezavo nikoli ne doseže odzivnika.

Stanje lahko prispe pripeto v rokovanju

Nič od tega ne zagotavlja, da odjemalec nikoli ne bo poslal še ene zahteve za preverjanje. Gradnja verige, politika stanja in podprti mehanizmi se razlikujejo glede na izvedbo.

Pregledovalnik potrdil v enem brskalniku ni opis vsakega operacijskega sistema in odjemalca VPN. Isti omrežni posnetek lahko pri različnih nastavitvah preverjanja pomeni različne stvari.

Predpomnjenje podre predpostavko ena stran eno iskanje

Predpomnjenje ločuje nalaganje strani od iskanj. Brskalnik lahko odgovor nekaj časa ponovno uporabi, zato en ogled strani ne pomeni ene omrežne zahteve.

Nasprotna napaka je enako pogosta. Predpomnjeni odgovor ne pove ničesar o tem, kdaj bo naslednje osveževanje, urnik osveževanja pa morda ni povezan s stranjo, ki se odpira. Preden posnetek pripišete OCSP, uporabite trenutno dokumentacijo odjemalca in veljavno politiko preverjanja.

Veljaven odgovor o stanju mora izpolnjevati pravila pristnosti in svežine preverjevalnika, HTTP 200 pa ni isto kot dobro stanje. Časovna omejitev ni preklic. Ti izidi vodijo v različno vedenje odjemalca in jih ne bi smeli stisniti v eno napako.

Izbire zasebnosti, ki ohranijo preverjanje nedotaknjeno

Kjer je iskanje samo občutljivo, se o podprtih možnostih dostave in predpomnjenja pogovorite z lastnikom sistema. Tega ne rešujte z izklopom preverjanja preklica ali preverjanja verige.

Tišja sled ni varnejša povezava. Ohranite nedotaknjene identiteto partnerja, preverjanje verige in predvideno politiko preklica, pot dostave pa spremenite le z možnostjo, ki jo podpira namestitev. Zabeležite, katera možnost je bila izbrana in kdo jo upravlja.

Ko se iskanje pojavi nepričakovano, ločeno navedite prejemnika, pot in operacijo s potrdilom. Prenos od izdajatelja, poizvedba stanja in zahteva strani so trije dogodki. Če jih obravnavate kot enega, je pregled zasebnosti netočen in skrije, katera stran se je v resnici česa naučila. Začnite pri poljih protokola in se pomikajte navzven do omrežne poti.