Android 17 i ECH: jakie dane ukrywa nowa ochrona prywatności, a co nadal widać

Najważniejszą zmianą Androida 17 w obszarze prywatności sieci jest obsługa Encrypted Client Hello (ECH). To rozszerzenie TLS 1.3, które szyfruje nazwę hosta ujawnianą zwykle na samym początku bezpiecznego połączenia. Dzięki temu operator Wi-Fi, dostawca internetu czy inny obserwator sieci ma mniejszą szansę ustalić, z jaką konkretnie witryną lub usługą łączy się aplikacja. Nie oznacza to jednak pełnej anonimowości. 46

ECH zadziała dopiero wtedy, gdy spełnione zostaną trzy warunki: urządzenie będzie korzystać z Androida 17 lub nowszego, aplikacja użyje biblioteki sieciowej obsługującej ECH, a serwer docelowy wdroży ten standard. 25

Co szyfruje ECH?

W typowym połączeniu TLS klient wysyła pole Server Name Indication (SNI) zawierające nazwę hosta, z którym chce się połączyć. ECH szyfruje wrażliwą część początkowej wiadomości ClientHello, korzystając z konfiguracji i klucza opublikowanych przez usługę docelową. Serwer potrafi odczytać chronione informacje, natomiast obserwator sieci widzi jedynie zewnętrzną warstwę uzgadniania, a nie właściwą nazwę hosta. 416

Ma to znaczenie nawet wtedy, gdy korzystamy z HTTPS. Protokół ten szyfruje treść sesji, ale sama nazwa odwiedzanej usługi może nadal zdradzać, z czym łączy się aplikacja. ECH ogranicza właśnie ten rodzaj wycieku metadanych — oczywiście tylko dla obsługiwanych celów. 56

Jakie informacje nadal pozostają widoczne?

ECH nie szyfruje całego połączenia ani wszystkich metadanych. W zależności od miejsca, w którym znajduje się obserwator, nadal dostępne mogą być:

• adres IP urządzenia;
• docelowy adres IP, który może wskazywać dostawcę hostingu, sieć CDN, a czasem także konkretną usługę;
• czas nawiązywania połączenia, rozmiary pakietów i ilość przesyłanych danych;
• zapytania DNS, jeśli nie są dodatkowo chronione.

Dlatego ECH nie jest VPN-em ani systemem zapewniającym anonimowość. Google przedstawia ECH i Prywatny DNS jako uzupełniające się zabezpieczenia: ECH ukrywa nazwę hosta w uzgadnianiu TLS, a szyfrowany DNS chroni osobny etap, w którym nazwa domeny jest zamieniana na adres IP. Żadne z tych rozwiązań samo w sobie nie ukrywa adresu IP urządzenia. 612

Wymagania i domyślne działanie w Androidzie 17

Android 17 udostępnia systemowe wsparcie i interfejsy API potrzebne bibliotekom sieciowym do wdrożenia ECH. Obejmuje to między innymi możliwość pobierania rekordów HTTPS DNS zawierających konfigurację ECH. 4

Rzeczywista ochrona zależy jednak od trzech elementów:

1. Urządzenie działa pod kontrolą Androida 17 lub nowszego.
2. Stos sieciowy aplikacji obsługuje ECH. W dokumentacji Androida wymieniono między innymi HttpEngine, WebView i OkHttp, ale samo wsparcie systemu nie sprawia, że każda biblioteka automatycznie korzysta z ECH. 23
3. Serwer zdalny wdrożył ECH. Bez konfiguracji po stronie serwera klient nie może zaszyfrować nazwy docelowej usługi. 25

W aplikacjach kierowanych na Androida 17 lub nowszego ECH jest używany dla połączeń TLS, jeśli obsługują go zarówno biblioteka sieciowa, jak i serwer. Jeżeli ECH nie może zostać zastosowany, o dalszym przebiegu połączenia decyduje skonfigurowana przez aplikację polityka szyfrowania domen. W trybie wymaganym połączenie może zostać przerwane, czyli zakończyć się bez awaryjnego przejścia do słabszej ochrony. 12

Czym jest ECH GREASE?

Polityka szyfrowania domen w Androidzie 17 nie ogranicza się do prostego przełącznika „włączone” lub „wyłączone”. Gdy szyfrowanie domen jest aktywne, ale serwer nie obsługuje prawdziwego ECH, Android może wysłać ECH GREASE — celowo niefunkcjonalne rozszerzenie przypominające ruch ECH.

Mechanizm ma poprawiać kompatybilność i utrudniać proste klasyfikowanie ruchu. Obserwator nie powinien móc łatwo założyć, że brak udanego połączenia ECH oznacza, iż klient w ogóle nie próbuje korzystać z tego standardu. GREASE nie ukrywa jednak nazwy hosta tak jak prawidłowo działające ECH. To mechanizm kompatybilności, a nie zamiennik wdrożenia ECH na serwerze. 1

