Android 17 får ECH: Sådan beskyttes webstedernes navne, og hvad der stadig kan ses

Android 17's vigtigste ændring inden for netværksprivatliv er platformunderstøttelse til Encrypted Client Hello (ECH). Det er en udvidelse til TLS 1.3, som krypterer det værtsnavn, der normalt afsløres i begyndelsen af en sikker forbindelse. Dermed lækker der færre oplysninger om, hvilket websted eller hvilken tjeneste en app kontakter, til Wi-Fi-ejere, internetudbydere og andre, der overvåger netværket. Det betyder dog ikke fuld anonymitet. 46

ECH giver kun beskyttelse, når hele forbindelsen er på plads: Enheden skal køre Android 17 eller nyere, appen skal bruge et netværksbibliotek med ECH-understøttelse, og den tjeneste, appen vil forbinde til, skal have implementeret ECH. 25

Hvad krypterer ECH?

I en almindelig TLS-forbindelse sender klienten en Server Name Indication (SNI) med værtsnavnet på den tjeneste, den vil besøge. ECH krypterer denne følsomme del af det indledende ClientHello ved hjælp af konfiguration og nøglemateriale, som tjenesten selv offentliggør. Serveren kan dekryptere oplysningerne, mens en observatør på netværket i stedet ser et ydre håndtryk uden det egentlige værtsnavn. 416

Det er relevant, fordi HTTPS allerede krypterer indholdet i en websession, men værtsnavnet stadig kan afsløre, hvilken tjeneste en app kontakter. ECH er udviklet til at begrænse netop denne form for metadata-lækage for tjenester, der understøtter standarden. 56

Hvad kan netværket stadig se?

ECH krypterer ikke alle dele af en netværksforbindelse. Afhængigt af forbindelsen og observatørens placering kan følgende oplysninger fortsat være synlige:

• Enhedens kilde-IP-adresse.
• Destinations-IP-adressen, som kan pege på en hostingudbyder, et CDN eller i nogle tilfælde en bestemt tjeneste.
• Tidspunkter, pakkestørrelser og den samlede trafikmængde.
• DNS-opslag, hvis DNS-forespørgslen ikke er beskyttet separat.

Derfor bør ECH ikke beskrives som en VPN eller et anonymitetssystem. Google fremstiller ECH og Private DNS som to supplerende beskyttelser: ECH skjuler værtsnavnet i TLS-håndtrykket, mens krypteret DNS beskytter det separate trin, hvor et domænenavn slås op. Ingen af funktionerne skjuler i sig selv enhedens IP-adresse. 612

Krav og standardindstillinger i Android 17

Android 17 leverer operativsystemunderstøttelsen og de API'er, som netværksbiblioteker skal bruge til at implementere ECH. Det omfatter blandt andet muligheden for at hente HTTPS-DNS-poster med ECH-konfigurationer. 4

Den faktiske beskyttelse afhænger stadig af tre ting:

1. Enheden kører Android 17 eller nyere.
2. Appens netværksstak understøtter ECH. Androids dokumentation nævner blandt andet HttpEngine, WebView og OkHttp, men platformunderstøttelse gør ikke automatisk alle biblioteker ECH-kompatible. 23
3. Den eksterne server har implementeret ECH. Uden konfiguration på serversiden kan klienten ikke kryptere destinationsværtsnavnet for den pågældende tjeneste. 25

For apps, der er målrettet Android 17 eller nyere, bruges ECH til TLS-forbindelser, når både netværksbiblioteket og den eksterne server understøtter protokollen. Hvis ECH ikke kan anvendes, afgør appens politik for domænekryptering, om forbindelsen må fortsætte, eller om den skal afvises helt. 12

Sådan fungerer ECH GREASE

Androids politik for domænekryptering er mere nuanceret end en simpel tænd/sluk-knap. Når domænekryptering er aktiveret, men en server ikke understøtter ægte ECH, kan Android sende ECH GREASE i stedet. Udvidelsen fungerer med vilje ikke, men ligner ECH-trafik.

Formålet er både kompatibilitet og modstand mod simpel trafikklassificering. Netværkssystemer skal ikke uden videre kunne konkludere, at en klient aldrig forsøger ECH, blot fordi der ikke blev oprettet en brugbar ECH-forbindelse. GREASE skjuler dog ikke værtsnavnet på samme måde som en vellykket ECH-forbindelse. Det er en kompatibilitetsmekanisme – ikke en erstatning for ECH på serversiden. 1

