Android 17 und ein neues Niveau des Netzwerkschutzes: ECH, Schutz des lokalen Netzwerks und Abwehr von 2G-Betrug

Android 17, das am 16. Juni 2026 veröffentlicht wurde und zunächst für die meisten unterstützten Pixel-Geräte verfügbar war, bringt mehrere Änderungen im Bereich der Netzwerksicherheit mit sich, die weit über das Erscheinungsbild oder die alltägliche Bedienung eines Smartphones hinausgehen. Google konzentriert sich dabei auf Informationen, die offengelegt werden können, wenn sich ein Smartphone mit Websites, Apps, Geräten im heimischen WLAN oder Mobilfunknetzen verbindet. Drei Neuerungen sind besonders wichtig: Encrypted Client Hello, kurz ECH, das die angeforderte Domain während einer verschlüsselten Verbindung verbergen kann, strengere Kontrollen für den Zugriff von Apps auf Geräte im lokalen Netzwerk sowie ein stärkerer Schutz vor Angriffen, bei denen Smartphones gezielt auf unsichere 2G-Verbindungen zurückgestuft werden. Keine dieser Maßnahmen macht ein Android-Smartphone vollständig unempfindlich gegenüber Tracking oder Betrug, doch gemeinsam schließen sie mehrere seit Langem bestehende Sicherheitslücken, durch die Netzwerkbetreiber, aufdringliche Apps oder Kriminelle bislang mehr über die Aktivitäten eines Nutzers erfahren konnten als notwendig.

Encrypted Client Hello macht Webverbindungen weniger transparent für Dritte

HTTPS verschlüsselt bereits die Informationen, die zwischen einem Smartphone und einer sicheren Website übertragen werden, darunter Passwörter, Nachrichten und der größte Teil der Seiteninhalte. Bis vor Kurzem konnte jedoch ein Teil des anfänglichen Verbindungsaufbaus weiterhin erkennen lassen, welche Internetdomain das Smartphone aufrufen wollte. Das Problem betrifft die sogenannte Server Name Indication, meist als SNI abgekürzt. Ein Browser oder eine App verwendet diese Information, damit ein Server, auf dem mehrere Websites gehostet werden, weiß, welche davon ausgeliefert werden soll. Bei herkömmlichen TLS-Verbindungen konnte dieser Name sichtbar sein, bevor die vollständig verschlüsselte Sitzung aufgebaut wurde. Dadurch konnten etwa ein WLAN-Betreiber, ein Internetanbieter oder andere Beobachter des Netzwerkverkehrs möglicherweise erkennen, welche Domain aufgerufen wurde, obwohl sie den eigentlichen Inhalt der Verbindung nicht lesen konnten.

Android 17 führt integrierte Unterstützung für Encrypted Client Hello ein, um genau diese Lücke zu verkleinern. ECH verschlüsselt sensible Informationen bereits in der frühen Phase einer TLS-Verbindung, darunter auch den Namen des Servers. Dadurch erhalten Beobachter zwischen dem Smartphone und dem Zielserver weniger verwertbare Informationen darüber, welche unterstützte Website oder welcher Dienst tatsächlich aufgerufen wird. Besonders relevant ist dies in Netzwerken, die der Nutzer nicht selbst kontrolliert, beispielsweise in Hotels, Flughäfen, Cafés oder öffentlichen WLAN-Netzen, deren Datenverkehr über Geräte anderer Betreiber läuft. Gleichzeitig kann dadurch auch die Menge an Informationen reduziert werden, die ein Internetanbieter über aufgerufene Domains erkennen kann.

Eine wichtige Einschränkung bleibt bestehen. Android 17 verbirgt nicht automatisch jede Domain, die von jeder beliebigen App angefordert wird. Bei Apps, die auf Android 17 beziehungsweise API-Level 37 ausgerichtet sind, kann ECH verwendet werden, wenn die eingesetzte Netzwerksoftware dies unterstützt und auch der Zielserver für ECH konfiguriert ist. Google nennt unter anderem WebView, HttpEngine und kompatible Versionen von OkHttp als Beispiele für Komponenten, die die erforderliche Unterstützung bereitstellen können. Unterstützt die Gegenseite ECH nicht, kann Android die betreffenden Informationen nicht einfach verschlüsseln, wenn der Server sie anschließend nicht verarbeiten könnte. ECH stellt daher eine wichtige Verbesserung des Datenschutzes dar, deren tatsächliche Reichweite jedoch mit der zunehmenden Unterstützung durch Entwickler und Website-Betreiber wächst.

Was ECH für die alltägliche Android-Nutzung verändert

