ATS wurde von Apple in den Versionen iOS 9.0 und OS X 10.11 eingeführt. Ist es aktiviert, müssen Anwendungen, die auf diesen Betriebssystemen laufen, eine sichere HTTPS-Verbindung nutzen anstatt Standard-HTTP.  Noch dieses Jahr werden die Restriktionen und Auswirkungen deutlich spürbarer, es hat nur leider bisher keiner darüber berichtet. 

Fast jede App tauscht Daten mit einer Art Backend-Server aus. Diese Daten können benutzerspezifisch und sensibel sein! Ein Benutzer muss sich möglicherweise mit Benutzername und Kennwort gegenüber dem Dienst authentifizieren.

Beispiele für einen unzureichenden Schutz des Datentransportes:

• Die Datenübertragung ist nicht verschlüsselt und kann von einem Angreifer zwischen Gerät und Server belauscht werden.
• Die Datenübertragung ist mit SSL / TLS geschützt, aber die Überprüfung des Serverzertifikats ist auf dem Gerät nicht möglich.

Aus diesem Grund wurde vor vielen Jahren SSL (Secure Sockets Layer) von Netscape Communications Corporation ins Leben gerufen. Dabei verfolgt SSL das Ziel: Schutz der Übertragung von Daten über das Internet (auf Ebene der Transportschicht).

Das SSL-Protokoll ist dabei anwendungsunabhängig.  Es wird häufig verwendet für FTP, IMAP, POP3, SMTP sowie HTTP.  Das als Transport Layer Security (TLS) bezeichnete Protokoll stellt dabei den Nachfolger von SSL dar. TLS 1.3 ist seit August 2018 verabschiedet und jetzt ein offizieller Standard (RFC 8446) der Internet Engineering Task Force (IETF). 

Während HTTPS im Desktop-Browser meist neben der URL angezeigt wird, wenn man sich in seinen E-Mail- oder Onlinebanking-Account etc. einloggt, sind mobile Apps weniger transparent bezüglich der Sicherheit ihrer Verbindungen. Daher ist es oft schwer zu sagen, ob sie HTTP oder HTTPS benutzen. Hier kommt ATS ins Spiel.

Apple stellt seit iOS 9 spezielle Anforderungen sowohl an die App Entwicklung als auch an die damit verbundenen Back-End-Systeme bei der Verwendung dieser SSL/TLS Protokolle. 

Zielsetzung von Apple dabei ist die Erhöhung

… der Sicherheit

… der (empfundenen) Performance

… der (wahrgenommen) Zuverlässigkeit

Kurz gesagt unterbindet ATS jegliche unverschlüsselte HTTP Verbindungen. Aber nicht nur das, auch gebrochene bzw. schwache HTTPS Verbindungen werden untersagt.

Allgemein erfolgt eine SSL/TLS Kommunikationsverbindung nach der Verhandlung für die zur Datenverbindung zu nutzenden Kombination aus vier Algorithmen (Cipher Suites):

• Schlüsselaustausch (z. B.: RSA, DH, PSK, SRP)
• Authentifizierung, (z.B. RSA, DSA) 
• Hashfunktion (z.B. MD5, SHA) 
• Verschlüsselung (z.B. RC4, DES, 3DES, IDEA, AES) 

Apple erlaubt bei ATS nur noch die nutzen von Chiper Suites aus der folgenden Liste:

• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_ AES_128_GCM_SHA256 
• TLS_ECDHE_ECDSA_WITH_ AES_256_CBC_SHA384 
• TS_ECDHE_ECDSA_WITH_ AES_256_CBC_SHA 
• TLS_ECDHE_ECDSA_WITH_ AES_128_CBC_SHA256 
• TLS_ECDHE_ECDSA_WITH_ AES_128_CBC_SHA 
• TLS_ECDHE_RSA_WITH_AES_256_ GCM_SHA384 
• TLS_ECDHE_RSA_WITH_AES_128_ GCM_SHA256 
• TLS_ECDHE_RSA_WITH_AES_256_ CBC_SHA384 
• TLS_ECDHE_RSA_WITH_AES_128_ CBC_SHA256 
• TLS_ECDHE_RSA_WITH_AES_128_ CBC_SHA 

Entwickler können Ausnahmen in einer Info.plist eines Projektes definieren für die komplette Kommunikation oder Domain-spezifisch. Jede Ausnahme muß jedoch Apple gegenüber begründet werden.

