android:usesCleartextTraffic="true" eine globale Ausnahmegenehmigung erhalten. Damit ist im Zuge der Anpassungen der Google-Play-Entwicklerrichtlinien und des App-Targeting auf API Level 36+ endgültig Schluss.
Google stuft die globale Deaktivierung von TLS-Zwängen als veraltet ein und verwehrt Anwendungen, die ab Juli 2026 auf neuere API-Level abziehen, das uneingeschränkte Senden von unverschlüsseltem Klartext-Traffic. Für Softwarearchitekten, Android-Entwickler und IT-Security-Spezialisten erfordert diese Härtungsmaßnahme eine grundlegende Überprüfung der Netzwerkarchitektur – insbesondere beim Zusammenspiel von Apps mit legacy On-Premises-Systemen, IoT-Schnittstellen oder internen Testumgebungen.
🔥 Mein Krypto-Tipp für deinen Homescreen
Du willst deine Krypto-Kurse auf einen Blick auf deinem Homescreen haben – ohne lästige Werbung oder Datenkraken im Hintergrund? Lade dir jetzt meine App herunter!
1. Die technische Problemstellung: Warum das Manifest-Flag eine Sicherheitslücke ist
Bisher nutzten Entwickler bei Verbindungsproblemen mit internen Servern oder REST-APIs ohne gültiges TLS-Zertifikat häufig den einfachsten Weg im Application-Manifest (AndroidManifest.xml):
<!-- Bisheriger, potenziell unsicherer Ansatz -->
<application
android:allowBackup="true"
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:usesCleartextTraffic="true"
android:theme="@style/AppTheme">
<!-- App-Komponenten -->
</application>
Das Setzen von android:usesCleartextTraffic="true" hebt jedoch die gesamte System-Härtung auf Anwendungsebene auf. Sämtliche HTTP-Verbindungen, die von Drittanbieter-SDKs, Werbenetzwerken oder eingebetteten WebViews innerhalb des App-Prozesses initiiert werden, dürfen Daten im Klartext senden und empfangen. In öffentlichen WLAN-Netzen ermöglicht dies einfache Man-in-the-Middle-Angriffe (MitM), Session-Hijacking und das Abfangen von Authentifizierungs-Tokens.
Mit der Verschärfung ab API Level 36 wird das Attribut vom Android-Laufzeitsystem schrittweise ignoriert bzw. führt beim Einreichen von Builds im Google Play Console Verification Pipeline zu harten Ablehnungen, sofern nicht explizit granulare Sicherheitskonfigurationen vorliegen.
2. Die Lösung: Die Network Security Configuration für feingranulare Ausnahmen
Der Wegfall des globalen Attributs bedeutet nicht, dass Entwicklungs-Builds oder Verbindungen zu lokalen Testumgebungen unmöglich werden. Die saubere architektonische Lösung besteht in der Verwendung der Network Security Configuration. Diese erlaubt es, Ausnahmen strikt auf spezifische Domainnamen oder IP-Adressen einzuschränken, während der verbleibende Datenverkehr der Anwendung zu 100% über TLS erzwungen wird.
Schritt 1: Verlinkung im Manifest
Zunächst wird im Manifest auf eine dedizierte XML-Ressource verwiesen:
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="net.dbh.security.app">
<uses-permission android:name="android.permission.INTERNET" />
<application
android:allowBackup="false"
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:networkSecurityConfig="@xml/network_security_config"
android:theme="@style/Theme.AppCompat">
<activity android:name=".MainActivity" android:exported="true">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>
</manifest>
Schritt 2: Granulare Konfiguration in network_security_config.xml
Unter res/xml/network_security_config.xml definieren Sie im Anschluss genau die Umgebungen, die vom TLS-Zwang ausgenommen werden sollen (beispielsweise die lokale Entwickler-Instanz):
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
<!-- Standard-Einstellung für die gesamte Anwendung: Nur TLS gestattet -->
<base-config cleartextTrafficPermitted="false">
<trust-anchors>
<certificates src="system" />
</trust-anchors>
</base-config>
<!-- Explizite Ausnahme NUR für die lokale Staging-/Entwicklungsumgebung -->
<domain-config cleartextTrafficPermitted="true">
<domain includeSubdomains="true">staging.internal.dbh-systems.local</domain>
<domain includeSubdomains="false">10.0.2.2</domain> <!-- Android Emulator Localhost -->
</domain-config>
</network-security-config>
3. Sichere Einbindung eigener Zertifizierungsstellen (Self-Signed CAs)
In Unternehmenseinflussbereichen oder internen Rechenzentren scheitert die Umstellung auf HTTPS oft an fehlenden öffentlichen Zertifikaten (z. B. von Let’s Encrypt). Viele In-House-Dienste nutzen selbstsignierte Zertifikate oder Zertifikate einer internen Unternehmens-CA.
Standardmäßig vertrauen moderne Android-Versionen benutzerdefinierten Zertifikaten, die im Speicher des Geräts abgelegt wurden, für normale Apps nicht mehr. Damit soll verhindert werden, dass Benutzer durch Schadsoftware zur Installation gefälschter Root-Zertifikate verleitet werden.
Um ein internes Zertifikat sicher und ohne unverschlüsselten Klartext-Traffic in die Anwendung einzubinden, kann das Zertifikat direkt im APK-Paket mitgeliefert und ausschließlich für den Prozesskontext registriert werden:
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
<base-config cleartextTrafficPermitted="false">
<trust-anchors>
<!-- Vertrauen auf Standard-System-Zertifikate -->
<certificates src="system" />
</trust-anchors>
</base-config>
<!-- Einbindung der internen Unternehmens-CA für die Firmendomäne -->
<domain-config>
<domain includeSubdomains="true">internal.dbh-systems.net</domain>
<trust-anchors>
<!-- Verweis auf res/raw/dbh_internal_root_ca.crt -->
<certificates src="@raw/dbh_internal_root_ca" />
</trust-anchors>
</domain-config>
<!-- Für Debug-Builds zusätzlich Zertifikate aus dem Benutzerspeicher zulassen -->
<debug-overrides>
<trust-anchors>
<certificates src="user" />
</trust-anchors>
</debug-overrides>
</network-security-config>
4. Auswirkungen auf Unternehmens-MDMs und Network Monitoring
Für Systemadministratoren und SecOps-Teams bedeutet der erzwungene Übergang zu reinem TLS-Traffic Anpassungen im Bereich des Network Monitoring und der Deep Packet Inspection (DPI).
- Transparenz im Unternehmensnetzwerk: Unverschlüsselter App-Traffic konnte bisher von Intrusion Detection Systemen (IDS) relativ mühelos nach regulären Ausdrücken oder sensiblen Klartextdaten durchsucht werden. Durch den TLS-Zwang ist die Analyse der Nutzdaten auf Netzwerkebene ohne Man-in-the-Middle-Proxy nicht mehr möglich.
- Sicherheitsgewinn durch Certificate Pinning: In Kombination mit der Network Security Configuration lässt sich über das Element
<pin-set>auch direktes Certificate Pinning konfigurieren. Dadurch wird verhindert, dass kompromittierte CA-Zertifikate von Drittanbietern genutzt werden können, um den Traffic der Anwendung abzufangen. - Enterprise MDM (Android Enterprise): Mobile Device Management Systeme können über Zertifikatsprofile private CAs direkt auf den Geräten installieren. Durch die Konfiguration von
<debug-overrides>oder expliziten Enterprise-Vertrauensankern im Code bleibt die Verwaltbarkeit von Firmen-Apps auf verwalteten Geräten (Managed Devices) weiterhin vollständig gewährleistet.
Fazit: Konsequente Härtung der mobilen Anwendungsinfrastruktur
Das verabschiedete Ende von android:usesCleartextTraffic="true" ist eine längst überfällige Konsequenz zur Erhöhung des Sicherheitsstandards im Android-Ökosystem. Während Entwickler gezwungen werden, voreilige Ausnahmeregelungen im Manifest aufzugeben und durch saubere Network-Security-Configs zu ersetzen, profitieren Unternehmen von einer stark verringerten Angriffsfläche für Datenabfluss und Man-in-the-Middle-Attacken. Die Umstellung auf API Level 36+ erfordert eine fristgerechte Auditierung aller internen Netzwerk-Aufrufe, belohnt jedoch mit einer durchgängig verschlüsselten und konformen Softwarearchitektur.
🔥 Mein Krypto-Tipp für deinen Homescreen
Du willst deine Krypto-Kurse auf einen Blick auf deinem Homescreen haben – ohne lästige Werbung oder Datenkraken im Hintergrund? Lade dir jetzt meine App herunter!
🌐 Fundierte Quellenangaben und Verweise:
- Android Developers Guide: Network Security Configuration & Cleartext Traffic Policies | Entwickler-Dokumentation aufrufen
- Google Play Console Support: Target API level requirements for Google Play apps | Richtlinien-Eintrag ansehen
- Android Security Blog: Protecting Users With TLS by Default in Android | Sicherheits-Analysen durchsuchen
Tags: android security, usescleartexttraffic, network security config, tls encryption, api level 36, google play policies, app hardening, mobile enterprise, mdms, dbh it systems
