Co lokalna sieć wciąż widzi przez twoje VPN

Trzej obserwatorzy łączą się w jedno pytanie za każdym razem, gdy ktoś pyta, czy VPN ukrywa jego ruch: sieć, do której jest podłączony, maszyna w jego rękach i operator tunelu. Każdy dowiaduje się czegoś innego, a tunel zmienia każdy z tych obrazów w inny sposób. Warto pracować w przeciwnym kierunku i zacząć od twierdzenia, które jest stawiane, bo to twierdzenie musi przetrwać sprawdzenie. Zdecyduj, którego twierdzenia potrzebujesz, a potem porównaj z nim narzędzia.

Twierdzenie pierwsze: nikt nie może przeczytać ruchu

Zacznij od najwęższego twierdzenia: zawartość pozostaje nieczytelna. Pasywny obserwator na ścieżce nie widzi wnętrza sesji TLS, więc tunel niewiele dodaje do witryny, która już używa HTTPS, a przeciw dwóm punktom końcowym nie dodaje niczego. To twierdzenie łamie ten, kto kontroluje urządzenie, bo proxy inspekcyjne kończy połączenie i podpisuje je ponownie korzeniem, któremu maszyna już ufa. Dlatego kłódka nadal się pojawia, gdy łańcuch certyfikatów niesie nazwę organizacji, która zainstalowała korzeń.

security find-certificate -a -p /Library/Keychains/System.keychain | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -noout -print_certs | grep subject
certutil -store Root

W systemie macOS ten potok wypisuje jeden wiersz podmiotu dla każdego certyfikatu w pęku kluczy maszyny, bez otwierania okna, a w systemie Windows certutil -store Root wylicza ten sam magazyn, który certlm.msc pokazuje graficznie. Korzeń należący do szkoły, pracodawcy lub produktu bezpieczeństwa sieci to wpis, którego trzeba szukać. Znalezienie jednego dowodzi tylko, że przechwytywanie jest możliwe, a nie że ma miejsce.

To, co możesz z tym zrobić, jest kwestią polityki, a nie techniki. Usunięcie profilu lub korzenia inspekcyjnego ze sprzętu, którego nie posiadasz, zwykle narusza umowę o dopuszczalnym użytkowaniu, a system zarządzania zwykle to zauważa i stosuje ponownie, więc wymóg, by właściciel urządzenia nie czytał twojego ruchu, wymaga innego urządzenia, a nie innego ustawienia.

Twierdzenie drugie: nikt nie widzi, dokąd idziesz

Cel jest trudniejszym twierdzeniem, bo dwa ujawnienia następują, zanim strona się załaduje. Zapytanie trafia do tego resolvera, którego system jest skonfigurowany używać, a odpowiedź jest widoczna dla sieci, która ją niesie. Potem uścisk dłoni TLS niesie żądaną nazwę serwera jawnie, chyba że Encrypted Client Hello jest obsługiwany po obu stronach. Żadne z ujawnień nie wymaga odszyfrowania, więc tunel nie ma wpływu na żadne z nich.

resolvectl status | grep -A2 "Link"
nslookup example.com

To, który resolver jest rzeczywiście używany, decyduje o ekspozycji, i można to zmierzyć zamiast dyskutować. W systemie Linux resolvectl status wypisuje serwery DNS dla każdego łącza, a jego wynik mówi, czy odpowiada resolver witryny, czy narzucony. Windows odpowiada na to samo pytanie poleceniem nslookup example.com, którego pierwszy blok wyniku to serwer DNS, który odpowiedział.

Gdy laptop pyta resolver witryny, zanim tunel się podniesie, albo profil przychodzi bez serwera zastępczego, więc stary pozostaje w użyciu, administrator nadal zbiera nazwy hostów, niczego nie odszyfrowując. Szyfrowany DNS w przeglądarce albo omija narzucony resolver, albo jest całkowicie blokowany i zawodzi w stanie zamkniętym. Operator wyjścia widzi te same nazwy ze swojej strony. Zmiana resolvera nie odsuwa więc tego ujawnienia od dostawcy tunelu.

Twierdzenie trzecie: nikt nie wie, że się połączyłeś

Trzecie twierdzenie jest tym, którego tunel nie może wesprzeć, bo pakiety nadal przechodzą przez sieć lokalną. Ta sieć dowiaduje się adresu punktu końcowego, przybliżonego wolumenu, czasu i istnienia jednej długotrwałej sesji szyfrowanej, co wystarcza, by blokować, ograniczać albo po prostu zauważyć. Zapora, która nie potrafi przeczytać pakietu, nadal może odmówić przepuszczenia go. Bycie obserwowanym to nie to samo co brak jakiegokolwiek obserwatora: przesunąłeś obserwatora, nie usunąłeś go.

Tunelowanie dzielone i każda aplikacja, która ignoruje narzuconą trasę, tworzą przepływy poza tunelem, które wyglądają dokładnie jak wcześniej. To właśnie te przepływy uważny obserwator zauważa najpierw, a tabela tras klienta pokazuje, które cele są wyłączone.

Operator na drugim końcu ma lustrzane odbicie tego widoku: adres wyjścia, czas, wolumen i zwykle nazwy witryn. Twój dostawca staje się stroną z punktem widokowym, co jest inną transakcją niż niewidzialność. Wybór dostawcy, któremu ufasz, jest prawdziwą decyzją; nazwanie wyniku nieobserwowanym już nie.

Zdecyduj, którego twierdzenia potrzebujesz

Zapisz wymaganie w jednej linii, zanim dotkniesz klienta: ukryć treść, ukryć cele albo ukryć, czy w ogóle się połączyłeś. Treścią zajmuje się już HTTPS razem z tunelem, natomiast cele wymagają resolvera i ścieżki, które całkowicie omijają sprzęt witryny.

Trzecie wymaganie jest to niewygodne, bo coś wciąż jest widocznie gdzieś podłączone, szyfrowane albo nie. Żadne ustawienie klienta tego nie zmienia. Jeśli wymaganie i polityka się rozchodzą, ta luka należy do rozmowy z właścicielem polityki, a nie do opcji klienta. Osobą, która może na to odpowiedzieć, jest ta, która napisała politykę.