OCSP-adatvédelem: a válaszadó tanúsítványt lát, nem az URL-t

Az állapotellenőrzés egyetlen kérdést tesz fel egyetlen tanúsítványról, és a válasz a saját kapcsolatán utazik. Nem tartalmazza az oldal útvonalát, amely az ellenőrzéshez vezetett. Az adatvédelmi viták gyakran böngészési előzményfolyamként kezelik a cserét, ami túlértékeli, mit hordoz a kérés, és alulértékeli, mit figyelhet meg a válaszadó. Olvassa el a kérést, mielőtt eldönti, mit árul el.

A kérés egyetlen tanúsítványt azonosít

Az OCSP-tanúsítvány-azonosító egy hash-függvényből, a kibocsátó két hash-éből és a céltanúsítvány sorozatszámából épül fel, ahogy az RFC 6960 előírja. Minden mező egyetlen tanúsítványra mutat, nem egy URL-re vagy HTTP-kérésre.

Az oldal útvonala, a lekérdezési karakterlánc és bármilyen űrlaptartalom hiányzik a szabványos azonosítóból. Az az állítás, hogy a válaszadó a pontos URL-t kapja meg, a tanúsítvány-ellenőrzésen kívül máshonnan származó bizonyítékot igényel. A kérés továbbra is megnevez egy tanúsítványt és egy pillanatot, és a válaszadó tudhatja, melyik szolgáltatás mutatja be.

Ami hiányzik, az az oldal, nem a teljes kontextus. Egy tanúsítvány-ellenőrzés plusz egy ismert szolgáltatás plusz egy ismétlődő forrás többet mondhat, mint bármelyikük önmagában.

Mit figyelhet meg a válaszadó valójában

A válaszadó azt a kapcsolatot látja, amely eléri: forráscím, időzítés és minden átviteli metaadat, amelyet a telepítése rögzít. Ha az állapotkérés a VPN-t követi, a forrás a VPN kijárata lehet a felhasználó hozzáférési hálózata helyett. Ne feltételezze, hogy az állapotkérés ugyanazt az útvonalat követi, mint az oldalkérés, csak mert mindkettő egyetlen böngésző-munkamenethez tartozik.

Ellenőrizze az ügyfél által támogatott útválasztást és ellenőrzési viselkedést ahelyett, hogy egyetlen nyomból következtetne rá. Egy megosztott alagút a két kérést különböző irányokba küldheti.

A tűzött válasz a másik gyakori minta. Az RFC 6066 TLS status_request kiterjesztése lehetővé teszi, hogy a kiszolgáló OCSP-választ csatoljon a saját kézfogásához, így az ügyfél azt ellenőrzi, amit kapott, ahelyett hogy maga szerezne állapotot ehhez a kapcsolathoz. Ez az eltolódás megváltoztatja a megfigyelőt. A beszerzést a kiszolgáló oldala végzi, és az ügyfél saját címe soha nem éri el a válaszadót ehhez a kapcsolathoz.

Az állapot tűzve érkezhet a kézfogásban

Ezek egyike sem garantálja, hogy az ügyfél soha nem indít újabb ellenőrzési kérést. A láncépítés, az állapotházirend és a támogatott mechanizmusok megvalósításonként változnak.

Egy böngésző tanúsítványmegjelenítője nem írja le az összes operációs rendszert és VPN-ügyfelet. Ugyanaz a hálózati rögzítés különböző ellenőrzési beállítások mellett mást jelenthet.

A gyorsítótárazás megbontja az egy oldal egy keresés feltevést

A gyorsítótárazás leválasztja az oldalbetöltéseket a keresésekről. A böngésző egy ideig újrahasznosíthat egy választ, így egy oldalmegtekintés nem jelent egy hálózati kérést.

Az ellenkező hiba ugyanilyen gyakori. A gyorsítótárazott válasz semmit nem mond arról, mikor történik a következő frissítés, és a frissítési ütemterv független lehet a megnyitott oldaltól. Használja az ügyfél jelenlegi dokumentációját és a hatályos ellenőrzési házirendet, mielőtt egy rögzítést az OCSP-hez rendel.

Egy érvényes állapotválasznak meg kell felelnie az ellenőrző hitelességi és frissességi szabályainak, és a HTTP 200 nem ugyanaz, mint a jó állapot. Az időtúllépés nem visszavonás. Ezek az eredmények eltérő ügyfélviselkedéshez vezetnek, és nem szabad egyetlen hibába összevonni őket.

Adatvédelmi választások, amelyek érintetlenül tartják az ellenőrzést

Ahol maga a keresés érzékeny, beszélje meg a támogatott kézbesítési és gyorsítótárazási lehetőségeket a rendszer tulajdonosával. Ne oldja meg a visszavonás-ellenőrzés vagy a láncellenőrzés kikapcsolásával.

A halkabb nyom nem biztonságosabb kapcsolat. Tartsa érintetlenül a partner identitását, a láncellenőrzést és a tervezett visszavonási házirendet, és a kézbesítési útvonalat csak a telepítés által támogatott lehetőséggel változtassa meg. Rögzítse, melyik lehetőséget választották, és ki felelős érte.

Amikor egy keresés váratlanul megjelenik, nevezze meg külön a fogadót, az útvonalat és a tanúsítvány-műveletet. A kibocsátótól való letöltés, az állapotlekérdezés és az oldalkérés három esemény. Ezek egyként kezelése pontatlanná teszi az adatvédelmi átvizsgálást, és elrejti, melyik fél tudott meg valóban valamit. Kezdje a protokoll mezőivel, és haladjon kifelé a hálózati útvonal felé.