Jeśli aplikacja wyłączy szyfrowanie domen, dokumentacja NetworkSecurityPolicy wskazuje, że Android nie powinien używać ani ECH, ani GREASE. To samo API udostępnia tryby szyfrowania domen, w tym tryb włączony oraz wymagany. 1

Co muszą zrobić twórcy aplikacji?

Samo pojawienie się obsługi ECH w Androidzie 17 nie zabezpieczy automatycznie ruchu każdej aplikacji. Deweloperzy powinni:

• sprawdzić, czy używana biblioteka sieciowa ma zintegrowaną obsługę ECH; 235
• skonfigurować Network Security Config lub równoważną politykę szyfrowania domen; 15
• upewnić się, że biblioteka potrafi pobrać i wykorzystać konfigurację ECH reklamowaną przez usługę docelową; Android udostępnia do tego interfejsy API umożliwiające pobieranie rekordów HTTPS DNS z konfiguracją ECH; 4
• przetestować zachowanie aplikacji zarówno z serwerami obsługującymi ECH, jak i tymi, które go nie obsługują — w tym zdecydować, czy dopuszczalny jest fallback, czy połączenie ma być zrywane bez ECH. 1

Swoją część muszą wykonać również operatorzy serwerów: wdrożyć ECH i opublikować konfigurację potrzebną klientom. Ta zależność po stronie usług oznacza, że systemowe wsparcie Androida 17 nie sprawi od razu, że nazwy wszystkich odwiedzanych domen zostaną ukryte w każdej aplikacji. 516

Google deklaruje współpracę z Jigsaw, przedstawicielami branży, dostawcami usług i twórcami aplikacji, aby rozszerzyć wykorzystanie ECH. Celem jest udostępnienie ochrony nazw hostów aplikacjom korzystającym ze wspólnej infrastruktury sieciowej, a nie ograniczenie jej wyłącznie do specjalnie skonfigurowanych przeglądarek. 46

Pozostałe zabezpieczenia sieciowe w Androidzie 17

Dostęp do sieci lokalnej wymaga uprawnienia

Aplikacje kierowane na Androida 17 lub nowszego muszą poprosić o uprawnienie czasu wykonywania ACCESS_LOCAL_NETWORK, zanim zaczną wykrywać urządzenia w sieci lokalnej lub łączyć się z nimi. Uprawnienie należy do istniejącej grupy NEARBY_DEVICES, dlatego użytkownicy, którzy wcześniej przyznali już inne uprawnienie z tej grupy, mogą nie zobaczyć drugiego pytania na poziomie grupy. 217

Zmiana ma ograniczyć działające po cichu skanowanie sieci lokalnej, które może służyć do śledzenia, tworzenia odcisku urządzenia lub wyszukiwania podatnego sprzętu. Aplikacje łączące się legalnie z urządzeniami smart home, odbiornikami do przesyłania obrazu czy innym sprzętem w sieci LAN muszą zadeklarować i poprosić o odpowiednie uprawnienie. 1719

Certificate Transparency jest domyślnie włączone

Android 17 domyślnie włącza Certificate Transparency (CT) dla połączeń TLS. Mechanizm pomaga wykrywać nieprawidłowo wystawione publiczne certyfikaty, wymagając umieszczania ich w publicznych, możliwych do audytu rejestrach. Aplikacje mogą wyłączyć CT globalnie albo tylko dla wybranych domen za pomocą konfiguracji bezpieczeństwa sieci. 3

Operatorzy mogą ograniczać połączenia 2G

Android 17 dodaje również zabezpieczenia związane ze słabym poziomem ochrony sieci 2G. W obsługiwanych konfiguracjach operatorzy mogą domyślnie ograniczać lub wyłączać łączność 2G, zmniejszając narażenie na fałszywe stacje bazowe i ataki typu SMS-blaster. Dokładne działanie zależy od wsparcia operatora oraz urządzenia. 8

Werdykt: ważna poprawa, ale nie pełna niewidzialność

ECH to istotny krok naprzód, ponieważ usuwa nazwę hosta z kluczowej części uzgadniania TLS — pod warunkiem, że standard obsługują zarówno klient, jak i serwer. Nie sprawia jednak, że przeglądanie internetu staje się niewidoczne. Zapytania DNS, docelowe adresy IP, czas połączeń, rozmiary pakietów i ilość ruchu nadal mogą dostarczać wskazówek.

Dla silniejszej ochrony nazw domen ECH warto łączyć z szyfrowanym DNS. Jeśli potrzebne jest ukrycie adresu IP, konieczne będzie osobne rozwiązanie, takie jak VPN, serwer proxy lub Tor.

Najtrafniej można więc podsumować zmianę w Androidzie 17 tak: nazwy odwiedzanych witryn i usług stają się trudniejsze do odczytania dla obserwatorów sieci, ale pozostałe warstwy metadanych połączenia nadal pozostają poza ochroną ECH.