Auf der WWDC 2020 hat Apple zahlreiche Maßnahmen im Bereich Datenkommunikation rund um iOS 14, beziehungsweise iPadOS 14 angekündigt. Hier ein Überblick über die Aktivitäten in verschiedenen Bereichen wie Performance, Security oder Datenschutz.

iOS 14: Mehr Performance mit IPv6 und HTTP/3

Bei iPv6 handelt es sich um das aktuellste Internet-Protokoll, das seit Jahren im Apple-Ökosystem unterstützt wird. Das ist nicht verwunderlich, immerhin prüft Apple bei Einreichungen im AppStore auf IPv6-Kompatibilität. Allerdings ist IPv6 noch gar nicht so weit verbreitet, wie Apple im Rahmen einer WWDC-Session darlegte: 54 Prozent der TCP-Verbindungen finden noch immer in einer IPv4-only-Umgebung statt. Immerhin sind 26 Prozent der Verbindungen in einer reinen IPv6-Umgebungen aktiv. In den verbleibenden 20 Prozent unterstützt nur der adressierte Server kein IPv6 und daher nur IPv4-Verbindungen.

Damit iOS-Geräte in der App IPv6 nutzen können, reicht es für Entwickler, auf URLSession und Network.framework zuzugreifen. Im Serverumfeld muss der Server selbst eigenständig mit IPv6 zurechtkommen. Auch die Verbindung während der Kommunikation ist hier relevant. Die Netzbetreiber helfen ebenfalls seit Jahren bei der Transition zwischen IPv4 zu IPv6. So wird weltweit Support geboten für:

• DNS64: synthetisiert eine IPv6-Adresse für einen IPv4-only-Server

• NAT64: übernimmt die Übersetzung einer IPv6 zu einer IPv4-Adresse

Der Aufwand lohnt sich, da IPv6 unter anderem eine geringere Latenz und eine höhere Performance als IPv4 bietet. Apple zufolge ist mit IPv6 eine im Schnitt 1,4 Mal so hohe Geschwindigkeit im Vergleich zu IPv4 möglich.

Einen weiteren Schritt in Richtung mehr Performance stellt HTTP/2 dar. Diese Technik nutzt Multiplexing über eine einzelne Verbindung, um die Performance zu erhöhen. Dies bedeutet, dass ein Client nicht warten muss, bis ein Request abgeschlossen ist, damit der nächste gestartet werden kann. Mit anderen Worten: Mehrere Requests können parallel abgearbeitet werden. Da Verbindungen zum gleichen Server erkannt und bereits aufgebaute Verbindungen effizienter weiter genutzt werden, spart dies "Zeit" für einen stetigen Auf-/Abbau der Verbindung. Mithilfe der Header-Komprimierung werden sowohl im Request als auch im Response wertvolle Bytes gespart.

Laut Apple nutzen bereits 70 Prozent der Verbindungen in Safari HTTP/2-Verbindung. Und auch hier wurde ein spürbarer Performance-Erfolg gemessen: Die Verbindungen waren im Durchschnitt um den Faktor 1,8 performanter als einfaches HTTP. Für iOS-Geräte reicht es auch hier für Entwickler, auf URLSession und Network.framework zuzugreifen. Im Serverumfeld muss der Server selbst HTTP/2 aktiviert haben.

Apple bleibt aber bei HTTP/2 nicht stehen. Mit HTTP/3, das auf dem neuen Internet-Transportprotokoll QUIC (Quick UDP Internet Connections) basiert, steht die nächste Generation von HTTP in den Startlöchern. Dieses Transport-Protokoll hat die Sicherheit von TLS 1.3 integriert und bietet die gleiche Unterstützung für Multiplex-Streams wie HTTP/2. Im Gegensatz zu herkömmlichen TCP- und TLS-Verbindungen kann QUIC aber die Ladezeiten und das Puffern einer Website verkürzen, da weniger Kommunikation zwischen Client und Server benötigt wird. HTTP/3 bietet auch eine integrierte Mobilitätsunterstützung, so dass Netzwerkübergänge nicht dazu führen, dass laufende Operationen fehlschlagen. Stattdessen können diese nahtlos und ohne Unterbrechung mit einer neuen Netzwerkverbindung fortgesetzt werden.

