Über die Cloud können Anwender selbst mit verschiedenen Geräte auf ihre Daten zuzugreifen, da diese stets synchronisiert vorliegen. Auf allen mobilen Plattformen attestieren Forscher der Technischen Universität Darmstatt und des Fraunhofer SIT jedoch eine unsichere Implementierung der Kommunikationsverbindungen und Autorisierungen von Apps in diese Cloud Systeme. In einer Studie untersuchten sie 750.000 Android- und iOS-Apps untersucht und prüften die Anbindung an verschiedene Cloud-Dienste wie Amazon, Apple, Facebook und Google. Dabei zeigte sich, dass viele Entwickler die Sicherheitsempfehlungen für eine abgesicherte Kommunikation ignorieren.

iOS 9 IST streng bei der Kommunikation

Mit App Transport Security (ATS) fördert Apple seit iOS 9 eine Verbesserung dieser Situation. ATS unterbindet standardmäßig die komplette Kommunikation über das unverschlüsselte HTTP-Protokoll. Mit der Einführung von ATS hat Apple die Möglichkeit geschaffen, die Art und Weise der Absicherung einer Kommunikationsverbindung mit Mindestanforderungen vorzuschreiben. Seit iOS 9 setzt Apple damit für die Kommunikationen eine TLSv1.2-Verbindung mit Forward Secrecy voraus. Forward Secrecy hat eine Besonderheit - wird das Zertifikat des Servers kompromittiert, kann der Angreifer zumindest die vergangene, zurückliegende Kommunikation nicht mehr "lesbar" machen. Auch die Mindestlänge des dabei zu nutzenden Schlüssels wird vorgegeben.

Gerade im mobilen Umfeld haben viele Anwender nur ein eingeschränktes Datenkontingent. Hier müssen Entwickler stellenweise umdenken, denn TLS kostet Datenvolumen. Die genutzten Zertifikate werden bei den meisten Kommunikationsanfragen mit übertragen. Viele Apps arbeiten heute jedoch noch nach dem klassischen HTTP 1.0 Prinzip: "TCP-Socket öffnen", "Request", "TCP-Socket schließen" und dann wieder von vorne. Für jede Iteration werden die Zertifikate entsprechend mit verwendet. Dies kostet sowohl Performance als auch Datenvolumen.

iOS 10 WIRD strenger

Entwickler sind mit iOS 9 jedoch in der Lage, über eine entsprechende Deklarierung ihrer Verbindung auch ohne ATS zu erlauben. Wie zu erwarten war, hat Apple dies mit iOS 10 geändert. Bis Ende 2016 ist ATS verpflichtend.

Jede HTTP Verbindung wird damit auf HTTPS angehoben werden, um die Vertraulichkeit der Kommunikation aber auch die Integrität der Daten (die Unveränderbarkeit und Verlässlichkeit des Inhaltes) sicherzustellen. Aber nicht alle SSL-Verbindungen bieten die gleiche Sicherheit.

So ist TLS 1.2 die einzige am Markt bekannte Möglichkeit, die allen bekannten Angriffen standhält. AES-128 und SHA-2 sind ebenso die einzigen Krypto-Algorithmen mit einer State-of-the-Art-Sicherheit. SHA-2 ist dabei der Oberbegriff für die vier kryptologischen Hashfunktionen SHA-224, SHA-256, SHA-384 und SHA-512, die 2001 vom US-amerikanischen NIST als Nachfolger von SHA-1 standardisiert wurden. RC4, SSLv3, SHA-1, und 3DES Algorithmen werden nicht mehr unterstützt.

Es gibt nur noch sehr geringe Ausnahmen. Hierfür werden Exceptions für Entwickler geboten, wenn es um AVFoundation- und WKWebView-Zugriffe geht.

Starkes TLS reicht nicht aus

Apple geht mit iOS 10 aber noch einen Schritt weiter, denn die Verlässlichkeit der Kommunikation hängt auch an den verwendeten Zertifikaten und deren Quellen.

