OCSP-personvern: svareren ser et sertifikat, ikke URL-en din

En statuskontroll stiller ett spørsmål om ett sertifikat, og svaret reiser på sin egen tilkobling. Den inneholder ikke sidebanen som førte til kontrollen. Personverndiskusjoner behandler ofte utvekslingen som en strøm fra nettleserhistorikken, noe som overdriver det forespørselen bærer og undervurderer det svareren kan observere. Les forespørselen før du avgjør hva den avslører.

Forespørselen identifiserer ett sertifikat

OCSP-sertifikatidentifikatoren bygges av en hashfunksjon, to hasher fra utstederen og serienummeret til målsertifikatet, som angitt i RFC 6960. Hvert felt peker på ett sertifikat, ikke på en URL eller en HTTP-forespørsel.

Sidebanen, spørringsstrengen og eventuelt skjemainnhold mangler i standardidentifikatoren. Påstanden om at svareren mottar den nøyaktige URL-en, krever bevis fra et annet sted enn sertifikatkontrollen. Forespørselen nevner fortsatt et sertifikat og et øyeblikk, og svareren kan vite hvilken tjeneste som presenterer det.

Det som mangler, er siden, ikke hele konteksten. En sertifikatkontroll pluss en kjent tjeneste pluss en gjentatt kilde kan være mer opplysende enn noen av dem alene.

Hva svareren faktisk kan observere

Svareren ser tilkoblingen som når den: kildeadresse, tidspunkt og alle transportmetadata som utplasseringen registrerer. Hvis statusforespørselen følger VPN-en, kan den kilden være VPN-utgangen i stedet for brukerens aksessnett. Ikke anta at statusforespørselen tar samme vei som sideforespørselen bare fordi begge tilhører én nettleserøkt.

Kontroller klientens støttede ruting og verifiseringsatferd i stedet for å utlede den fra ett enkelt spor. En delt tunnel kan sende de to forespørslene i ulike retninger.

Et festet svar er det andre vanlige mønsteret. TLS-utvidelsen status_request fra RFC 6066 lar en server feste et OCSP-svar til sin egen håndtrykk, slik at klienten validerer det den fikk i stedet for å hente status selv for den tilkoblingen. Det skiftet endrer observatøren. Det er serversiden som henter, og klientens egen adresse når aldri svareren for den tilkoblingen.

Status kan ankomme festet i håndtrykket

Ingenting av dette garanterer at en klient aldri gjør en ny verifiseringsforespørsel. Kjedeoppbygging, statuspolitikk og støttede mekanismer varierer etter implementasjon.

En sertifikatviser i én nettleser er ikke en beskrivelse av hvert operativsystem og hver VPN-klient. Den samme nettverksfangsten kan bety ulike ting under ulike verifiseringsinnstillinger.

Hurtigbuffer bryter antakelsen én side ett oppslag

Hurtigbuffer frikobler sideinnlastinger fra oppslag. Nettleseren kan gjenbruke et svar en periode, så én sidevisning betyr ikke én nettverksforespørsel.

Den motsatte feilen er like vanlig. Et bufret svar sier ingenting om når neste oppdatering skjer, og oppdateringsplanen kan være urelatert til siden som åpnes. Bruk klientens gjeldende dokumentasjon og den gjeldende verifiseringspolitikken før du tilskriver en fangst til OCSP.

Et gyldig statussvar må oppfylle verifisererens regler for ekthet og ferskhet, og en HTTP 200 er ikke det samme som en god status. En tidsavbrudd er ikke en tilbakekalling. Disse utfallene fører til ulik klientatferd og bør ikke slås sammen til én feil.

Personvernvalg som holder verifiseringen intakt

Der selve oppslaget er sensitivt, diskuter støttede leverings- og hurtigbufferalternativer med systemeieren. Ikke løs det ved å slå av tilbakekallingskontroll eller kjedeverifisering.

Et stillere spor er ikke en sikrere tilkobling. Hold peer-identitet, kjedeverifisering og den tiltenkte tilbakekallingspolitikken intakt, og endre leveringsveien bare gjennom et alternativ som utplasseringen støtter. Noter hvilket alternativ som ble valgt og hvem som eier det.

Når et oppslag dukker uventet opp, navngi mottakeren, ruten og sertifikatoperasjonen hver for seg. En utsteder-nedlasting, en statusforespørsel og sideforespørselen er tre hendelser. Å behandle dem som én gjør personvernvurderingen unøyaktig og skjuler hvilken part som faktisk lærte noe. Start ved protokollfeltene og arbeid deg utover til nettverksbanen.