Da sich HTTP/3 noch immer in der Spezifizierung bei der IETF befindet, können Anwender/Entwickler die Kompatibilität nur mithilfe der Entwicklereinstellungen aktivieren. Sie können die gleiche HTTP/3-Unterstützung auch in Safari über experimentelle Einstellungen ausprobieren.

iOS und iPadOS 2020: Mehr Sicherheit mit ATS

Fast jede App tauscht Daten mit einer Art Backend-Server aus. Diese Daten können benutzerspezifisch und sensibel sein, weswegen sich ein Anwender möglicherweise mit Benutzernamen und Kennwort gegenüber dem Dienst authentifizieren muss. Um die Sicherheit, die (empfundene) Performance und die (wahrgenommene) Zuverlässigkeit zu erhöhen, stellt Apple dazu bereits seit iOS 9 spezielle Anforderungen - sowohl an die App-Entwicklung als auch an die damit verbundenen Backend-Systeme. Mit dieser Vorgabe, auch als Application Transport Security (ATS) bezeichnet, unterbindet iOS / iPadOS unverschlüsselte HTTP-Verbindungen und unterbrochene, beziehungsweise schwache HTTPS-Verbindungen. Die Vorgaben betreffen aber auch weitere Bereiche bei der Datenkommunikation. So dürfen nur noch State-of-the-Art-Krypto-Algorithmen wie AES-128 und die Hash-Funktionen SHA-224, SHA-256, SHA-384 und SHA-512 verwendet werden.

Auch die Verlässlichkeit, dass mit dem richtigen Server abgesichert kommuniziert wird, adressiert Apple. Hier spielen SSL-Zertifikate eine entscheidende Rolle. Ihre originäre Aufgabe ist es sicherzustellen, dass ein Client mit dem richtigen Server kommuniziert. Hierzu erhält der Server ein Zertifikat von einer entsprechenden Registrierungsstelle (CA). Diese Zertifikate bestätigen dem Client nun kryptographisch die Richtigkeit der Serveradresse. Mit ATS forciert Apple zudem die Nutzung des Certificate-Transparency-Verfahrens. Dieses ursprünglich von Google ins Leben gerufene Verfahren erlaubt es, SSL-Zertifikate an einer neutralen Stelle zu protokollieren, zu kontrollieren und damit deren Korrektheit zu überwachen.

Ein weiteres Verfahren, um die Gültigkeit eines SSL-Zertifikates für die Datenkommunikation zu überprüfen, ist der Support für OSCP-Stapeling im Umgang mit OCSP-Responders (Online Certificate Status Protocol): Alle SSL-Zertifikate enthalten bereits eine URL, um sich selbst durch die Zertifizierungsstelle überprüfbar zu machen. Eine solche URL kann von einer App genutzt werden, um zu prüfen, ob das SSL-Zertifikat gültig ist oder zwischenzeitlich gesperrt wurde. Bei OCSP Stapeling muss dies nicht pro Element von der App abgefragt werden, sondern der Webserver selbst bezieht regelmäßig vom OCSP Responder eine OCSP-Antwort zu dem von ihm verwendeten SSL-Zertifikat. Diese Antwort verpackt der Server kryptographisch signiert eigenständig im TLS-Handshake mit dem Client.

Hier eine zusammenfassende Übersicht der von Apple eingeforderte Sicherheits-Features für eine sichere Datenkommunikation.

Einige ganz spezifische Ausnahmen gibt es jedoch weiterhin. Diese sind nicht als generelle Freigabe in einer PLIST-Datei zu pflegen, sondern stellen Exceptions innerhalb des App-Codes dar. So werden Exceptions für Entwickler geboten, wenn es um AVFoundation- und WKWebView-Zugriffe geht.

