Przy zwykłym proxy HTTP sieć lokalna widzi początkowy cel CONNECT, nawet jeśli żądanie do witryny chroni HTTPS. TLS do proxy zmienia tę ekspozycję na odcinku klient–proxy.

TrasaCo widzi obserwator z dostępem do lokalnego ruchu
Nieszyfrowana witryna HTTP przez nieszyfrowane proxy HTTPWymiana aplikacji jest przesyłana czytelnie; widoczny jest nie tylko adres proxy.
Witryna HTTPS przez nieszyfrowane proxy HTTPWidoczne są jawny cel CONNECT, połączenie z proxy i zależności czasowe; TLS celu chroni żądanie do witryny w tunelu.
Poprawnie zweryfikowane połączenie z proxy HTTPSTLS chroni wymianę z proxy na tym odcinku; połączenie z punktem i metadane ruchu nadal są widoczne.

Ochrona tego odcinka nie odbiera operatorowi proxy wglądu we własną obsługę połączeń. TLS celu i zaufanie do operatora to osobne części trasy.

DNS też wymaga osobnej kontroli. Nazwa celu rozwiązana lokalnie nie przenosi się automatycznie do wnętrza połączenia proxy. Zdalne rozwiązywanie SOCKS zmienia to wyszukiwanie, lecz procesy w tle i inne aplikacje nadal mogą rozwiązywać nazwy i łączyć się niezależnie.

Dla użytecznej oceny prywatności zapisz schemat URL proxy, schemat celu, faktyczną trasę klienta i zachowanie DNS. Jedno ustawienie przeglądarki nie potwierdza ochrony całego urządzenia. U celu zalogowane żądanie nadal może identyfikować konto przez ciasteczka, nawet jeśli lokalny odcinek jest szyfrowany, a wyjściowy IP się zmienił.

Powiązane artykuły