OCSP-integritet: svararen ser ett certifikat, inte din URL

En statuskontroll ställer en fråga om ett certifikat, och svaret färdas på sin egen anslutning. Den innehåller inte sidans sökväg som ledde till kontrollen. Integritetsdiskussioner behandlar ofta utbytet som ett flöde från webbläsarhistoriken, vilket överdriver vad begäran bär och underskattar vad svararen kan observera. Läs begäran innan du avgör vad den avslöjar.

Begäran identifierar ett certifikat

OCSP-certifikatidentifieraren byggs av en hashfunktion, två hashar från utfärdaren och serienumret för målcertifikatet, enligt RFC 6960. Varje fält pekar på ett certifikat, inte på en URL eller en HTTP-begäran.

Sidans sökväg, frågesträngen och eventuellt formulärinnehåll saknas i standardidentifieraren. Påståendet att svararen tar emot den exakta URL:en kräver bevis från annat håll än certifikatkontrollen. Begäran namnger fortfarande ett certifikat och en tidpunkt, och svararen kan veta vilken tjänst som presenterar det.

Det som saknas är sidan, inte hela sammanhanget. En certifikatkontroll plus en känd tjänst plus en upprepad källa kan säga mer än någon av dem för sig.

Vad svararen faktiskt kan observera

Svararen ser anslutningen som når den: källadress, tidpunkt och alla transportmetadata som distributionen registrerar. Om statusbegäran följer VPN:en kan den källan vara VPN-utgången i stället för användarens åtkomstnät. Anta inte att statusbegäran tar samma väg som sidbegäran bara för att båda hör till en webbläsarsession.

Kontrollera klientens stödda routning och verifieringsbeteende i stället för att härleda det från ett enda spår. En delad tunnel kan skicka de två begärandena i olika riktningar.

Ett häftat svar är det andra vanliga mönstret. TLS-utökningen status_request från RFC 6066 låter en server fästa ett OCSP-svar vid sin egen handskakning, så klienten validerar det den fick i stället för att själv hämta status för den anslutningen. Den förskjutningen ändrar observatören. Det är serversidan som hämtar, och klientens egen adress når aldrig svararen för den anslutningen.

Status kan anlända häftad i handskakningen

Inget av detta garanterar att en klient aldrig gör en ny verifieringsbegäran. Kedjeuppbyggnad, statuspolicy och stödda mekanismer varierar beroende på implementering.

En certifikatvisare i en webbläsare är inte en beskrivning av varje operativsystem och VPN-klient. Samma nätverksfångst kan betyda olika saker under olika verifieringsinställningar.

Cachelagring bryter antagandet en sida en sökning

Cachelagring frikopplar sidinläsningar från sökningar. Webbläsaren kan återanvända ett svar en tid, så en sidvisning innebär inte en nätverksbegäran.

Det motsatta felet är lika vanligt. Ett cachelagrat svar säger inget om när nästa uppdatering sker, och uppdateringsschemat kan vara orelaterat till sidan som öppnas. Använd klientens aktuella dokumentation och den gällande verifieringspolicyn innan du tillskriver en fångst till OCSP.

Ett giltigt statussvar måste uppfylla verifierarens regler för äkthet och färskhet, och en HTTP 200 är inte detsamma som en bra status. En timeout är inte en återkallelse. Dessa utfall leder till olika klientbeteende och bör inte slås samman till ett enda fel.

Integritetsval som håller verifieringen intakt

Där själva sökningen är känslig, diskutera stödda leverans- och cachelagringsalternativ med systemägaren. Lös det inte genom att stänga av återkallelsekontrollen eller kedjeverifieringen.

Ett tystare spår är inte en säkrare anslutning. Håll peer-identitet, kedjeverifiering och den avsedda återkallelsepolicyn intakta, och ändra leveransvägen bara genom ett alternativ som distributionen stöder. Notera vilket alternativ som valdes och vem som äger det.

När en sökning dyker upp oväntat, namnge mottagaren, vägen och certifikatoperationen var för sig. En nedladdning från utfärdaren, en statusfråga och sidbegäran är tre händelser. Att behandla dem som en gör integritetsgranskningen felaktig och döljer vilken part som faktiskt lärde sig något. Börja vid protokollfälten och arbeta utåt mot nätverksvägen.