Soukromí u OCSP: respondent vidí certifikát, ne vaši URL

Kontrola stavu klade jednu otázku o jednom certifikátu a odpověď putuje vlastním spojením. Neobsahuje cestu stránky, která ke kontrole vedla. Diskuse o soukromí často berou tuto výměnu jako kanál historie prohlížení, což přeceňuje, co požadavek nese, a podceňuje, co může respondent pozorovat. Přečtěte si požadavek, než rozhodnete, co prozrazuje.

Požadavek identifikuje jeden certifikát

Identifikátor certifikátu OCSP se sestavuje z hashovací funkce, dvou hashů vydavatele a sériového čísla cílového certifikátu, jak stanoví RFC 6960. Každé pole ukazuje na jeden certifikát, ne na URL nebo požadavek HTTP.

Cesta stránky, řetězec dotazu a jakýkoli obsah formuláře ve standardním identifikátoru chybějí. Tvrzení, že respondent dostává přesnou URL, potřebuje důkaz odjinud než z kontroly certifikátu. Požadavek stále jmenuje certifikát a okamžik a respondent může vědět, která služba jej předkládá.

Chybí stránka, ne celý kontext. Kontrola certifikátu plus známá služba plus opakovaný zdroj mohou být informativnější než kterákoli z nich samostatně.

Co může respondent skutečně pozorovat

Respondent vidí spojení, které k němu dorazí: zdrojovou adresu, časování a jakákoli transportní metadata, která jeho nasazení zaznamenává. Pokud požadavek na stav prochází VPN, může být tím zdrojem výstup VPN, ne uživatelova přístupová síť. Nepředpokládejte, že požadavek na stav jde stejnou cestou jako požadavek na stránku, jen proto, že oba patří jedné relaci prohlížeče.

Ověřte podporované směrování a chování ověřování na klientovi, místo abyste je vyvozovali z jediného záznamu. Rozdělený tunel může poslat oba požadavky různými směry.

Připnutá odpověď je druhý běžný vzor. Rozšíření TLS status_request z RFC 6066 umožňuje serveru připojit odpověď OCSP k vlastnímu handshake, takže klient ověří to, co dostal, místo aby pro toto spojení získával stav sám. Tento posun mění pozorovatele. Získávání dělá strana serveru a vlastní adresa klienta se pro toto spojení k respondentovi nikdy nedostane.

Stav může dorazit připnutý v handshake

Nic z toho nezaručuje, že klient nikdy neučiní další požadavek na ověření. Sestavení řetězce, politika stavu a podporované mechanismy se liší podle implementace.

Prohlížeč certifikátů v jednom prohlížeči není popisem každého operačního systému a klienta VPN. Stejný síťový záznam může při různých nastaveních ověřování znamenat různé věci.

Kešování boří předpoklad jedna stránka jeden dotaz

Kešování odděluje načítání stránek od dotazů. Prohlížeč může odpověď po určitou dobu znovu použít, takže jedno zobrazení stránky neznamená jeden síťový požadavek.

Opačná chyba je stejně častá. Kešovaná odpověď nic neříká o tom, kdy proběhne příští obnovení, a plán obnovení může nesouviset se stránkou, která se otevírá. Použijte aktuální dokumentaci klienta a platnou politiku ověřování, než záznam přiřadíte OCSP.

Platná odpověď o stavu musí splnit pravidla pravosti a čerstvosti ověřovatele a HTTP 200 není totéž jako dobrý stav. Časový limit není odvolání. Tyto výsledky vedou k různému chování klienta a neměly by se slévat do jedné chyby.

Volby soukromí, které zachovají ověřování nedotčené

Tam, kde je samotný dotaz citlivý, proberte s vlastníkem systému podporované možnosti doručení a kešování. Neřešte to vypnutím kontroly odvolání nebo ověření řetězce.

Tišší stopa není bezpečnější spojení. Zachovejte nedotčené identitu protistrany, ověření řetězce a zamýšlenou politiku odvolání a cestu doručení měňte jen volbou, kterou nasazení podporuje. Zaznamenejte, která volba byla zvolena a kdo ji vlastní.

Když se dotaz objeví nečekaně, pojmenujte příjemce, trasu a operaci s certifikátem odděleně. Stahování od vydavatele, dotaz na stav a požadavek na stránku jsou tři události. Pojímat je jako jednu činí kontrolu soukromí nepřesnou a skrývá, která strana se skutečně něco dozvěděla. Začněte u polí protokolu a postupujte ven k síťové cestě.