Apple drückt App Transport Security (ATS) zunehmend in den Markt - die Möglichkeit für Entwickler, dieses Sicherheits-Feature auszuschalten, wird immer weiter reglementiert. 

Wer bis heute dachte, dass hier lediglich Entwickler gefragt sind, liegt somit falsch. Mit iOS 12 wird das ganze jedoch noch härter in der Auswirkung.

ATS wird noch dieses Jahr auch für den Einsatz im MDM / Enterprise Umfeld benötigt. Dies hatte Apple bereits im letzten Jahr angekündigt und macht diese “Androhung” nun wahr. Beachten sie daher bei der Prüfung jeden bereitgestellten Dienst, wie z.B.

• Check-In 
• SCEP Server
• OTA Profile Auslieferung
• Enterprise App Verteilung

Auch hatte ATS bisher einige optionale Eigenschaften, die Entwickler häufig nicht genutzt haben. Das wird sich jetzt ändern.

Ein Beispiel ist die so genannte Certiciate Transperency.

Die originäre Aufgabe eines Zertifikate bei der Datenkommunikation ist es, sicherzustellen, dass mit dem richtigen Server kommuniziert wird (chain of trust). Certificate Transparency hat zur Aufgabe, Zertifikate, die von den Zertifizierungsstelle ausgestellt wurden, zu protokollieren, kontrollieren und zu überwachen.  Hierfür werden auf neutralen CT-Log Servern die Informationen zum Zertifikat vorgehalten. Der Eigentümer eines Zertifikates kann sich informieren, wenn es Änderungen oder neue Zertifikate zu seiner URL gibt (Auditierung und Monitoring ). Der iOS-Client war bisher in der Lage zu Prüfen (NSRequiresCertificateTransparency) ob es sich um ein Zertifikat handelt, das auf einem CT-Log-Server vorgehalten wird.

Diese Freiwilligkeit ändert sich. Zertifikate die ab 15. Oktober 2018 ausgestellt werden, müssen auf mindestens 2 CT-Log-Servern vorgehalten werden. Anderenfalls werden die Zertifikate als ungültig erklärt und eine Datenkommunikation ist nich mehr möglich.

Aber auch ein „gültiges“ Zertifikat reicht nicht aus, wenn dieses von der Symantec Certificate Authorities (CAs) stammt. Laut Supportdokument ( https://support.apple.com/en-us/HT208860 ) werden Zertifikate dieser CA zum 1. August 2018 teilweise mißtraut. 

Für Website-Betreiber, die Symantec TLS-Serverzertifikate verwenden, die zwischen dem 1. Juni 2016 und dem 1. Dezember 2017 ausgestellt wurden, werden diese Zertifikate weiterhin als vertrauenswürdig eingestuft, wenn das SCT-Datum (Signed Certificate Timestamp) des Zertifikats vor dem 1. Dezember 2017 liegt. Alle Zertifikate die diesen Vorgaben nicht entsprechen, werden (sind) seit 1. August nicht vertrauenswürdig für iOS.

Ab Herbst 2018, ein genaues Datum steht noch nicht fest, werden dabei sogar allen Zertifikaten der  Symantec-Zertifizierungsstellen  misstraut.

Websitebetreiber, die derartige TLS-Serverzertifikate verwenden, müssen auf ein Zertifikat umstellen, das von einer von Apple anerkannten CA.1 ausgestellt wurden.

Viele Webseiten, z.B. https://www.ssllabs.com bieten eine online Prüfung für öffentlich verfügbare Adressen an. Wer nicht auf einem (unbekannten) externen Dienstleister zur Einsicht in die Zertifikate und ATS Unterstützung vertrauen will, kann sich auch die App „ATS Diagnostic“ (https://itunes.apple.com/de/app/ats-diagnostic/id1297164068?mt=8) auf sein iOS Gerät laden.

Mit ATS Diagnostic bekommen Entwickler und Administratoren ein Werkzeug in die Hand, das die  Funktionsfähigkeit von ATS umfänglich anzeigt. Dabei ist es egal ob der betroffene Server (Endpunkt) frei im Internet verfügbar ist, oder nur im lokalen Netzwerk dem iOS-Endgerät zur Verfügung steht.

Dies erlaubt die Prüfung der Kommunikationsstrecke zwischen iOS-Gerät und Server (z.B. Dauer, Verbindungsart, usw.), das Prüfen der Serverkonfiguration (z.B. Encoding Einstellungen, usw.) aber auch die Prüfung der ATS-Konformität (z.B. Zertifikate, Schlüssellängen, Hash-Funktionen, usw.).