Die ab iOS9 automatisch aktive App Transport Security (ATS) erzwingt sichere Netzwerkverbindungen. Das bedeutet das bspw. Verbindungen per NSURLSession oder NSURLConnection nicht per HTTP sondern nur per HTTPS erlaubt werden. Darüber hinaus werden zeitgemäße Sicherheitsstandards durchgesetzt. Doch das System kann und muss öfter konfiguriert werden. Als Entwickler hast Du nämlich auf Deine Gegenstelle nicht immer Einfluss. Dieser Artikel zeigt wie es geht.

Anforderungen von App Transport Security

Per Default ist die Transport Security aktiviert und setzt die definierten Standards durch. Dazu gehört unter anderem TLS ab Version 1.2 aufwärts, da vorherige Versionen nicht mehr als sicher eingestuft werden. Auch für SSL Zertifikate gelten härtere Rahmenbedingungen. Sie müssen von einem vertrauenswürdigen Aussteller (CA) stammen. Das bedeutet auch, dass selbstsignierte Zertifikate nicht ausreichen. Auch der ausgehandelte Verschlüsselungsalgorithmus unterliegt einigen Restriktionen. Im wesentlichen darf das Zielsystem keine alten Technologien anbieten, da sie nicht mehr als sicher gelten. Details dazu bietet die offizielle Dokumentation von Apple.

Eine typische Fehlermeldung

Es gibt verschiedene Meldung. Eine der häufigten Stolperfallen ist aber die Verwendung von HTTP-Verbindungen, gerade wenn App Transport Security noch gar kein Begriff ist. Zunächst äußert sich das wie folgt:

