Czy operator VPN widzi, jakie strony odwiedzasz?

Zapytaj, co VPN może zobaczyć, a odpowiedź zależy od tego, gdzie stoisz na ścieżce. Na warstwie sesji operator ma zdarzenia uwierzytelniania i liczniki bajtów. Na warstwie pakietów ma adresy docelowe i czas. Na warstwie DNS może mieć same nazwy. Każda warstwa odpowiada na inne pytanie i żaden przełącznik nie przenosi cię między nimi.

Ustal warstwę, zanim cokolwiek stwierdzisz

To samo połączenie tworzy inne zapisy w każdym punkcie, a twierdzenie o prywatności ma sens tylko wtedy, gdy nazywa ten punkt. Czytaj tabelę kolumna po kolumnie: co istnieje na tej warstwie, co operator może tam zobaczyć i czego te same zapisy wciąż nie mogą powiedzieć.

Czytanie jednej warstwy jako całego obrazu jest początkiem zarówno nadużyć, jak i fałszywego spokoju. Dostawca, który twierdzi, że nie rejestruje przeglądania, może być dokładny co do logowania adresów URL, a mimo to przechowywać zapisy sesji, a przechwycenie pakietów pokazujące tylko adresy nie staje się historią przeglądania bez wyszukiwań wstecznych i domysłów.

Oceniając politykę, znajdź zdanie opisujące każdą warstwę. Jeśli polityka ich nie rozdziela, pytaj, jakie zapisy istnieją, zamiast przyjmować ogólne stwierdzenie o szyfrowaniu.

Spis sesji: co przechowuje zwykły serwer OpenVPN

Domyślnie serwer OpenVPN nie przechwytuje ruchu. Zwykłe wyjście to spis sesji: konto, które się uwierzytelniło, adres źródłowy, z którego przyszło, znaczniki czasu rozpoczęcia i zakończenia, przydzielony adres tunelu oraz sumy bajtów w obu kierunkach. To spis sesji, a nie lista miejsc docelowych.

Opcje rejestrowania mogą dodać szczegóły. Wyższy poziom szczegółowości zapisuje więcej o uzgadnianiu, a plik stanu może wymienić podłączonych klientów, ale żadne z nich nie czyni serwera przezroczystym proxy. Wytwarzanie adresów URL wymaga zakończenia TLS lub uruchomienia jawnego proxy, a oba zmieniają układ zaufania, a nie włączają ukrytą funkcję.

Dlatego dokładna wersja twierdzenia o braku dziennika przeglądania jest węższa, niż brzmi. Serwer nie zna strony, ale wie, że sesja istniała i mniej więcej ile danych przez nią przeszło. Czy ten zapis sesji jest przechowywany i jak długo, to osobne pytanie polityki.

Pakiety wewnętrzne i zewnętrzne to różne dowody

Przechwycenie pakietów to sposób, by zobaczyć, co naprawdę przechodzi przez tunel. Na serwerze nazwij interfejs tunelu i pisz do pliku, który można przeanalizować offline:

sudo tcpdump -ni tun0 -w /tmp/tun.pcap
sudo tcpdump -r /tmp/tun.pcap -nn | head

Ten plik zawiera odszyfrowany ruch wewnętrzny: adres tunelu klienta jako źródło, adres docelowy i port, rozmiary pakietów i czas. Nie zawiera ścieżki HTTP ani treści odpowiedzi, chyba że TLS został gdzieś zakończony, a to dane wrażliwe, których przechowywanie jest decyzją polityki, a nie wygodą debugowania.

Przechwycenie na interfejsie fizycznym pokazuje coś innego. Widać tam pakiety zewnętrzne adresowane do punktu końcowego VPN, z zaszyfrowaną zawartością w środku. Niepowiązane adresy w tym pliku są normalne, gdy istnieje adapter wirtualny, ponieważ urządzenie tunelu niesie przepływy wewnętrzne, a szyfrowany transport zewnętrzne.

Zapytaj, na jakie pytanie ma odpowiedzieć przechwycenie. Korzystanie z tunelu przez aplikację widać na adapterze wirtualnym; osiągalność tunelu do punktu końcowego widać na fizycznym. Użycie któregokolwiek pliku jako pełnego obrazu daje wnioski, których dane nie wspierają.

DNS to miejsce, w którym nazwy stają się widoczne

DNS pozostaje praktycznym wyjątkiem. Resolver widzi nazwy, o których rozwiązanie jest proszony, więc kto nim zarządza, dowiaduje się, jakich stron szuka klient, nawet gdy późniejsze połączenia są szyfrowane. Przechwycenie tunelu pokazuje adresy; resolver pokazuje nazwy.

Sprawdź, jakiego adresu resolver użył, by dotrzeć do zewnętrznej usługi. Odpowiedzią jest adres wyjściowy resolvera, a porównanie z wyjściem VPN mówi, czy zapytanie przeszło przez tunel:

dig +short myip.opendns.com @resolver1.opendns.com
dig example.com
sudo tcpdump -ni any udp port 53

Jeśli ten adres odpowiada połączeniu lokalnemu, a nie wyjściu tunelu, wyszukiwanie ominęło VPN i nazwa była widoczna na ścieżce lokalnej. Powtórz sprawdzenie po aktualizacji klienta, ponieważ nowa wersja może zmienić, który resolver instaluje profil.

Szyfrowany DNS przenosi widoczność, zamiast ją usuwać. Sieć nie widzi już zapytania, ale resolver nadal je widzi, a kwestia zaufania po prostu zmienia ręce. Nazwa serwera TLS w uzgadnianiu połączenia to kolejny częściowy sygnał: często przetrwa nawet wtedy, gdy zawartość jest nieprzejrzysta, więc adresy docelowe nie są jedynymi metadanymi, które serwer przekazujący może obserwować.

Trzy rodzaje zapisów i kto może je czytać

Rozliczanie sesji, zapisy według nazw i dowody wycieku to trzy różne produkty z trzema różnymi obowiązkami. Dzienniki sesji są tanie i mało wrażliwe, odpowiadają, kto i kiedy się połączył. Zapisy według nazw wymagają rejestrującego resolvera lub jawnego proxy i tworzą obowiązek ujawnienia wobec osób, których to dotyczy. Dowód wycieku to test po stronie klienta, który porównuje to, co ujawnia resolver, z wyjściem tunelu.

Zapisz, który z tych trzech prowadzisz, kto może go czytać i jak długo zostaje. Stwierdzenia, że usługa nie prowadzi dzienników, opisują jedną warstwę i pozostają prawdziwe tylko w tym zakresie. Ten sam dostawca może być dokładny co do sesji, a mylić się co do DNS.

Utrzymaj test odtwarzalnym: to samo zapytanie do resolvera, ten sam interfejs przechwytywania i to samo porównanie. Twierdzenie o prywatności, którego nie można sprawdzić na nazwanej warstwie, jest sloganem, a nie faktem operacyjnym.