Für gewöhnliche Android-Nutzer liegt ein wesentlicher Vorteil darin, dass ECH größtenteils im Hintergrund arbeitet. Es muss nicht jedes Mal ein eigener Datenschutzmodus aktiviert werden, wenn eine unterstützte App eine Verbindung zu einer Website aufbaut. Wenn alle erforderlichen Bestandteile der Verbindung ECH unterstützen, werden die Informationen automatisch im Rahmen der normalen verschlüsselten Sitzung geschützt. Das ist relevant, weil Sicherheits- und Datenschutzfunktionen in der Praxis besonders wirksam sind, wenn Nutzer nicht ständig Einstellungen ändern oder die technischen Details einer TLS-Verbindung verstehen müssen, um davon profitieren zu können.

ECH darf allerdings nicht mit vollständiger Anonymität verwechselt werden. Ein Netzwerk kann weiterhin erkennen, dass das Smartphone Daten überträgt, und in der Regel auch die IP-Adresse sehen, mit der eine Verbindung hergestellt wird. In manchen Fällen wird eine IP-Adresse von zahlreichen Domains gemeinsam genutzt, wodurch sie nur eingeschränkt erkennen lässt, welcher konkrete Dienst aufgerufen wird. In anderen Fällen kann sie dennoch Hinweise auf das Ziel liefern. Auch DNS-Anfragen müssen entsprechend geschützt werden, da eine unverschlüsselte DNS-Abfrage eine Domain bereits offenlegen kann, bevor ECH überhaupt zum Einsatz kommt. Funktionen wie Private DNS unter Android und andere verschlüsselte DNS-Verfahren bleiben daher weiterhin relevant und werden durch ECH nicht ersetzt.

Die praktische Veränderung besteht somit in einer Verringerung unnötiger Offenlegung und nicht darin, dass sämtliche Netzwerkmerkmale unsichtbar werden. Diese Unterscheidung ist wichtig, wenn die Datenschutzverbesserungen von Android 17 realistisch bewertet werden sollen. Wer sich beispielsweise mit einem öffentlichen WLAN verbindet, konnte bereits zuvor den Inhalt einer HTTPS-Sitzung schützen, während die aufgerufene Domain beim Verbindungsaufbau dennoch sichtbar bleiben konnte. ECH kann diese konkrete Lücke schließen, sofern die erforderliche Unterstützung vorhanden ist. Nutzer sollten trotzdem weiterhin Updates installieren, nicht vertrauenswürdige Zertifikate meiden und Browser sowie Apps aktuell halten, da ECH nur einen bestimmten Teil der Netzwerkkommunikation schützt und nicht jede denkbare Form der Datenerfassung verhindert.

Der Schutz des lokalen Netzwerks stellt den Zugriff auf Heimgeräte unter Berechtigungskontrolle

Ein heimisches WLAN kann wesentlich mehr Informationen enthalten, als vielen Nutzern bewusst ist. Smartphones befinden sich häufig im selben lokalen Netzwerk wie Fernseher, Drucker, Lautsprecher, Streaming-Geräte, Computer, Sicherheitskameras und Smart-Home-Geräte. Eine App, die dieses Netzwerk durchsuchen kann, ist möglicherweise in der Lage zu erkennen, welche Geräte vorhanden sind, und deren Kombination als weiteres Merkmal zur Identifizierung eines Haushalts zu verwenden. Vor den neueren Android-Beschränkungen wurde die Kommunikation im lokalen Netzwerk anders behandelt als der Zugriff auf offensichtlich sensible Informationen wie Kamera oder präzisen Standort, obwohl bereits eine detaillierte Liste verbundener Geräte Rückschlüsse auf den Nutzer ermöglichen kann.

Android 17 verändert dies für Apps, die auf API-Level 37 ausgerichtet sind, indem der Schutz lokaler Netzwerke verbindlich durchgesetzt wird. Eine solche App kann nicht mehr ohne Weiteres uneingeschränkten Zugriff auf Geräte im lokalen Netzwerk erhalten, wenn sie diese suchen oder mit ihnen kommunizieren möchte. Android führt dafür die Laufzeitberechtigung ACCESS_LOCAL_NETWORK für Apps ein, die tatsächlich einen umfassenden Zugriff auf das lokale Netzwerk benötigen. Diese Berechtigung gehört zur bestehenden Berechtigungsgruppe Nearby Devices. Das beeinflusst auch, wie die Anfrage für Nutzer dargestellt wird: Wurde einer App bereits eine entsprechende Nearby-Devices-Berechtigung erteilt, erscheint unter Umständen nicht zwangsläufig eine zusätzliche Abfrage nur deshalb, weil die App nun auf die neue Berechtigung für das lokale Netzwerk zugreift.

