Szyfrowanie tunelu WSS kończy się na terminatorze TLS, nie w aplikacji

Tunel przenoszony wewnątrz bezpiecznego WebSocketa ma dokładnie tyle szyfrowania, ile klient w niego włożył, nie więcej. Schemat wss:// mówi, że TLS chroni jedno połączenie na jednym skoku. Nie mówi nic o tym, czy bajty wewnątrz komunikatów WebSocket są chronione osobno, i właśnie ta różnica decyduje, kto może czytać twój ruch, gdy coś pośrodku kończy TLS.

Dwie warstwy, które wyglądają jak jedna

Bezpieczny WebSocket to TLS z uściskiem dłoni WebSocket wykonanym na nim, jak opisuje RFC 6455 w sekcjach o połączeniu i bezpieczeństwie. Warstwa TLS uwierzytelnia serwer i szyfruje strumień, a następnie warstwa WebSocket dzieli na ramki to, co aplikacja zdecyduje się wysłać.

To dwie niezależne decyzje, a diagram rysujący jedną kłódkę na całej ścieżce ukrywa drugą. Zapytaj, kto kończy połączenie TLS. Potem zapytaj, co klient umieszcza w każdej wiadomości. Wszystko inne o wdrożeniu wynika z tych dwóch odpowiedzi.

Projekt A: transport to jedyne szyfrowanie

W prostszym projekcie klient bierze surowe pakiety IP i opakowuje je w komunikaty WebSocket. Nic w środku nie jest szyfrowane, więc komponent trzymający sesję TLS czyta ładunki jako czysty tekst. Gdy tym komponentem jest twój własny serwer tunelu, jest to zamierzony punkt końcowy, a projekt jest spójny, bo serwer i tak widziałby ruch.

Staje się to innym układem, gdy na ścieżce siedzi proxy inspekcyjne i kończy TLS certyfikatem, któremu klient ufa. To proxy ma teraz ten sam czysty tekst, który miałby serwer, i żadna ilość ramkowania WebSocket tego nie zmienia. Magazyn zaufania klienta przesądził o tym wyniku na długo przed otwarciem tunelu, ponieważ wybrał akceptację tego certyfikatu dla tej nazwy. Proxy widzi też żądany host i rozmiar każdej wiadomości, co wystarcza do pobrania odcisku wielu działań bez dalszego odszyfrowywania.

Projekt B: ładunek niesie własne klucze

W drugim projekcie klient szyfruje i uwierzytelnia swoje pakiety protokołem VPN, który ma własną tożsamość partnera i wymianę kluczy, a następnie przenosi wynik w komunikatach WebSocket. Zakończenie zewnętrznego TLS tutaj ujawnia szyfrogram, a nie ruch. Proxy może zobaczyć rozmiary i czasy wiadomości, i nic więcej w ładunku. To znacznie mniejsze narażenie, a mimo to metadane, które warto nazwać w przeglądzie, zamiast je zbywać.

Własne punkty końcowe wewnętrznego protokołu nadal widzą czysty tekst, co jest sensem tego układu i zarazem jego granicą. Jeśli komponent na punkcie końcowym ma prawo czytać dane przed szyfrowaniem lub po odszyfrowaniu, dodatkowa warstwa go nie ogranicza. Klucze i oprogramowanie, które nimi zarządza, pozostają granicą, która ma znaczenie.

Etykieta VPN, znajoma ikona klienta lub strona marketingowa nie są dowodem, że ten projekt istnieje. Czytanie formatu ładunku jest.

Prześledź, gdzie naprawdę pojawia się czysty tekst

Schemat adresu URL daje jeden fakt, więc resztę weź z interfejsów. Wykonaj poniższe sprawdzenia po kolei, bo każde zawęża następne:

ss -tnp | grep -E ':(443|8443)\b'
ip -br link show type tun
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
tcpdump -ni tun0 -c 5 -X

Zacznij od połączenia zewnętrznego. Jedna długotrwała sesja TCP do portu TLS to wygląd nośnika WebSocket, a druga sesja do niepowiązanego hosta zasługuje na wyjaśnienie, zanim spojrzysz głębiej. Następnie znajdź interfejs tunelu na kliencie, bo urządzenie tun lub tap mówi, że klient obsługuje pakiety IP, a nie pośredniczy w jednym strumieniu aplikacji.

Przechwycenie na interfejsie tunelu zwykle rozstrzyga kwestię ładunku. Czytelne nagłówki oznaczają, że wewnętrzne pakiety nigdy nie były szyfrowane osobno, a ładunki o wysokiej entropii oznaczają, że były. Powtórz przechwycenie na interfejsie zewnętrznym i porównaj oba: jeśli oba wyglądają losowo, warstwa wewnętrzna wykonuje pracę, której zewnętrzna nie może cofnąć.

Przejrzyj zaufanie, którego naprawdę udzieliłeś

Zainstalowany korporacyjny certyfikat główny jest faktem o magazynie zaufania klienta, a nie twierdzeniem o tym, co rejestruje lub sprawdza jakiekolwiek proxy. Ustal wdrożoną politykę i rzeczywistą ścieżkę połączenia, zamiast wnioskować o zachowaniu z obecności CA.

Na sprzęcie zarządzanym zapytaj administratora, który komponent kończy TLS, czy klient weryfikuje certyfikat przypięty czy publiczny, i jaki jest format ładunku. Te trzy odpowiedzi dają ustalenie, którego możesz później bronić.

Zapisz wynik jako granicę, a nie wyrok. "TLS kończy się na proxy inspekcyjnym, a wewnętrzny ładunek jest osobno szyfrowany kluczami, które mają tylko punkty końcowe" to sprawdzalne stwierdzenie, które przetrwa zmianę dostawcy. "WebSockets są bezpieczne" nie.