Auch wenn ATS noch nicht verbindlich TLS 1.3 Verbindungen einfordert, wird dies von iOS technisch unterstützt. TLS 1.3 erlaubt einen schnelleren Handshake und erhöht die Sicherheit in der Verbindung. Auch hier bietet Apple seit iOS 13.4 eine standardmäßige Nutzung. Gemäß Apple nutzten 51 Prozent aller Verbindungen zwar noch TLS 1.2, der Rest aber immerhin schon TLS 1.3. Und selbst wenn wir das Performance-Kapitel schon verlassen haben: TLS 1.3 wirkt sich auch positiv auf die Internetverbindung aus. So werden Kommunikationsverbindungen 1,3 Mal schneller aufgebaut als mit TLS 1.2. Für iOS-Geräte reicht es auch hier für Entwickler, auf URLSession und Network.framework zuzugreifen. Im Serverumfeld muss der Server selbst TLS 1.3 aktiviert haben. Wenn Sie in dieser Angelegenheit bereits Ihren Server konfigurieren, möchte ich Ihnen noch ein paar Konfigurationen empfehlen:

• Aktivieren Sie HTTPS-Only -> HTTP ohne TLS deaktivieren

• entfernen Sie alte Protokollversionen

• deaktivieren Sie schwache Chipher-Suiten

• aktivieren Sie Forward Secrecy

Es lohnt sich hier, immer auf Aktualität zu achten. Wer prüfen möchte, ob ein Server die Vorgaben von ATS erfüllt, kann dies extern wie intern mit Tools wie z.B. ATS Diagnostic untersuchen.

iOS-Geräte: Zwei Netzwerkverbindungen für mehr Stabiliät

Mithilfe von Multipath TCP bekommt eine App die Möglichkeit, über Netzwerk-Interfaces hinweg eine stabilere Verbindung zu erhalten. Damit muss eine App eine Verbindung nicht neu aufbauen, wenn die Netzwerkverbindungen wechseln. Für iOS-Geräte müssen die Entwickler dazu die multipathServiceType Property für die URLSessionConfiguration (für URLSession) und/oder für NWParameters (für Network.framework) aktivieren. Es werden hierzu zwei Modi für Apps angeboten, Voraussetzung ist jedoch, dass die Apps sparsam mit Daten umgehen.

• Handover Mode: Dieser Modus erlaubt es Apps, Verbindungen im laufenden Datentransfer über das Netzwerk-Interface hinweg zu wechseln (WLAN->Mobilfunk->WLAN->…). Er eignet sich daher für langlebige Verbindungen mit Bedarf an hoher Verfügbarkeit. Dieser Modus ist geeignet für Apps mit allen Arten von Verbindungen, die nicht "einfach mal so" neu aufgesetzt werden können. Für das Herunterladen großer Dateien (im Hintergrund) ist dieser Modus nicht vorgesehen.

• Interactive Mode: In diesem Modus werden die Verbindungen über die gebotenen Netzwerk-Interfaces parallel geöffnet und eignen sich somit für kurzlebigen Datenverbindungen mit dem Bedarf nach geringster Latenz. Bricht eine Verbindung weg, besteht die parallel dazu aufgebaute Verbindung weiterhin. Sind WiFi- und GSM/LTE-Verbindungen verfügbar, priorisiert dieser Modus immer die WiFi-Verbindung für die Datenübertragung. Dieser Modus ist geeignet für Apps mit hohen Anforderungen an die Latenz. Systemintern setzt iOS bereits seit Version 7 auf diesen Modus. Auch dieser Modus ist nicht geeignet für (Background-) Downloads jeglicher Art.

