Co tunel szyfruje, a co pozostawia czytelne

Twój tunel działa, jedna karta pokazuje zieloną kłódkę, a zwykła strona HTTP w innej karcie nadal ostrzega, że połączenie nie jest bezpieczne. Ta kombinacja myli ludzi, ponieważ obie ochrony obejmują różne odległości. VPN chroni ruch między własnymi punktami końcowymi, a za wyjściem ruch znów staje się zwykły. HTTPS chroni jedno połączenie aż do witryny. Zestawienie tych dwóch faktów wyjaśnia większość pytań o to, co VPN naprawdę ukrywa.

Co tunel faktycznie obejmuje

Między klientem a partnerem VPN obserwator widzi zaszyfrowane bajty, a nie czytelne żądanie. Obejmuje to odcinek, który tunel przecina, a zwykle jest to część, której nie kontrolujesz. Nie sięga do łącza między wyjściem VPN a witryną, ponieważ tunel zakończył się na wyjściu. Bajty znów są czytelne od chwili zakończenia tunelu. Nic w tym nie jest błędną konfiguracją.

Wyjście to maszyna, która odszyfrowuje i przekazuje dalej, i właśnie do tego służy VPN. Wszystko, co przekazuje, jest dla niej widoczne w postaci, w jakiej zostało odebrane, więc zwykłe żądanie HTTP pozostaje czystym tekstem od wyjścia dalej.

Czytaj to jako właściwość, a nie wadę. Szyfrowanie jest ograniczone do jednej ścieżki, a ścieżka kończy się tam, gdzie zaczyna się usługa.

Klucze, nonce i integralność prostymi słowami

Bieżący ruch jest chroniony kryptografią symetryczną, a obie strony wyprowadzają lub uzyskują materiał klucza podczas uzgadniania. Szyfrowanie uwierzytelnione, opisane ogólnie w RFC 5116, daje poufność i integralność w jednej konstrukcji. Odbiorca odrzuca zmienione bajty, zamiast po prostu nie móc ich odczytać, i to jest część, o której ludzie zapominają, gdy sądzą, że szyfrowanie oznacza mieszanie.

Klucze pochodzą z tej wymiany, a nie z hasła wpisanego przy logowaniu. Hasło uwierzytelnia tożsamość, a następnie protokół ustala materiał sesji. Efemeryczna wymiana kluczy daje tajność w przód, więc nagrana sesja pozostaje nieczytelna, nawet jeśli później wycieknie klucz długoterminowy.

Duża liczba w specyfikacji nie odpowiada na żadne z tych pytań, a porównywanie liczb między niepowiązanymi algorytmami nie jest rankingiem. Zapytaj zamiast tego, co daje wymiana kluczy.

Gdzie kończy się tunel

Punkt końcowy, który kończy tunel, może czytać to, co przekazuje. Dotyczy to zarówno bramy korporacyjnej, dostawcy komercyjnego, jak i serwera hostowanego samodzielnie. To jest projekt, a nie jego wada. Silna kryptografia nie może powstrzymać przejętego punktu końcowego przed odczytaniem czystego tekstu, który do niego dociera, ponieważ ochrona zatrzymuje się właśnie na punkcie końcowym.

HTTPS trwa dalej poza tym punktem, dlatego witryna może być bezpieczna w wrogiej sieci nawet bez VPN. Obie ochrony nakładają się na pierwszym odcinku i tylko jedna z nich trwa po wyjściu.

Dlatego osłabianie weryfikacji certyfikatu, aby połączenie działało, nie jest testem tunelu. Wyłącza inną ochronę i zostawia cię z mniejszym niż na początku.

Dlaczego anonimowość to inny produkt

Adresy, czas i wolumen pozostają obserwowalne poza tunelem. Obserwator może zobaczyć, że ruch płynie do punktu końcowego VPN, w przybliżeniu ile i kiedy. Treść może być nieczytelna, podczas gdy wzorzec nadal jest informacyjny.

Dostawca również znajduje się gdzie indziej niż twoja sieć, co jest zmianą obserwatora, a nie usunięciem obserwacji. Pliki cookie, logowania i identyfikatory kont działają dokładnie tak jak wcześniej, ponieważ tunel nigdy nie obiecał ich zmieniać.

Wybierz dostawcę według jego polityki rejestrowania i jurysdykcji, jeśli to jest wymóg, a następnie przeczytaj samą politykę. Strony marketingowe rzadko odpowiadają na to pytanie w sposób, który ktoś może zweryfikować.

Sprawdź tunel i witrynę osobno

Najpierw sprawdź tunel, aby wiedzieć, którą ochronę testujesz. Następnie sprawdź własny transport witryny i porównaj oba wyniki, zamiast zakładać, że jedno wynika z drugiego. Tunel przenoszący zwykłe HTTP i witryna serwująca HTTPS robią dokładnie to, do czego zostały skonfigurowane.

Uruchamiaj kontrole wobec hosta, którego wolno ci testować, i czytaj dane wyjściowe, a nie podsumowanie.

wg show
ip -brief addr show tun0
curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' https://example.com

Gdy tunel działa, a witryna jest HTTPS, masz dwie ochrony na pierwszym odcinku i jedną na drugim. Gdy witryna jest zwykłym HTTP, drugi odcinek jest czytelny dla każdego, kto w nim jest, łącznie z wyjściem, które przekazało żądanie. Wiedza, której z dwóch brakuje, to cała diagnoza, i wymaga dwóch poleceń, a nie nowego klienta.