Hvis en app deaktiverer domænekryptering, siger dokumentationen for Androids NetworkSecurityPolicy, at hverken ECH eller GREASE bør bruges. Det samme API giver adgang til tilstande for domænekryptering, herunder aktiveret og påkrævet. 1

Hvad skal udviklere ændre?

Android 17 beskytter ikke automatisk trafikken fra alle apps. Udviklere bør:

• Kontrollere, at appens netværksbibliotek har integreret ECH-understøttelse. 235
• Konfigurere appens Network Security Config eller tilsvarende politik for domænekryptering. 15
• Sikre, at biblioteket kan hente og anvende den ECH-konfiguration, som tjenesten offentliggør. Android leverer platform-API'er til at hente HTTPS-DNS-poster med ECH-konfigurationsdata. 4
• Teste både ECH-kompatible og ECH-inkompatible servere, herunder om appen skal tillade fallback eller kræve ECH og afvise forbindelsen, hvis det ikke kan bruges. 1

Serveroperatører skal også implementere ECH og offentliggøre den konfiguration, klienterne har brug for. Denne afhængighed af tjenesten på serversiden er hovedårsagen til, at Androids platformunderstøttelse ikke med det samme skjuler alle værtsnavne fra alle apps. 516

Google oplyser, at virksomheden samarbejder med Jigsaw, brancheaktører, tjenesteudbydere og appudviklere for at udbrede teknologien. Målet er at gøre beskyttelse af værtsnavne tilgængelig for apps via almindelig netværksinfrastruktur i stedet for kun at tilbyde den i særligt konfigurerede browsere. 46

Andre netværksbeskyttelser i Android 17

Adgang til lokalnetværket kræver en kørselstilladelse

Apps, der er målrettet Android 17 eller nyere, skal anmode om kørselstilladelsen ACCESS_LOCAL_NETWORK, før de kan finde eller oprette forbindelse til enheder på lokalnetværket. Tilladelsen hører til den eksisterende gruppe NEARBY_DEVICES, så brugere, der allerede har givet en anden tilladelse i gruppen, muligvis ikke får vist endnu en gruppedialog. 217

Ændringen skal begrænse skjult scanning af lokalnetværk, som kan bruges til sporing, fingeraftryk eller søgning efter sårbare enheder. Apps, der legitimt forbinder til smart-home-udstyr, cast-modtagere eller andre enheder på hjemmenetværket, skal deklarere og anmode om tilladelsen. 1719

Certificate Transparency er aktiveret som standard

Android 17 aktiverer Certificate Transparency (CT) som standard for TLS-forbindelser. CT gør det lettere at opdage certifikater, der er udstedt forkert, ved at kræve, at offentlige certifikater optræder i offentlige og kontrollerbare logfiler. Apps kan fravælge funktionen globalt eller for udvalgte domæner via netværkssikkerhedskonfigurationen. 3

Teleselskaber kan begrænse usikre 2G-forbindelser

Android 17 introducerer også en beskyttelse mod den svage sikkerhed i 2G-mobilnetværk. Funktionen gør det muligt for teleselskaber at begrænse eller som standard deaktivere 2G-forbindelser, hvor enheden og operatøren understøtter det. Det kan mindske eksponeringen for falske basestationer og såkaldte SMS-blaster-angreb. Den præcise funktion afhænger af operatørens og enhedens understøttelse. 8

Den praktiske dom over privatlivsbeskyttelsen

ECH er en reel forbedring, fordi teknologien fjerner værtsnavnet fra en central del af TLS-håndtrykket, når både klienten og serveren understøtter standarden. Men den gør ikke internetbrug usynlig. DNS-konfiguration, destinations-IP-adresser, tidspunkter, pakkestørrelser og trafikmængde kan stadig give netværksobservatører fingerpeg.

For bedre beskyttelse af domænenavne bør ECH kombineres med krypteret DNS. Hvis målet også er at skjule IP-adressen, kræves et separat system som en VPN, proxy eller Tor.

Den mest præcise beskrivelse af Android 17's ændring er derfor: Den gør websteders og tjenesters navne sværere for netværksobservatører at aflæse, men andre lag af forbindelsens metadata er stadig uden for ECH's beskyttelse.