Allerdings haben Entwickler zusätzlich Zugriff auf den Aggregation Mode, der eine Bündelung von Zugangsbandbreiten ermöglicht. Damit können beispielsweise Mobilfunk mit 1 Mbit/s Bandbreite und DSL mit 6 Mbit/s zu einem Internet-Zugang mit 7 Mbit/s Durchsatz kombiniert werden. Der Modus ist nur auf Entwicklergeräten verfügbar und lässt sich nicht auf Endkundengeräte übertragen. Apple hat die App-Entwickler aufgerufen, Use-Case-Szenarien für diesen Modus zu identifizieren. Im Server-Umfeld ist dies etwas aufwändiger umzusetzen. Anleitungen und Hilfestellungen finden Sie hier.

Im Zusammenhang mit dem Begriff Reliable Network Fallback ("WLAN-Unterstützung") wurde früher der WiFi Assistent in iOS genannt, der ein ähnlich klingendes Problem lösen sollte. Ursprünglich wurde diese Funktion implementiert, um beim Verbindungsaufbau einer App zu unterstützen. Befand sich der Anwender zum Zeitpunkt des Kommunikationsaufbaus in einem Bereich, der keine ausreichende WLAN-Versorgung sicherstellte, wurde die Verbindung über Mobilfunk aufgebaut. Leider war diese Funktion nur zu diesem Zeitpunkt aktiv. Die Verbindung (NSURlSession) mit der schnellsten Antwort hatte hier gewonnen (Flow Creation Time). Die Verbindung zum WiFi-Netzwerk blieb aber auch bei der Kommunikation via Mobilfunk weiterhin bestehen, falls die WLAN-Verbindung für spätere Anfragen effizienter antwortete. Eine Unterstützung während des Datenverkehrs war nicht enthalten. Brach die Verbindung zum WiFi-Netzwerk komplett ab, musste iOS erst aufwändig nach einem neuen Netzwerk per WLAN-Scan suchen.

Bereits mit iOS 13 wurde die WLAN-Unterstützung wie folgt erneuert: Bereitet eine bereits aufgebaute Verbindung Probleme, kann diese vom System neu aufgebaut werden (Improved Flow Recovery). Diese Funktionalität steht zentral seit iOS 13 den High-Level APIs (URLSession, Network.framework) zur Verfügung. Entwickler werden aber von Apple aufgefordert, keine eigenständige Prüfung der Netzwerkqualität - zum Beispiel mit SCNetworkReachability - durchzuführen. Das System "lernt" die WiFi-Verfügbarkeit nun nämlich automatisch. Falls eine App mit Massendaten arbeitet, sollten Entwickler dies dem System mithilfe von allowExpensiveNetworkAccess = false mitteilen. Dies verhindert, dass die Massendaten (bei Verbindungswegfall) via Mobilfunk übertragen werden.

Bereits mit iOS 13 führte Apple außerdem den "Low Data Mode" ein. Dieser bietet dem Anwender die Möglichkeit, dem System mitzuteilen, dass dieses sehr sparsam mit den zu übertragenen Daten umgehen soll. Der Modus ist für WLAN wie auch Mobilfunk definierbar. Gerade in Situationen, in denen ein schwaches WLAN-Signal oder eine (fast) gedrosselte Handy-Flat den Datenverkehr ausbremst, soll diese Funktion helfen. Aktiviert der Anwender dieses Feature, reduziert iOS seine eigenen Netzwerkzugriffe auf das Nötigste und alle Hintergrundaktivitäten von Drittanbieter-Apps werden deaktiviert. Das Ganze funktioniert aber nur, wenn die Entwickler ihre Apps entsprechend angepasst haben.

iOS 14: Mehr Datenschutz und Privatsphäre

Mit iOS/iPadOS 14 halten aber auch datenschutzrelevante Themen Einzug in die Datenkommunikation. So muss der Anwender zum Beispiel den Zugriff im lokalen Netzwerk durch Apps, die hier nach Hardware Ausschau halten (multicast, broadcast, ...), extra freigeben. Ein "Fingerprinting" des Anwenders soll so vermieden oder zumindest erschwert werden.

