Szyfrowany klient Hello i DoH: czego zapory obwodowe nie są już w stanie zobaczyć

Przez dwadzieścia lat sieciowe zapory sieciowe i serwery proxy opierały się na jednym niezaszyfrowanym polu, aby wiedzieć, dokąd zmierza zaszyfrowany ruch: wskaźniku nazwy serwera (SNI), czyli nazwie hosta ogłaszanej przez klienta w pierwszej wiadomości podczas uzgadniania TLS. DNS przez HTTPS (DoH, RFC 8484) już ukrył wyszukiwanie DNS poprzedzające połączenie. Zaszyfrowany klient Hello, teraz opublikowany jako RFC 9849, ukrywa sam SNI. Razem usuwają dwa sygnały, na których zbudowano większość filtrów wychodzących.

Jak działa ECH: wewnętrzny i zewnętrzny ClientHello

Za pomocą ECH klient tworzy dwie wiadomości ClientHello. Wewnętrzny zawiera prawdziwe miejsce docelowe i wrażliwe parametry i jest szyfrowany za pomocą HPKE do klucza publicznego opublikowanego wcześniej przez serwer. Zewnętrzny, przesyłany jawnie, ma wspólną nazwę publiczną, zwykle nazwę interfejsu dostawcy, więc obserwator dowiaduje się jedynie, że klient rozmawia z tym dostawcą (RFC 9849; Wyjaśnienie Cloudflare).

TLS ClientHello (outer, cleartext)
  server_name:            cloudflare-ech.com      <- shared public name
  encrypted_client_hello: <HPKE ciphertext>        <- real hostname is inside

Skąd pochodzi klucz: rekord DNS HTTPS

Klient potrzebuje klucza publicznego ECH serwera przed uzgadnianiem. Pobiera go z DNS, w rekordzie zasobu HTTPS (typ 65, RFC9460), którego parametr ech zawiera ECHConfigList. Zapytaliśmy prawdziwego. dig dostarczany z systemem macOS nie zna rekordu według nazwy, więc poproś o podanie numeru:

$ dig crypto.cloudflare.com TYPE65 +short
\# 133 0001000001000302683200040008A29F874FA29F884F000500470045 FE0D0041AF…
     …0012636C6F7564666C6172652D6563682E636F6D
# 0005 = the "ech" key, FE0D = ECH config version, and the last bytes decode to
# the ASCII public name: cloudflare-ech.com

Jeśli samo zapytanie DNS przechodzi przez DoH, obserwator sieci nie widzi ani wyszukiwania, ani (w przypadku ECH) nazwy hosta podczas uzgadniania. To właśnie o tej kombinacji jest mowa w tym artykule.

To, czy ECH zostanie zastosowany, zależy od klienta

ECH nie jest czymś, co włącza sieć; decyduje każdy klient. Przeglądarki dostarczyły obsługę (Stan platformy Chrome), zazwyczaj powiązaną z używanym szyfrowanym DNS. Wiele programów w ogóle z niego nie korzysta. Punkt końcowy śledzenia Cloudflare raportuje otrzymane informacje, a curl wbudowany w macOS nadal wysyła nazwę hosta w sposób wyraźny:

$ curl -s https://crypto.cloudflare.com/cdn-cgi/trace | grep -E "^(tls|sni)="
tls=TLSv1.3
sni=plaintext

Zatem dzisiejszy realistyczny obraz jest mieszany: przeglądarki coraz częściej ukrywają nazwę hosta, wiele innych programów tego nie robi, a oprogramowanie napisane w celu uniknięcia monitorowania może celowo używać ECH i DoH.

Co traci zapora sieciowa i co zatrzymuje

Szczerze mówiąc, filtrowanie oparte na nazwach hostów na brzegu sieci przestaje działać w przypadku ruchu ECH, podczas gdy kontrole oparte na adresach IP nie. Sieć może nadal odmawiać połączeń znanym programom rozpoznawania nazw DoH, co w praktyce uniemożliwia także przeglądarkom uzyskiwanie kluczy ECH za pośrednictwem zaszyfrowanego DNS i nadal może blokować zakresy adresów. Jedyne, czego nie może już zrobić, to rozróżnić dwie witryny tego samego dostawcy lub pozwolić jednej i zablokować drugą, bez naruszania protokołu TLS w sposób, który ECH ma wykrywać.

Widoczność przesuwa się do punktu końcowego

Jedynym miejscem, w którym nazwa hosta nigdy nie jest ukryta, jest maszyna, która nawiązuje połączenie: program pyta o to po nazwie. Dlatego ECH przesuwa kontrolę wyjścia w kierunku punktu końcowego. Zapora sieciowa oparta na hoście w ogóle nie musi czytać uzgadniania; widzi, który proces otworzył połączenie, z jakim adresem i kiedy program rozpoznał nazwę, jaką nazwę, zanim opuszczą jakiekolwiek zaszyfrowane bajty. Widzi także to, czego urządzenie sieciowe nigdy nie było w stanie osiągnąć, nawet przed ECH: która aplikacja na komputerze się z nią łączy.

• Zdecyduj o aplikacji, a nie o nazwie hosta: przeglądarka, klient synchronizacji i nieznany plik binarny mają różne reguły.
• Traktuj program, który uruchamia swój własny DoH dla resolwera, którego system nie skonfigurował, jako sygnał warty obejrzenia.
• Trzymaj listy blokowania oparte na adresach IP na krawędzi; nadal działają i nic nie kosztują.

Jaką rolę odgrywają FireAI i HisnLabs

ECH hides the hostname from the network, not from the machine making the connection: an on-device firewall such as FireAI still sees which process is connecting and where, and asks before an app it does not know goes online.

FireAI to własny produkt HisnLabs: zapora sieciowa z AI działająca bezpośrednio na Macu. Pokazuje prostym językiem każde połączenie nawiązywane przez twoje aplikacje i pozwala ci decydować, co opuszcza twojego Maca — jej AI działa lokalnie, więc twój ruch nigdy nie jest wysyłany do nas ani do nikogo innego. Zespół badań nad bezpieczeństwem HisnLabs dba o to, by te decyzje pozostały trafne: kataloguje, które domeny to zwykła telemetria, a które prawdziwa usługa, śledzi kraj i sieć stojące za połączeniem oraz trenuje lokalny model (funkcję Autopilot) na rzeczywistych wzorcach ruchu — a nic z tego nie opuszcza twojego Maca.

Możesz przeczytać o decyzjach technicznych, które za tym stoją, albo wypróbować FireAI przez 17 dni na FireAI od HisnLabs.