Súkromie pri OCSP: respondent vidí certifikát, nie vašu URL

Kontrola stavu kladie jednu otázku o jednom certifikáte a odpoveď putuje vlastným spojením. Neobsahuje cestu stránky, ktorá ku kontrole viedla. Diskusie o súkromí často berú túto výmenu ako kanál histórie prehliadania, čo preceňuje, čo požiadavka nesie, a podceňuje, čo môže respondent pozorovať. Prečítajte si požiadavku, kým rozhodnete, čo prezrádza.

Požiadavka identifikuje jeden certifikát

Identifikátor certifikátu OCSP sa zostavuje z hašovacej funkcie, dvoch hašov vydavateľa a sériového čísla cieľového certifikátu, ako stanovuje RFC 6960. Každé pole ukazuje na jeden certifikát, nie na URL alebo požiadavku HTTP.

Cesta stránky, reťazec dopytu a akýkoľvek obsah formulára v štandardnom identifikátore chýbajú. Tvrdenie, že respondent dostáva presnú URL, potrebuje dôkaz odinakiaľ než z kontroly certifikátu. Požiadavka stále menuje certifikát a okamih a respondent môže vedieť, ktorá služba ho predkladá.

Chýba stránka, nie celý kontext. Kontrola certifikátu plus známa služba plus opakovaný zdroj môžu byť informatívnejšie než ktorákoľvek z nich samostatne.

Čo môže respondent skutočne pozorovať

Respondent vidí spojenie, ktoré k nemu dorazí: zdrojovú adresu, časovanie a akékoľvek transportné metadáta, ktoré jeho nasadenie zaznamenáva. Ak požiadavka na stav prechádza cez VPN, tým zdrojom môže byť výstup VPN, nie používateľova prístupová sieť. Nepredpokladajte, že požiadavka na stav ide rovnakou cestou ako požiadavka na stránku, len preto že obe patria jednej relácii prehliadača.

Overte podporované smerovanie a správanie overovania u klienta, namiesto toho, aby ste ich odvodzovali z jednej stopy. Rozdelený tunel môže poslať obe požiadavky rôznymi smermi.

Pripnutá odpoveď je druhý bežný vzor. Rozšírenie TLS status_request z RFC 6066 umožňuje serveru pripojiť odpoveď OCSP k vlastnému handshake, takže klient overí to, čo dostal, namiesto toho, aby pre toto spojenie získaval stav sám. Tento posun mení pozorovateľa. Získavanie robí strana servera a vlastná adresa klienta sa pre toto spojenie k respondentovi nikdy nedostane.

Stav môže doraziť pripnutý v handshake

Nič z toho nezaručuje, že klient nikdy neurobí ďalšiu požiadavku na overenie. Zostavovanie reťazca, politika stavu a podporované mechanizmy sa líšia podľa implementácie.

Prehliadač certifikátov v jednom prehliadači nie je opisom každého operačného systému a klienta VPN. Rovnaký sieťový záznam môže pri rôznych nastaveniach overovania znamenať rôzne veci.

Kešovanie búra predpoklad jedna stránka jeden dopyt

Kešovanie oddeľuje načítavanie stránok od dopytov. Prehliadač môže odpoveď po určitý čas znovu použiť, takže jedno zobrazenie stránky neznamená jednu sieťovú požiadavku.

Opačná chyba je rovnako častá. Kešovaná odpoveď nič nehovorí o tom, kedy nastane ďalšie obnovenie, a plán obnovenia môže nesúvisieť so stránkou, ktorá sa otvára. Použite aktuálnu dokumentáciu klienta a platnú politiku overovania, kým záznam priradíte OCSP.

Platná odpoveď o stave musí splniť pravidlá pravosti a čerstvosti overovateľa a HTTP 200 nie je to isté ako dobrý stav. Časový limit nie je odvolanie. Tieto výsledky vedú k rôznemu správaniu klienta a nemali by sa zlievať do jednej chyby.

Voľby súkromia, ktoré zachovajú overovanie nedotknuté

Tam, kde je samotný dopyt citlivý, preberte s vlastníkom systému podporované možnosti doručenia a kešovania. Neriešte to vypnutím kontroly odvolania alebo overenia reťazca.

Tichšia stopa nie je bezpečnejšie spojenie. Zachovajte nedotknutú identitu protistrany, overenie reťazca a zamýšľanú politiku odvolania a cestu doručenia meňte len voľbou, ktorú nasadenie podporuje. Zaznamenajte, ktorá voľba bola zvolená a kto ju vlastní.

Keď sa dopyt objaví nečakane, pomenujte príjemcu, trasu a operáciu s certifikátom oddelene. Sťahovanie od vydavateľa, dopyt na stav a požiadavka na stránku sú tri udalosti. Vnímať ich ako jednu robí kontrolu súkromia nepresnou a skrýva, ktorá strana sa skutočne niečo dozvedela. Začnite pri poliach protokolu a postupujte von k sieťovej ceste.