HTTPS, DoH, ECH i VPN ukrywają różne rzeczy
Każdy mechanizm usuwa z drogi innego obserwatora i żaden nie usuwa wszystkich. Porównaj, co jest chronione, zanim dodasz kolejny tunel.
Dodanie VPN do przeglądarki, która już używa HTTPS, DoH i ECH, nie układa trzech zabezpieczeń w jedno; zmienia to, kto jest w pozycji obserwowania czego. Każdy mechanizm usuwa inną stronę z innej wymiany i każdy coś zostawia. Użyteczne pytanie nie brzmi, który jest najsilniejszy, ale którego obserwatora próbujesz usunąć, bo odpowiedź decyduje, czy tunel w ogóle pomaga. Porównanie pozostałych obserwatorów jest użyteczniejsze niż lista funkcji.
Cztery mechanizmy, czterej obserwatorzy
Zacznij od czterech relacji i strony, którą każda z nich ma trzymać na zewnątrz. Poniższa tabela jest tą, której używam w przeglądzie, ponieważ zmusza rozmowę do nazwania obserwatora zamiast technologii.
| Mechanizm | Relacja, którą chroni | Obserwator, którego nie usuwa |
|---|---|---|
| HTTPS | Połączenie TLS aplikacji z jej nazwanym punktem końcowym | Sieć dostępowa nadal widzi adres docelowy |
| DoH | Wymiana DNS z wybranym resolverem HTTPS | Ten resolver widzi każde zapytanie |
| ECH | Wrażliwe pola ClientHello, tam gdzie są obsługiwane i akceptowane | Adresy docelowe i DNS, jeśli nie są objęte |
| VPN | Osłonięte pakiety przenoszone do peera VPN | Operator VPN widzi cele |
Wartością tabeli jest to, czego odmawia powiedzenia. Nie szereguje mechanizmów i nie twierdzi, że użycie wszystkich czterech usuwa wszystkich czterech obserwatorów. Aplikacja webowa w chmurze, która już kończy TLS na własnej krawędzi, jest dla tej wymiany chroniona przed siecią dostępową, i żaden tunel nie poprawia tej konkretnej właściwości. Tunel może zmienić to, która sieć widzi pakiety zewnętrzne i który operator jest teraz na drodze.
Co naprawdę ukrywa HTTPS
HTTPS chroni wymianę aplikacji między klientem a punktem końcowym, który nazywa certyfikat. Nie ukrywa adresu docelowego, nie ukrywa, że doszło do połączenia, i nie ukrywa nazwy, chyba że w grze jest ECH. Walidacja certyfikatu jest częścią ochrony, a nie formalnością wokół niej.
VPN nie musi kończyć tego TLS, a wyjście przekazujące nie powinno być traktowane jako uwierzytelniony punkt końcowy aplikacji. Jeśli projekt każe wyjściu odszyfrowywać, to inna architektura z innym oświadczeniem zaufania.
Co przenoszą DoH i ECH, a co zostawiają
DoH przenosi wymianę DNS do resolvera HTTPS, co oznacza, że ten resolver widzi twoje zapytania zamiast resolvera sieci lokalnej. To zmiana realna i ograniczona: wybrany resolver staje się stroną, która może korelować zapytania z adresami, z którymi potem się łączysz, i dokładnie o tej korelacji mówi RFC 8484. Szyfrowany transport nie sprawia, że odbiorca nie wie o zapytaniach, na które odpowiada.
ECH chroni wrażliwą część ClientHello, aby pasywny obserwator na drodze nie mógł odczytać zamierzonej nazwy serwera. Zależy to od wspierającego wdrożenia oraz od akceptacji przez serwer i sieć, i pozostawia inne kanały na miejscu: adresy docelowe pozostają widoczne, a DNS nadal może ujawnić nazwę.
Inną rzeczą, której ECH nie robi, jest udowadnianie samego siebie. Połączenie używające TLS 1.3 nie jest dowodem, że ECH zostało zaakceptowane, a przeglądarka oferująca ECH serwerowi bez wsparcia wycofuje się po cichu. Sprawdzaj rzeczywisty stan połączenia, zamiast wnioskować go z wersji protokołu.
Taki jest ogólny kształt całego tego porównania: każdy mechanizm jest weryfikowany na własnej warstwie i żaden z nich nie jest weryfikowany sukcesem innego.
Co przenosi VPN, a co dodaje
Gdy ruch webowy wchodzi do VPN, sieć dostępowa widzi zewnętrzną wymianę z peerem VPN zamiast pojedynczych połączeń aplikacji, a operator VPN zajmuje pozycję na dalszej drodze. To przeniesienie granicy zaufania, a nie jej usunięcie. Operator widzi teraz, do jakich celów docierasz, nawet jeśli treść pozostaje szyfrowana od końca do końca. Czy to poprawa, zależy wyłącznie od tego, której z tych dwóch stron ufasz mniej.
Zachowaj HTTPS aplikacji i zamierzoną ochronę resolvera na miejscu, robiąc to. Tunel nie zastępuje walidacji certyfikatu, a wyłączanie zabezpieczeń resolvera dlatego, że ruch idzie przez tunel, usuwa kontrolę bez jej zastąpienia.
Wybór z wymagania
Nazwij rzeczywiste wymaganie, bo to ono decyduje o projekcie. Dopuszczenie do zasobów prywatnych, zarządzany punkt wyjścia, konkretne zagrożenie sieci dostępowej i autoryzacja urządzeń to cztery różne potrzeby z czterema różnymi odpowiedziami, a firma używająca tylko publicznych aplikacji chmurowych nadal musi zdecydować o autoryzacji i przetwarzaniu danych. Dodatkowe warstwy mogą być właściwe, nie będąc wymiennymi. Bardziej złożone połączenie nie jest miarą anonimowości i samo w sobie nie jest argumentem bezpieczeństwa.
Specyfikacja ECH, RFC 9849, jest warta przeczytania ze względu na to, co mechanizm obejmuje, a czego nie, i jest uczciwa co do kanałów, które zostawia w spokoju. Porównuj mechanizmy według obserwatora, którego każdy usuwa, zapisz tego obserwatora, a potem zdecyduj, czy dodatkowa warstwa się nim zajmuje. Jeśli odpowiedź brzmi, że obserwator już był poza twoim modelem zagrożeń, tunel jest kosztem bez korzyści.