Czy ECH zastępuje VPN? Co każde z nich naprawdę ukrywa
ECH szyfruje części uzgadniania TLS, które mogą ujawnić zamierzoną nazwę serwera. VPN przenosi ruch do punktu końcowego. Żadne z nich nie wykonuje pracy drugiego.
Włączasz Encrypted Client Hello, otwierasz stronę i połączenie działa. Ktoś pyta, czy VPN jest jeszcze potrzebny, a uczciwa odpowiedź brzmi, że te dwie funkcje ukrywają różne rzeczy przed różnymi stronami. ECH chroni części uzgadniania TLS, które w przeciwnym razie mogą ujawnić nazwę serwera, o którą prosiłeś. VPN umieszcza ruch w tunelu, który kończy się w punkcie końcowym operatora. Mylenie obu prowadzi albo do przepłacania za ochronę, którą już masz, albo do wiary, że masz ochronę, której nigdy nie miałeś.
Co ujawnia uzgadnianie bez ECH
Połączenie TLS zaczyna się od ClientHello, a w starszej formie zamierzona nazwa serwera podróżuje w nim jawnie. Każdy, kto może obserwować uzgadnianie, od operatora sieci po pasywny czujnik na ścieżce, może odczytać tę nazwę, mimo że dane aplikacji są potem szyfrowane. Adres docelowy też jest widoczny, więc nazwa często jest informacją potwierdzającą, a nie jedynym sygnałem.
To jest ten konkretny wyciek, na który celuje ECH. Jest wąski i warto go zawężać, ale to nie to samo co ukrywanie, dokąd zmierza twój ruch.
Co ECH naprawdę zmienia
Przy zgodnym wsparciu klienta i serwera oraz potrzebnej konfiguracji ECH szyfruje wewnętrzny ClientHello kluczami opublikowanymi przez serwer, więc obserwator widzi zewnętrzne uzgadnianie, które nie niesie prawdziwej nazwy serwera. Ruch nadal idzie na ten sam adres, o tych samych porach, w mniej więcej tych samych ilościach. Czas i rozmiar pozostają obserwowalne, a docelowy adres IP nigdy nie był częścią tego, co szyfruje ECH.
Wsparcie też nie jest powszechne. Nie każdy klient, usługa czy pojedyncze połączenie używa ECH, a jego obecności nie można wywnioskować z ikony kłódki ani z faktu zmiany kraju VPN. Zdiagnozowanie go wymaga spojrzenia na uzgadnianie, a nie na ozdobniki przeglądarki.
Co zamiast tego zmienia VPN
VPN przenosi osłonięty ruch w tunelu do punktu końcowego, więc najbliższy tobie obserwator widzi połączenie z VPN, a nie z celem. To zmienia, kto co może obserwować, i zmienia adres, który widzi cel. Nie szyfruje niczego, czego aplikacja już nie zaszyfrowała, i nie ukrywa połączenia przed operatorem VPN, który z założenia jest na ścieżce.
Oba naturalnie się łączą: aplikacja może używać TLS i ECH, podczas gdy tunel chroni otaczający segment sieci. Żadne z nich nie ustala, co każda strona może zobaczyć lub zachować, ponieważ strony zajmują różne pozycje na ścieżce.
Gdzie pasuje DNS
Niezabezpieczone zapytanie DNS ujawnia nazwę resolverowi i każdemu, kto obserwuje tę ścieżkę, co jest osobnym wyeksponowaniem niż uzgadnianie TLS. ECH nie szyfruje DNS, a VPN zmienia tożsamość resolvera tylko wtedy, gdy zapytania też wysyłasz przez tunel lub używasz szyfrowanego resolvera. Ludzie włączają jedną z trzech rzeczy i zakładają, że pozostałe dwie przyszły razem z nią.
Sprawdzaj ścieżkę resolvera osobno od ścieżki uzgadniania. Zawodzą niezależnie i są konfigurowane w różnych miejscach.
Jak rozpoznać, na którą warstwę patrzysz
Zapytaj, co ujawniłaby obserwacja. Jeśli pytanie brzmi, o jaką nazwę serwera poproszono, właściwymi warstwami są uzgadnianie i resolver. Jeśli pytanie brzmi, do której sieci poszedł ruch i kto mógł go zobaczyć w drodze, to tunel. Jeśli pytanie brzmi, które konto co zrobiło na stronie, żadne z nich nie pomaga, bo strona nadal otrzymuje żądanie i każdą podaną przez ciebie tożsamość.
Zachowaj nienaruszoną weryfikację certyfikatów i politykę DNS, badając zgodność. Wyłączenie sprawdzenia, aby test przeszedł, zmienia znaczenie wyniku, zamiast pokazać, co chroni ECH.
Zapisz, którą warstwę naprawdę włączyłeś, zanim dodasz kolejną. Większość zamieszania tutaj bierze się z założenia, że jedna kontrola obejmuje naraz żądanie, jego nazwę, jego cel i jego tożsamość.