Ebenso adressiert Apple das Thema Schutz der Privatsphäre gegenüber einem Domain Name System (DNS). Der Hintergrund: Wenn Ihre App auf eine Website zugreift, startet das System eine DNS-Abfrage, um die URL (www.apple.com) einer Webseite in eine Reihe von Adressen (23.15.137.53 oder auch 2600:1406:5800:0592:1A) zu verwandeln. Die DNS-Kommunikation erfolgt dabei in der Regel über einen unverschlüsselten Transport (UDP). Das bedeutet, dass andere Geräte im Netzwerk sehen könnten, welche Adressen der Anwender interessieren. DNS-Anfragen geben einen Schatz an Metadaten preis, aus denen zum Beispiel DNS-Resolver-Betreiber Einiges über das Verhalten eines Nutzers auslesen können. Dazu gehört etwa, welche Seiten er im Internet besucht, welche Mail-Server er verwendet und von wem er gerade den Schlüssel für die nachfolgende verschlüsselte Kommunikation bezieht.

Dieser Punkt ist auch für Firmen mit eigenem VPN wichtig. Denn im Regelfall ist das Domain Name System der Schuldige, auch wenn es um Datenlecks bei VPN-Verbindungen geht: Um durch das Internet navigieren zu können, nutzt Ihr Rechner normalerweise automatisch die DNS-Server Ihres Internetanbieters. Geschieht das auch bei der Nutzung eines VPN-Tunnels, könnten Kriminelle genau diese Daten abgreifen. Deshalb leiten die meisten VPN-Provider den Traffic ihrer Kunden auch über DNS-Server um, die nicht in Zusammenhang mit deren Internetanbietern stehen.

Um bei diesem Problem Abhilfe zu schaffen, bietet Apple den App-Entwicklern mithilfe eines systemweiten verschlüsselten DNS-Zugriffs diese zwei möglichen Verfahren an

• DNS über TLS (DoT)

• DNS über HTTPS (DoH)

Beide Verfahren verwenden TLS zur Verschlüsselung von DNS-Nachrichten. DoH verwendet zusätzlich HTTPS, um die Performance in der Datenkommunikation zu verbessern.

Es gibt zwei Möglichkeiten, eine verschlüsselte-DNS Anbindung zu aktivieren. Die erste Möglichkeit besteht darin, einen einzigen DNS-Server als Standard-Resolver für alle Anwendungen auf dem System zu konfigurieren. Hierfür bedarf es zur Anbindung einer App mit einer so genannten NetworkExtension (NEDNSSettingsManager). Auch die Verwendung eines Mobile-Device-Management-Systems kann helfen, eine systemweite Nutzung zu konfigurieren.

Das Verwenden eines verschlüsselten DNS für nur eine App zu einem dedizierten Server ist eine weitere Option für App-Entwickler. So ist es möglich, dass eine App von sich aus verschlüsseltes DNS verwendet, auch wenn der Rest des Systems noch unverschlüsseltes DNS verwendet. Aber aufgepasst: Selbst wenn Sie Encrypted DNS aktiviert haben, um die Namensauflösung privater zu gestalten, enthält jeder TLS-Handshake, den Sie mit einem Server durchführen, eine Klartextanzeige des Servernamens oder SNI, die von einer dritten Partei im Netzwerk beobachtet werden kann.

Apple arbeitet derzeit mit der IETF an der Standardisierung von Methoden zur weiteren Verschlüsselung des TLS-Handshakes, so dass Dritte auch diesen Datenverkehr nicht ausspionieren können. Dies wird zukünftig ein wichtiger zusätzlicher Schritt sein, um zu ermöglichen, dass die Netzwerkkommunikation zwischen einer App und dem zugehörigen Server abgesichert ist, insbesondere in Kombination mit verschlüsseltem DNS. (mb/fm)