Android 17:s ECH-skydd: vad nätverket fortfarande kan se

Android 17:s mest betydelsefulla förändring för nätverksintegritet är stödet för Encrypted Client Hello (ECH). Det är ett tillägg till TLS 1.3 som krypterar värdnamnet – alltså domänen som normalt exponeras i början av en säker anslutning. För Wi-Fi-operatörer, internetleverantörer och andra som övervakar nätverk blir det därmed svårare att se vilken webbplats eller tjänst en app ansluter till. Men ECH gör dig inte anonym. 46

Skyddet fungerar dessutom bara när hela anslutningen stöder tekniken: enheten måste köra Android 17 eller senare, appen måste använda ett ECH-kompatibelt nätverksbibliotek och tjänsten på andra sidan måste ha aktiverat ECH. 25

Vad krypterar ECH?

I en vanlig TLS-anslutning skickar klienten en Server Name Indication (SNI) med värdnamnet som den vill ansluta till. ECH krypterar den känsliga delen av det inledande ClientHello-meddelandet med konfiguration och nyckelmaterial som destinationstjänsten har publicerat. Servern kan dekryptera informationen, medan en observatör på nätverket bara ser en yttre handshake och inte det avsedda värdnamnet. 416

Det spelar roll eftersom HTTPS redan krypterar innehållet i en webbsession, men inte nödvändigtvis namnet på tjänsten som kontaktas. ECH är utformat för att minska just den typen av metadata-läckage för destinationer som stöder tekniken. 56

Vad kan fortfarande synas?

ECH krypterar inte alla delar av en nätverksanslutning. Beroende på anslutningen och var observatören befinner sig kan följande fortfarande vara synligt:

• Enhetens käll-IP-adress.
• Destinationens IP-adress, som kan avslöja en molnleverantör, CDN eller ibland en viss tjänst.
• Tidpunkter, paketstorlekar och mängden trafik.
• DNS-förfrågningar, om DNS inte skyddas separat.

ECH ska därför inte beskrivas som en VPN- eller anonymitetslösning. Google framställer ECH och Privat DNS som kompletterande skydd: ECH döljer värdnamnet i TLS-handshaken, medan krypterad DNS skyddar det separata steget där ett domännamn slås upp. Ingen av funktionerna döljer enhetens IP-adress på egen hand. 612

För den som vill minska domänläckage krävs alltså både ECH och skyddad DNS. Om även IP-adressen måste döljas behövs en separat lösning, till exempel VPN, proxy eller Tor.

Krav och standardbeteende i Android 17

Android 17 tillhandahåller operativsystemstödet och de API:er som nätverksbibliotek behöver för att implementera ECH. Det omfattar bland annat möjligheten att hämta HTTPS-DNS-poster som innehåller ECH-konfigurationer. 4

Det faktiska skyddet beror ändå på tre villkor:

1. Enheten kör Android 17 eller senare.
2. Appens nätverksstack stöder ECH. Androids dokumentation nämner bland annat HttpEngine, WebView och OkHttp, men plattformsstödet gör inte automatiskt alla bibliotek ECH-kompatibla. 23
3. Fjärrservern har aktiverat ECH. Utan serverstöd kan klienten inte kryptera värdnamnet för tjänsten. 25

För appar som riktar sig mot Android 17 eller senare används ECH för TLS-anslutningar när både nätverksbiblioteket och fjärrservern stöder protokollet. Om ECH inte kan användas avgör appens konfiguration för domänkryptering om anslutningen får fortsätta eller måste avbrytas. 12

ECH GREASE: ett sätt att undvika enkel trafikklassificering

Androids policy för domänkryptering är mer avancerad än en enkel av/på-knapp. När domänkryptering är aktiverad men servern inte stöder riktig ECH kan Android skicka ECH GREASE i stället. Tillägget fungerar inte på riktigt, men liknar ECH-trafik.

Syftet är bland annat bättre kompatibilitet och att göra det svårare för nätverkssystem att klassificera trafik på ett förenklat sätt. En observatör ska inte utan vidare kunna dra slutsatsen att en klient aldrig försöker använda ECH bara för att ingen fungerande ECH-anslutning upprättades.