App Transport Security has blocked a cleartext HTTP (http://) resource load since it is insecure. Temporary exceptions can be configured via your app’s Info.plist file.

Hier wird schon in der Meldung vermeintlich alles wichtige gesagt. Die HTTP Verbindung wurde nicht erlaubt, da es unsicher ist. Nun lässt sich argumentieren, ob zum Beispiel der Abruf von Bildern unbedingt verschlüsselt passieren muss. Nicht jedes CDN (Content Delivery Network) bietet das an. Das führt auch schon zur zweiten Aussage in der Meldung. In der Info.plist Datei können Ausnahmen definiert werden!

Die Info.plist

Die Info.plist Datei ist in jedem Xcode Projekt zu finden. Es ist eine Konfigurationsdatei, genau genommen ein XML-Dokument. Es können verschiedenste Einstellungen hinterlegt werden. Auch eigene Werte können hinterlegt werden. Und eben die Konfiguration der Transport Security. Wenn Du die Datei links über die Projekt Navigation öffnest, wird die XML-Struktur in einem speziellen Editor dargestellt:

info.plist

Die einzelnen Werte können einen unterschiedlichen Typ haben. String- und Boolean-Werte werden direkt einem Schlüssel zugeordnet. Wenn weitere Daten verschachtelt werden oder mehrere kombiniert werden, gibt es auch Dictionaries und Arrays. Die Bedingung ist selbsterklärend. Darum gehe ich da nicht näher drauf ein.

Neben dem Editor kannst Du auch direkt auf den XML Quellcode zugreifen. Die direkte Bearbeitung ist gerade bei umfangreicheren Werten praktisch, da Du nicht gefühlte hundert Mal irgendwo mit der Maus klicken musst. Das widerstrebt mir als Entwickler grundsätzlich.  Unter anderem die ATS Konfiguration definiere ich daher grundsätzlich im XML-Format, da sie auf mehreren Ebenen verschachtelt ist. Dazu rechts auf die Info.plist klicken und per “Open as” die “Source Code” Variante öffnen:

info.plist-sourcecode

Wenn alles geklappt hat, öffnet sich ein XML Dokument. Der Hauptknoten sollte (nach dem DOCTYPE) plist heißen. Darin verschachtelt ist ein weiterer Knoten dict, der die eigentlichen Einträge bereithält:

info.plist-sourcecode-xml

Das war der erste Schritt. Hier kannst Du nun – im besten Fall ganz unten – die Konfiguration hinterlegen und die Application Transport Security beeinflussen. Aber, was kann überhaupt eingestellt werden?

App Transport Security im Videotraining

Lern die App Transport Security im praktischen Einsatz kennen, beim Datenabruf von JSON APIs.

Hier geht es zum Videotraining

Die mögliche Konfiguration

Im einfachsten Fall kannst Du einfach die Kontrolle global deaktivieren. Dann wird keine Verbindung mehr geprüft. Wenn ohnehin nur mit HTTP gearbeitet wird, kein Problem. Du kannst auch die Prüfung allgemein deaktivieren, sie aber für einzelne Hostnamen wieder aktivieren. Ich nutze lieber eine dritte Variante. Du kannst ATS aktiv lassen und nur  einzelne Hostnamen von der Prüfung ausschließen. Damit hast Du die meiste Kontrolle. Das folgende Beispiel zeigt wie es geht.

Im Info.plist Editor (als Property List, die Standardansicht) sieht die Konfiguration für den Host openthesaurus.de wie folgt aus. Die Transport Security wird deaktivieren. Dieser Schnippsel ist Teil des Videotrainings Datenabruf von JSON APIs:

Screen Shot 2016-01-05 at 11.25.36

Die Settings bzw. Schlüssel im Detail:

  • App Transport Security Settings: NSAppTransportSecurity
    Der Hauptknoten der ATS Konfiguration
  • Exception Domains: NSExceptionDomains
    In dieser Datenstruktur können alle Domains hinterlegt werden. Schlüssel ist der jeweilige Domainname
  • openthesaurus.de: Host für den die Ausnahme gilt
    Hier wird die Domain hinterlegt
  • NSIncludesSubdomains
    Sollen auch alle Subdomains wie www.openthesaurus.de erlaubt sein?
  • NSTemporaryExceptionAllowsInsecureHTTPSLoads
    Darüber werden unsichere Aufrufe ermöglicht
  • NSTemporaryExceptionMinimumTLSVersion
    Hier wird die minimale TLS Version auf 1.1 herabgesetzt (Standard ist min. 1.2)

Ich finde es wie gesagt sehr unpraktisch alles über die Property List (den normalen Editor für die Info.plist) zu hinterlegen. Stattdessen kommen wir jetzt auf die XML Ansicht zurück.

ATS Ausnahmen per XML festlegen

Die oben gezeigte Konfiguration wird durch folgenden XML Code hinterlegt:

Der Code muss nur auf der richtigen Ebene hinterlegt werden. Er wird im äußeren dict-Tag verschachtelt. Im einfachsten Fall einfach ganz am Ende, dann steht nämlich wie im Screenshot oben auch die Konfiguration ganz am Ende. Dein XML Dokument sollte am Ende daher wie folgt aussehen:

Screen Shot 2016-01-05 at 11.44.10

Nun kannst Du von openthesaurus.de Daten auch mit unsicheren Verbindungen abrufen.

App Transport Security ganz deaktivieren

Manchmal kann es auch praktisch sein, wenn die App Transport Security gar nicht mehr aktiv ist. Wie gesagt, Nutzung auf eigene Gefahr. So fällt nämlich auch nicht auf, wenn trotz HTTPS eine unsichere Verbindung hergestellt wird. Wenn Du aber bspw. ohnehin nur Bilder abrufst, sicher ein valides Mittel. Ohne große Erklärung, hier ein Snippet für Deine Info.plist:

 

Foto: Secure Computing Cloud by FutUndBeidl, used under CC BY / Original used as background

Kommentare (2)

  • E..

    1 Jahr ago

    Danke dir Jan für die tolle Erklärung!

    • Jan Brinkmann

      1 Jahr ago

      Herzlich gern. Vielen Dank für Deinen Kommentar 🙂

Schreib einen Kommentar

Your email address will not be published.