OCSP-privatliv: svareren ser et certifikat, ikke din URL

En statuskontrol stiller ét spørgsmål om ét certifikat, og svaret rejser på sin egen forbindelse. Den indeholder ikke den sidesti, der førte til kontrollen. Privatlivsdiskussioner behandler ofte udvekslingen som et feed fra browserhistorikken, hvilket overdriver, hvad anmodningen bærer, og underdriver, hvad svareren kan observere. Læs anmodningen, før du afgør, hvad den afslører.

Anmodningen identificerer ét certifikat

OCSP-certifikatidentifikatoren bygges af en hashfunktion, to hashes fra udstederen og serienummeret på målcertifikatet, som angivet i RFC 6960. Hvert felt peger på ét certifikat, ikke på en URL eller en HTTP-anmodning.

Sidestien, forespørgselsstrengen og eventuelt formularindhold mangler i den standardidentifikator. Påstanden om, at svareren modtager den præcise URL, kræver bevis fra et andet sted end certifikatkontrollen. Anmodningen nævner stadig et certifikat og et øjeblik, og svareren kan vide, hvilken tjeneste der præsenterer det.

Det, der mangler, er siden, ikke hele konteksten. En certifikatkontrol plus en kendt tjeneste plus en gentagen kilde kan være mere oplysende end nogen af dem alene.

Hvad svareren faktisk kan observere

Svareren ser den forbindelse, der når den: kildeadresse, timing og enhver transportmetadata, som dens udrulning registrerer. Hvis statusanmodningen følger VPN’en, kan den kilde være VPN-udgangen i stedet for brugerens adgangsnetværk. Antag ikke, at statusanmodningen tager samme vej som sideanmodningen, blot fordi begge hører til én browsersession.

Kontroller klientens understøttede routing og verifikationsadfærd i stedet for at udlede den af et enkelt spor. En delt tunnel kan sende de to anmodninger i forskellige retninger.

Et stapled svar er det andet almindelige mønster. TLS-udvidelsen status_request fra RFC 6066 lader en server vedhæfte et OCSP-svar til sit eget handshake, så klienten validerer det, den har fået, i stedet for selv at hente status for den forbindelse. Det skift ændrer observatøren. Det er serversiden, der henter, og klientens egen adresse når aldrig svareren for den forbindelse.

Status kan ankomme stapled i handshaket

Intet af dette garanterer, at en klient aldrig laver endnu en valideringsanmodning. Kædeopbygning, statuspolitik og understøttede mekanismer varierer efter implementering.

En certifikatviser i én browser er ikke en beskrivelse af ethvert styresystem og enhver VPN-klient. Den samme netværksoptagelse kan betyde forskellige ting under forskellige valideringsindstillinger.

Caching bryder antagelsen om én side og ét opslag

Caching afkobler sideindlæsninger fra opslag. Browseren kan genbruge et svar i en periode, så én sidevisning betyder ikke én netværksanmodning.

Den modsatte fejl er lige så almindelig. Et cachet svar siger intet om, hvornår den næste opdatering sker, og opdateringsplanen kan være uden forbindelse til den side, der åbnes. Brug klientens aktuelle dokumentation og den gældende verifikationspolitik, før du tilskriver en optagelse OCSP.

Et gyldigt statussvar skal opfylde verifikatorens regler for ægthed og friskhed, og en HTTP 200 er ikke det samme som en god status. En timeout er ikke en tilbagekaldelse. Disse udfald fører til forskellig klientadfærd og bør ikke slås sammen til én fejl.

Privatlivsvalg, der holder valideringen intakt

Hvor selve opslaget er følsomt, drøft understøttede leverings- og cachingmuligheder med systemejeren. Løs det ikke ved at slå tilbagekaldelseskontrol eller kædevalidering fra.

Et mere stille spor er ikke en sikrere forbindelse. Hold peer-identitet, kædevalidering og den tilsigtede tilbagekaldelsespolitik intakt, og skift kun leveringsvejen via en mulighed, som udrulningen understøtter. Noter, hvilken mulighed der blev valgt, og hvem der ejer den.

Når et opslag dukker uventet op, navngiv modtageren, ruten og certifikatoperationen hver for sig. En udstederdownload, en statusforespørgsel og sideanmodningen er tre begivenheder. At behandle dem som én gør privatlivsgennemgangen unøjagtig og skjuler, hvilken part der faktisk lærte noget. Start ved protokolfelterne og arbejd udad mod netværksstien.