ECH GREASE döljer dock inte värdnamnet på samma sätt som en lyckad ECH-anslutning. Det är en kompatibilitetsmekanism – inte en ersättning för att servern faktiskt distribuerar ECH. 1

Om en app stänger av domänkryptering anger Androids dokumentation att varken ECH eller GREASE ska användas. API:t har också lägen där domänkryptering är aktiverad eller obligatorisk. I det senare fallet ska anslutningen misslyckas om ECH inte kan aktiveras. 1

Vad måste utvecklare göra?

Android 17 skyddar inte automatiskt trafiken från varje app. Utvecklare behöver bland annat:

• Kontrollera att appens nätverksbibliotek har stöd för ECH. 235
• Konfigurera appens Network Security Config eller motsvarande policy för domänkryptering. 15
• Säkerställa att biblioteket kan hämta och använda den ECH-konfiguration som destinationstjänsten annonserar. Android tillhandahåller API:er för HTTPS-DNS-poster med sådan information. 4
• Testa både ECH-kompatibla och inkompatibla servrar – inklusive om appen ska tillåta en reservlösning eller kräva ECH och avbryta anslutningen om skyddet inte kan användas. 1

Serveroperatörer måste i sin tur distribuera ECH och publicera den konfiguration som klienterna behöver. Detta beroende på serversidan är huvudskälet till att Android 17:s plattformsstöd inte omedelbart kommer att dölja alla domännamn som besöks av alla appar. 516

Google uppger att företaget samarbetar med Jigsaw, branschaktörer, tjänsteleverantörer och apputvecklare för att öka användningen. Målet är att göra skyddet av värdnamn tillgängligt via vanlig nätverksinfrastruktur för appar, i stället för att begränsa det till särskilt konfigurerade webbläsare. 46

Fler nätverksskydd i Android 17

Tillgång till lokala nätverk kräver behörighet

Appar som riktar sig mot Android 17 eller senare måste begära körningsbehörigheten ACCESS_LOCAL_NETWORK innan de upptäcker eller ansluter till enheter på det lokala nätverket. Behörigheten ingår i den befintliga gruppen NEARBY_DEVICES. Användare som redan har beviljat en annan behörighet i gruppen behöver därför inte nödvändigtvis få upp en ny behörighetsfråga. 217

Förändringen ska minska risken för att appar i det tysta kartlägger lokala nätverk för spårning, fingeravtryck eller sökning efter sårbara enheter. Appar som legitimt ansluter till exempelvis smarta hem-enheter, cast-mottagare eller annan LAN-utrustning måste deklarera och begära behörigheten. 1719

Certificate Transparency aktiveras som standard

Android 17 aktiverar Certificate Transparency (CT) som standard för TLS-anslutningar. CT hjälper till att upptäcka felaktigt utfärdade offentliga certifikat genom att kräva att certifikaten finns i offentliga och granskbara loggar. Appar kan välja bort funktionen globalt eller för utvalda domäner via nätverkssäkerhetskonfigurationen. 3

Operatörer kan begränsa osäkra 2G-anslutningar

Android 17 innehåller också skydd mot den svagare säkerheten i 2G-nät. Där stödet finns kan mobiloperatörer begränsa eller inaktivera 2G som standard. Det minskar exponeringen mot falska basstationer och så kallade SMS-blaster-attacker. Det exakta beteendet beror på operatörens och enhetens stöd. 8

Slutsatsen: bättre integritet, men ingen osynlighet

ECH är en konkret förbättring. När klient och server stöder standarden försvinner värdnamnet från en viktig del av TLS-handshaken, vilket gör det svårare för nätverksobservatörer att läsa vilken tjänst en app använder.

Men ECH gör inte surfandet osynligt. DNS-inställningar, destinations-IP, tidpunkter, paketstorlekar och trafikmängd kan fortfarande ge ledtrådar.

Den mest träffsäkra sammanfattningen är därför: Android 17 gör webbplats- och tjänstenamn svårare för nätverksobservatörer att läsa, men lämnar andra delar av anslutningens metadata utanför ECH:s skydd.