Die Regel baut auf Änderungen auf, die bereits mit Android 16 eingeführt wurden. Entwickler konnten lokale Netzwerkbeschränkungen dort vorab testen und freiwillig aktivieren, bevor sie für Apps mit Zielversion Android 17 verpflichtend wurden. Ziel ist nicht, legitime Verbindungen zwischen Smartphones und Geräten im Haushalt zu verhindern. Vielmehr unterscheidet Android stärker zwischen Anwendungen, die einen nachvollziehbaren Grund für den Zugriff auf das lokale Netzwerk haben, und Anwendungen, deren Hauptfunktion ohne weitreichenden Zugriff auskommt. Dadurch wird das unbemerkte Scannen lokaler Netzwerke schwieriger und Android erhält eine klarere Grundlage, um Apps einzuschränken, die keinen überzeugenden Grund dafür haben, Geräte in der Umgebung zu untersuchen.

Casting und Smart-Geräte ohne unnötige Sichtbarkeit des gesamten Netzwerks

Viele legitime Android-Funktionen sind auf Geräte in der näheren Umgebung angewiesen. Eine Video-App kann Inhalte auf einen Fernseher übertragen, eine Smart-Home-App eine Lampe oder einen Thermostat steuern und eine Dienstprogramm-App mit einem Drucker oder Netzwerkspeicher kommunizieren. Würde für jede dieser Aktionen uneingeschränkter Netzwerkzugriff vorausgesetzt, entstünde dadurch wiederum ein Datenschutzproblem. Android 17 unterstützt deshalb systemgesteuerte Verfahren zur Geräteauswahl, über die eine App mit einem vom Nutzer ausdrücklich ausgewählten Gerät arbeiten kann, ohne zuvor die Berechtigung erhalten zu müssen, sämtliche Geräte im lokalen Netzwerk zu durchsuchen.

Casting ist dafür ein leicht verständliches Beispiel. Wenn ein Nutzer ein Video auf einen Fernseher übertragen möchte, ist die entscheidende Information, welches konkrete Gerät dafür verwendet werden soll. Die Video-App benötigt nicht zwangsläufig eine dauerhafte Liste aller Computer, Kameras, Lautsprecher und sonstigen erreichbaren Geräte im Haushalt. Eine datenschutzorientierte Geräteauswahl durch das Betriebssystem kann die Auswahl übernehmen und der App anschließend Zugriff auf das ausgewählte Gerät gewähren. Apps, die tatsächlich eine umfassendere und dauerhafte Kommunikation mit Geräten im lokalen Netzwerk benötigen, können dagegen ACCESS_LOCAL_NETWORK anfordern und erklären, weshalb dieser Zugriff erforderlich ist.

Für Nutzer wird der Zugriff auf das lokale Netzwerk dadurch zu einer bewussteren Entscheidung und nicht zu einer unsichtbaren Folge der App-Installation. Eine solche Berechtigungsanfrage kann beispielsweise bei Smart-Home-Verwaltung, Netzwerkdiagnose oder bestimmten Anwendungen zur Gerätesteuerung nachvollziehbar sein, während sie bei einer App ohne Bezug zu Geräten im eigenen Netzwerk deutlich schwerer zu rechtfertigen wäre. Android 17 kann nicht automatisch beurteilen, ob jede einzelne Anfrage berechtigt ist. Die Einführung einer verbindlichen Berechtigungsgrenze reduziert jedoch den automatischen Zugriff und schafft für Entwickler einen stärkeren Anreiz, nur die Netzwerkrechte anzufordern, die ihre Software tatsächlich benötigt.

Android 17 verstärkt den Schutz vor SMS-Betrug über 2G-Netze

Trotz der weit verbreiteten Nutzung von 4G und 5G bleibt die Unterstützung älterer 2G-Netze ein Sicherheitsrisiko, weil ein Smartphone unter bestimmten Umständen von einem modernen Netz auf die ältere Verbindung zurückgestuft werden kann. Kriminelle können gefälschte Mobilfunk-Basisstationen einsetzen, die teilweise als Cell-Site-Simulatoren oder SMS-Blaster bezeichnet werden und in der Nähe potenzieller Opfer ein besonders starkes Mobilfunksignal aussenden. Ein anfälliges Smartphone kann dadurch von LTE oder 5G auf 2G gedrängt werden, wo ältere und schwächere Sicherheitsmechanismen gelten. Angreifer können diese Verbindung anschließend nutzen, um betrügerische SMS einzuschleusen oder andere Arten der Überwachung durchzuführen, die in modernen Mobilfunknetzen erheblich schwieriger wären.