Die originäre Aufgabe der Zertifikate ist es sicherzustellen, dass mit dem richtigen Server kommuniziert wird. Hierzu erhält der Server dieses Zertifikat von einer entsprechenden Registrierungsstelle (CA). Diese Zertifikate bestätigen dem Client nun kryptographisch die Richtigkeit der Serveradresse.

Mögliche Angriffsszenarien bestehen in dem Brechen der SSL-Verbindung und dem Verwenden eines Man-in-the-Middle-SSL-Attacke. Auch das Kompromittieren der Registrierungsstelle ist möglich, um einen eigenen Server aufzusetzen und dessen Legitimität vorzutäuschen.

Apple unterstützt hierfür das von Google ins Leben gerufene Certificate Transparency Verfahren. Dieses Verfahren soll Zertifikate, die von den Registrierungsstellen ausgestellt wurden, protokollieren, kontrollieren und überwachen. Die Idee dahinter ist, dass diese Registrierungsstellen keine-Public Key-Zertifikate ausstellen sollen, ohne den Eigentümer der Domain darüber zu informieren. Irrtümlich oder bösartiger Weise ausgestellte Zertifikate lassen sich so einfacher erkennen.

Certificate Transparency ist dabei auch in der Lage, alle ausgestellten Zertifikate nicht nur in einer, sondern auch in mehreren redundanten Datenbanken auf Log-Servern zugänglich zu machen.

Der Client ist nun in der Lage zu überprüfen, ob es sich um ein Zertifikat handelt, das auf einem Log-Server vorgehalten wird. Es werden mindestens zwei Log-Server benötigt. Dabei bleibt es der App selbst überlassen (NSRequiresCertificateTransparency: YES), wie sie sich verhält, sollte sich eine Registrierungsstelle dazu entschieden haben, die ausgestellten Zertifikate nicht auf Log-Servern zu veröffentlichen.

Diese Prüfung ist aktuell optional möglich (https://developer.apple.com/videos/play/wwdc2016/706/ nur Safari). Es wird nicht verpflichtend von Apple vorgeschrieben.

OCSP-Stapeling

Zertifikate für Webserver enthalten die URL eines OCSP-Responders (Online Certificate Status Protocol), der von der Zertifizierungsstelle betrieben wird. Diese URL kann von einer App genutzt werden, um zu prüfen (OCSP-Antwort), ob das Zertifikat zwischenzeitlich gesperrt ist. Hierzu muß bei jedem Request auch eine weitere Anfrage an den OCSP-Responder gestellt werden. Ein Nachteil dieses Verfahrens ist die erhöhte Latenz durch diese zusätzlichen Verbindungen auf Client-Seite (https://blog.pki.dfn.de/2015/03/mehr-privacy-fuer-den-nutzer-ocsp-stapling/).

Zur Lösung dieses Problems gibt es das OCSP-Stapling-Verfahren (http://tools.ietf.org/html/rfc6066 ) Bei diesem Verfahren bezieht nicht der Client, sondern der Webserver selbst regelmäßig vom OCSP-Responder eine OCSP-Antwort über sein eigenes Zertifikat, und schickt diese direkt im initialen TLS-Handshake kryptographisch signiert der App bei der Kommunikation. Damit muss der Server selbst und nicht der Client die zusätzlichen Kommunikationsverbindungen und die daraus resultierende Latenz eingehen. Mit iOS 10 unterstützt Apple dieses Verfahren in TLS (https://developer.apple.com/videos/play/wwdc2016/706/ nur Safari).

Empfehlung für Unternehmen

Es empfiehlt sich für Unternehmen, bereits heute ihre Infrastruktur dahingehend zu überprüfen, ob die verschlüsselte Übertragung bereits überall mit den entsprechenden Algorithmen eingesetzt wird. Inwieweit der eigene Server eine ausreichende Unterstützung bietet, kann über die URL https://www.ssllabs.com/ssltest/analyze.html geprüft werden.

Der Erwerb eines SSL-Zertifikats und die Umstellung des Webservers können so frühzeitig und ohne Zeitdruck vollzogen werden. Lesen Sie den zweiten Teil dieses Beitrags hier! (mb)