Prywatność OCSP: responder widzi certyfikat, a nie twój URL

Sprawdzenie statusu zadaje jedno pytanie o jeden certyfikat, a odpowiedź podróżuje własnym połączeniem. Nie zawiera ścieżki strony, która doprowadziła do sprawdzenia. Dyskusje o prywatności często traktują tę wymianę jak strumień historii przeglądania, co przecenia to, co niesie zapytanie, i nie docenia tego, co responder może zaobserwować. Przeczytaj zapytanie, zanim zdecydujesz, co ujawnia.

Zapytanie identyfikuje jeden certyfikat

Identyfikator certyfikatu OCSP jest budowany z funkcji skrótu, dwóch skrótów wystawcy i numeru seryjnego certyfikatu docelowego, jak określa RFC 6960. Każde pole wskazuje jeden certyfikat, a nie URL ani zapytanie HTTP.

Ścieżka strony, ciąg zapytania i wszelka zawartość formularza są nieobecne w standardowym identyfikatorze. Twierdzenie, że responder otrzymuje dokładny URL, wymaga dowodów z innego miejsca niż sprawdzenie certyfikatu. Zapytanie nadal wskazuje certyfikat i moment, a responder może wiedzieć, która usługa go prezentuje.

Brakuje strony, a nie całego kontekstu. Sprawdzenie certyfikatu plus znana usługa plus powtarzające się źródło mogą powiedzieć więcej niż każde z nich osobno.

Co responder może faktycznie zaobserwować

Responder widzi połączenie, które do niego dociera: adres źródłowy, czas i wszelkie metadane transportu, które zapisuje jego wdrożenie. Jeśli zapytanie o status podąża za VPN, tym źródłem może być wyjście VPN, a nie sieć dostępowa użytkownika. Nie zakładaj, że zapytanie o status idzie tą samą ścieżką co zapytanie o stronę, tylko dlatego że oba należą do jednej sesji przeglądarki.

Sprawdź obsługiwane przez klienta trasowanie i zachowanie weryfikacji, zamiast wywnioskować je z jednego śladu. Podzielony tunel może wysłać oba zapytania w różnych kierunkach.

Przypięta odpowiedź to drugi częsty wzorzec. Rozszerzenie TLS status_request z RFC 6066 pozwala serwerowi dołączyć odpowiedź OCSP do własnego uzgadniania, więc klient weryfikuje to, co otrzymał, zamiast sam pobierać status dla tego połączenia. Ta zmiana przenosi obserwatora. Pobierania dokonuje strona serwera, a własny adres klienta nigdy nie dociera do respondera dla tego połączenia.

Status może nadejść przypięty w uzgadnianiu

Nic z tego nie gwarantuje, że klient nigdy nie wykona kolejnego zapytania weryfikacyjnego. Budowanie łańcucha, polityka statusu i obsługiwane mechanizmy różnią się w zależności od implementacji.

Przeglądarka certyfikatów w jednej przeglądarce nie jest opisem każdego systemu operacyjnego i klienta VPN. Ten sam zrzut sieciowy może znaczyć różne rzeczy przy różnych ustawieniach weryfikacji.

Buforowanie łamie założenie jedna strona jedno wyszukanie

Buforowanie oddziela wczytywanie stron od wyszukiwań. Przeglądarka może użyć odpowiedzi ponownie przez pewien czas, więc jedno wyświetlenie strony nie oznacza jednego żądania sieciowego.

Przeciwny błąd jest równie częsty. Zbuforowana odpowiedź nie mówi nic o tym, kiedy nastąpi następne odświeżenie, a harmonogram odświeżania może nie mieć związku z otwieraną stroną. Użyj aktualnej dokumentacji klienta i obowiązującej polityki weryfikacji, zanim przypiszesz zrzut do OCSP.

Ważna odpowiedź o statusie musi spełniać reguły autentyczności i świeżości weryfikatora, a HTTP 200 nie jest tym samym co dobry status. Przekroczenie limitu czasu nie jest unieważnieniem. Te wyniki prowadzą do innego zachowania klienta i nie powinny być łączone w jeden błąd.

Wybory prywatności, które zachowują weryfikację nietkniętą

Tam, gdzie samo wyszukiwanie jest wrażliwe, omów obsługiwane opcje dostarczania i buforowania z właścicielem systemu. Nie rozwiązuj tego przez wyłączanie sprawdzania unieważnienia lub walidacji łańcucha.

Cichszy ślad nie jest bezpieczniejszym połączeniem. Zachowaj nietknięte tożsamość partnera, walidację łańcucha i zamierzoną politykę unieważniania, a ścieżkę dostarczania zmieniaj tylko przez opcję obsługiwaną przez wdrożenie. Zapisz, którą opcję wybrano i kto za nią odpowiada.

Gdy wyszukiwanie pojawi się niespodziewanie, nazwij osobno odbiorcę, trasę i operację na certyfikacie. Pobranie od wystawcy, zapytanie o status i żądanie strony to trzy zdarzenia. Traktowanie ich jako jednego sprawia, że przegląd prywatności jest niedokładny i ukrywa, która strona naprawdę czegoś się dowiedziała. Zacznij od pól protokołu i przechodź na zewnątrz do ścieżki sieciowej.