SMS-Blaster sind besonders problematisch, weil betrügerische Nachrichten, die über manipulierte Mobilfunktechnik zugestellt werden, einen Teil der Schutzmechanismen legitimer Mobilfunkanbieter umgehen können. Eine Nachricht kann beispielsweise so gestaltet werden, dass sie scheinbar von einer Bank, einem Paketdienst, einer Behörde oder einem anderen bekannten Absender stammt und den Empfänger anschließend auf eine Phishing-Seite führt. Solche Angriffe funktionieren lokal: Die Täter benötigen geeignete Funktechnik innerhalb der Reichweite der anvisierten Smartphones. Google hat unter anderem auf tragbare sowie in Fahrzeugen montierte Geräte hingewiesen, die in belebten Stadtgebieten eingesetzt werden können. Das zeigt, warum die Möglichkeit moderner Smartphones, weiterhin auf 2G zurückzufallen, von Angreifern ausgenutzt werden kann, selbst wenn Mobilfunkanbieter ihre regulären 2G-Dienste bereits reduzieren.

Android ermöglicht es seit Android 12 auf kompatiblen Geräten, 2G direkt auf Ebene des Mobilfunkmodems zu deaktivieren, sodass das Gerät normalerweise nicht mehr nach 2G-Netzen sucht oder sich mit ihnen verbindet. Android 17 erweitert dieses Konzept, indem Mobilfunkanbieter den 2G-Schutz so konfigurieren können, dass 2G für ihre Kunden standardmäßig deaktiviert ist. Dabei handelt es sich nicht um eine universelle Einstellung, die Google automatisch auf jedem Smartphone mit Android 17 aktiviert. Die stärkere Standardabsicherung hängt sowohl von der Unterstützung des Mobilfunkanbieters als auch vom jeweiligen Gerät ab. Wird sie eingesetzt, ist der Sicherheitsgewinn jedoch erheblich, weil das Smartphone eine potenziell unsichere Verbindung bereits vermeidet, bevor ein SMS-Blaster die Möglichkeit erhält, eine erzwungene Herabstufung auszunutzen.

Was Nutzer über den Schutz vor 2G-Netzen wissen sollten

Zunächst ist wichtig zu verstehen, dass das Abschalten von 2G nicht dasselbe ist wie das Blockieren gewöhnlicher Spam-Nachrichten. Stattdessen wird ein bestimmter Angriffsweg entfernt, der für eine besondere Form von Mobilfunkbetrug genutzt werden kann. Wenn ein Smartphone reguläre 2G-Verbindungen verweigert, kann eine gefälschte Basisstation das Gerät nicht einfach auf 2G zurückstufen und anschließend die üblichen Schwachstellen der älteren Mobilfunktechnik ausnutzen. Das ist besonders in Ländern sinnvoll, in denen reguläre 2G-Dienste bereits abgeschaltet wurden oder kurz vor der Abschaltung stehen, weil moderne Smartphones dort im Alltag kaum noch einen Grund haben, dauerhaft für 2G-Verbindungen verfügbar zu bleiben.

Es gibt dennoch Situationen, in denen 2G weiterhin nützlich sein kann. In einigen Regionen basiert die Mobilfunkversorgung teilweise noch auf älteren Netzen, und Reisende können auf Roaming-Netze treffen, in denen weder 4G noch 5G zuverlässig verfügbar sind. Die Android-Dokumentation weist darauf hin, dass ein Gerät mit deaktiviertem 2G in solchen Situationen seine gewöhnliche Mobilfunkverbindung verlieren kann, bis 2G wieder eingeschaltet wird. Notrufe werden jedoch anders behandelt: Laut Android verhindert die Sicherheitsabschaltung von 2G keine Notrufe, da das Gerät für Notfallkommunikation weiterhin nach verfügbaren 2G-Netzen suchen und diese gegebenenfalls verwenden kann. Damit lässt sich der Schutz im normalen Betrieb erhöhen, ohne eine wichtige Rückfallebene für Notfallsituationen vollständig zu entfernen.

Zusammengenommen richten sich die ECH-Unterstützung in Android 17, die verpflichtenden Kontrollen für lokale Netzwerke bei entsprechend ausgerichteten Apps und die verbesserten Möglichkeiten zur Deaktivierung von 2G gegen drei unterschiedliche Formen der Offenlegung und Manipulation von Daten. ECH reduziert die Menge an Zielinformationen, die bei unterstützten verschlüsselten Verbindungen sichtbar bleiben. Berechtigungen für das lokale Netzwerk begrenzen die unbemerkte Untersuchung von Geräten innerhalb desselben WLANs. Verbesserte 2G-Kontrollen erschweren zudem Angriffe, bei denen Smartphones gezielt auf eine ältere Mobilfunkverbindung zurückgestuft werden, sofern Mobilfunkanbieter und Gerät die Funktion unterstützen. Keine dieser Maßnahmen ersetzt Software-Updates, einen sorgfältigen Umgang mit App-Berechtigungen oder Vorsicht bei unerwarteten Nachrichten. Ihr eigentlicher Wert liegt darin, bestimmte Risiken bereits zu reduzieren, bevor der Nutzer überhaupt darauf reagieren muss, und mehrere bislang vergleichsweise offene Bereiche der Android-Netzwerkkommunikation standardmäßig stärker zu schützen.