Bequem statt sicher: Google verleitet iOS-Entwickler
Google steht momentan in der Kritik. Im Ads Developer Blog, dem von Google betreuten Nachrichtenbereich für App-Entwickler, die Googles Werbebanner in mobile Applikationen einbinden, präsentiert der Suchmaschinen-Anbieter aktuell eine Anleitung, die für hochgezogene Augenbrauen sorgt.
So erklärt Googles Tristan Emrich hier, wie sich Apples „App Transport Security“ umgehen lässt. Die Neuerung, die Cupertino mit dem Akronym ATS abkürzt, beschreibt eine Architektur-Umstellung in iOS 9, die dafür sorgen soll, dass Anwendungen von Drittanbietern grundsätzlich auf verschlüsselte HTTPS-Verbindungen setzen.
Statt die Sicherheitsvorkehrungen Apples mit entsprechenden Anleitungen zu stärken beschreibt Google nun, wie sich der von iOS 9 implementierte ATS-Zwang umgehen lässt:
While Google remains committed to industry-wide adoption of HTTPS, there isn’t always full compliance on third party ad networks and custom creative code served via our systems. To ensure ads continue to serve on iOS9 devices for developers transitioning to HTTPS, the recommended short term fix is to add an exception that allows HTTP requests to succeed and non-secure content to load successfully.
Zwar hat Emrich seinen Eintrag inzwischen um einen Zusatz ergänzt und verweist nun auch auf Apples offizielle ATS-Dokumentation. Der Trick zur Umgehung bleibt aber weiterhin Online. Danke Oli.
Der Trick ist doch schon seit der ersten Beta jedem Entwickler Bekannt. Ich finde nicht das es was mit Bequemlichkeit zutun hat. In manchen fällen macht https kein sinn.
Sehe ich auch so, wüsste auch nicht warum man deswegen Google kritisieren sollte.
… weil Google bekanntlich zur Achse des Bösen gehört :)
Es gibt keinen Fall, in dem HTTPS nicht sinnvoll wäre.
Ich wüsste nicht was mehrausgaben (zeit oder geld) für nen verschlüsselten weg für werbung rechtfertigen würde und darauf bezieht sich google auch.
+1
Naja, ganz so kritisch würde ich das nicht sehen. Es gibt schon Anwendungsfälle bei denen die Verwendung von HTTPS schlicht überflüssig ist (wenn z.B. keine geschützten Daten übertragen werden). Ob der Abruf von Werbung in diese Kategorie fällt soll jeder selbst beurteilen. Um aber z.B. die Uhrzeit von einem Server abzufragen muss ja keiner gezwungen werden für den Server ein SSL Zertifikat zu unterhalten. Generell würde ich eine Umgehung also nicht prinzipiell als unsinnig und gefährlich beschreiben.
Problematisch ist auch, dass eine HTTPS Verbindung aus der App heraus bereits genügt, damit die App den „Tatbestand“ erfüllt eine Verschlüsselungstechniken zu nutzen. Kein Drama, aber damit müssen die Entwickler bei US Behörden eine Exportgenehmigung beantragen, damit die App überhaupt verkauft und „exportiert“ werden darf. Die Genehmigung ist wohl kein Problem, aber unnützer Aufwand ist es in jedem Fall.
In der realen Welt wird Werbung auch meistens ohne Umschlag verschickt.
Grundsätzlich eröffnet die unverschlüsselte Übertragung Angreifern (z.B. in einem öffentlichen WLAN) die Möglichkeit die übertragenen Daten nicht nur mitzulesen, sondern auch unbemerkt zu verändern. Das gilt für Werbebanner genauso wie für deine Uhrzeit. Im besten Fall zeigt deine App dann nur die falsche Uhrzeit an. Im ungünstigsten Fall enthält die App in der Uhrzeitfunktion eine Sicherheitslücke und der Angreifer hackt dir damit dein Handy.
Also, lange Rede, kurzer Sinn: Verschlüsselung ist IMMER sinnvoll. IMMER. Und das sogar ganz besonders bei Geräten, deren normales Nutzungsprofil auch öffentliche Netze beinhaltet.
Wer den Trick ohnehin nicht anwenden wollte, wird ihn auch weiterhin nicht anwenden. Wer ihn sowieso nutzen wollte, hätte ihn über eine Suchmaschine sowieso gefunden und genutzt.
Ergebnis: die Veröffentlichung hier hat keine Auswirkungen.
Verdammt – jetzt ist der Kommentar, auf den ich geantwortet habe, einfach weg.
Entwickler finden diesen Workaround aber schon sehr lang im Dev.Center. Nicht jeder „kleine“ Entwickler braucht ein Backend mit https. Da dies ja auch kein Ausnutzen einer Schwachstelle/Sicherheitslücke ist, sollte dies erstmal egal sein. Möglich ist allerdings, dass Apple diesen Weg mal sperren wird. Derzeit ist es aber „legal“ und wie gesagt auch im Develeoper Center seit der ersten Beta von iOS 9 bekannt und diskutiert.
Auch schön das die ersten 3 Buchstaben NSA sind :’D ich würde google hier nicht kritisieren, wie sie schon gesagt haben, viele Werbedienstleister nutzen kein HTTPS, wozu auch? Die Daten die für die Werbung übermittelt werden sind so zahlreich und im großen und ganzen uninteressant, das hier keine verschlüsselung notwendig ist.
Doch. Signierte SSL Zertifikate sind kostspielig.
StartSSL: 0 €
Hatte ich ne zeitlang und durfte jedes mal die gültigkeit des zertifikates prüfen. Privat für den eigenen server/nas noch in ordnung, aber für was offizielles ist das eher contra produktiv. Zumindest würde mir das kein wirklich sicheres gefühl geben bei google erst mal „ja, ich vertraue dem zertifikat“ anklicken zu müssen.
Dann hast du bei der Einrichtung das Zwischenzertifikat vergessen oder sowas.
StartSSL ist auf allen auch nur halbwegs aktuellen Clients (Windows, Linux, OS X, iOS, Android, Java) im Zertifikatsspeicher und sollte daher ohne Warnmeldung funktionieren.
Ich schließe mich an. Der Schritt von Apple, unverschlüsseltes HTTP zu verbieten und nur über einen Info.plist Schlüssel wieder freizuschalten ist total überzogen.
Man denke nur an UPnP/DLNA und ähnliche auf HTTP basierende Protokolle. Wie sollen die Millionen Audioanlagen, Fernseher, Router und was es da noch an embedded Geräten gibt mit einem ordentlichen SSL Zertifikat ausgestattet werden? Das ist total unrealistisch.
Und selbst bei HTTPS gibt es auch akzeptierbar sichere Wege, zum Beispiel mit selbst signierten (also „schlechten“) Zertifikaten umzugehen (Pinning). Nicht alles ist per se schlecht, was sich auf den ersten Blick nicht auf dem Standardpfad bewegt. Kann, muss aber nicht und hat dabei eventuell sehr gute Gründe.
Insofern finde ich auch die hier latent zu findende Verteufelung der Abschaltung von ATS („bequem statt sicher“) knapp an der Boulevardpresse vorbei geschrammt.
Es gibt sehr gute Gründe, ATS abzuschalten. Und aus dem Abschalten von ATS einfach nur auf „unsicher“ zu schließen, ist technisch kurzsichtig.
Ich gehe mit, dass die Anbieter von Werbung durchaus in der Lage sein sollten, vernünftige Zertifikate auf ihren Servern zu installieren und zu warten. Aber wehret den Anfängen! Wenn wieder mal eine App ATS abschaltet, dann schaut genau hin, warum sie das tut und urteilt erst nach genauer Analyse!
Nein! Das hat nichts mit Boulevardpresse zu tun. Es handelt sich hier eben nicht um eine Verbindung zu einem Stück Unterhaltungselektronik im eigenen Haus, sondern allgemein um Werbung in einer App, bei der Google grundsätzlich erstmal davon ausgehen muss, daß sie auch außerhalb gesicherter Netze verwendet wird. Und dort zu empfehlen die Verschlüsselung pauschal zu deaktivieren ist einfach nur fahrlässig. Und sowas gehört öffentlich an den Pranger gestellt.
Jawoll. Du hast recht. In diesem konkreten Fall der Werbeserver sollte das mit den ordentlichen Zertifikaten lösbar sein und ATS eingeschaltet bleiben können.
Mich stört der allgemein uneingeschränkt negative Ton zur Abschaltung von ATS in diesem Artikel hier. Da fehlt die Reflektion auf die Szenarien, in denen das Abschalten von ATS eben nicht an den Pranger gehört sondern die einzig vernünftige Lösung ist.
Beispielhafte Details habe ich oben schon erläutert.
ATS ist ein Feature,welches alle Entwickler in Betracht ziehen sollten. Auch wenn es nur Werbung ist die geladen werden soll, schadet es nicht dies über HTTPS zu tun. Die Anleitung von Herrn Emrich ist auch nichts neues, Apple hat bei der Vorstellung des iOS9 Features erwähnt, dass sich einzelne Verbindungen trotzdem über HTTP aufbauen lassen. Allerdings ist es kontraproduktiv das ATS-Feature,wie oben in der PLIST zu sehen vollständig zu deaktivieren. Klar kann der Entwickler beim Aufbau einer Verbindung angeben ob er jetzt http oder https verwenden will,aber Apple kommt sowohl den Nutzern als auch den Entwicklern mit ATS entgegen.
Der Trick ist ja nicht die Arbeit der iOS Entwickler, sondern die Serverseite. Ein ordentliches Zertifikat kostet Geld (ja, für jedes einzelne Gerät) und darf keine quasi unendliche Laufzeit haben, muss also später sicher(!!!) austauschbar sein.
Bringst Du Deinen Fernseher dann zum Händler Deines Vertrauens, damit das SSL Zertifikat nach einem Jahr erneuert wird, damit Deine DLNA App auf dem iPhone weiter funktioniert? Nein. Also schaltet der Hersteller des Fernsehers in seiner iOS App ATS aus. Und ich habe als Sicherheits bewusster Anwender in meinem LAN überhaupt kein Problem damit.
Und nein, Apple hat keinen Filter um HTTP ausschließlich im LAN zu erlauben. „Im LAN“ ist auch nicht immer einfach definierbar (bedenke VPN).
Klar ist es für iOS Entwickler technisch einfach zwischen HTTPS mit ATS und HTTP hin und her zu schalten, aber das ist nicht der Punkt. Der Server ist das Problem, das nicht immer wirtschaftlich vernünftig lösbar ist.
Ok,ich hätte mich etwas genauer ausdrücken müssen. Ich habe an das klassische Client-Server-Modell im Internet gedacht,sprich Client->Router->NAT->Server(ganz grob gesehen). Im LAN ist es durchaus problematisch mit den Zertifikaten, da hast du vollkommen recht.