-
Betrifft nur HTTP APIs!
Autor: /mecki78 10.06.15 - 13:47
Was hier immer gerne übersehen wird, APS betrifft nur die OS X HTTP APIs (im westenlich die Foundation Framework Klassen NSURLSession, NSURLConnection und NSURLDownload) und die API, auf denen die aufgebaut sind (CFStream Klassen im CoreFoundation Framework).
Apps die direkt Sockets öffnen oder eigenen HTTP Libraries nutzen (z.B. libcurl) sind davon nicht betroffen, für die besteht nach wie vor kein TLS Zwang. Apple will nur nicht mehr, das Entwickler mit iOS Boardmitteln unsichere HTTP Verbindung aufbauen (und HTTP ist eben das häufigste Protokoll hier um Daten zu laden oder REST API Calls zu machen). Natürlich darf eine Mail Client App nach wie vor auch SMTP/IMAP/POP3 Verbindungen zu einem Mailserver machen (das geht nicht über HTTP) und natürlich auch zu Mailservern, die keine Verschlüsselung erlauben. Dass mussten aber Entwickler schon immer selber implementieren, weil Apple dieses Protokolle z.B. nicht anbietet.
NSURLConnection ist primär für HTTP Verbindungen gedacht, kann aber z.B. auch FTP Verbindungen und nicht einmal hier wird TLS erzwungen, APS betrifft wirklich ausschließlich HTTP Verbindungen. Davon ab wird es wohl auch langfristig erlaubt sein HTTP Verbindungen zu benutzten, wenn man Apple klar machen kann, warum das unvermeidbar ist (z.B. weil man keine Kontrolle über die Server hat, zu denen man verbindet; Apples Webbrowser wird auch nach wie vor HTTP Verbindungen öffnen können müssen). Man muss es aber sinnvoll begründen können und in dein meisten Fällen wird man das nicht können (Faulheit, "war einfacher", "ist billiger", "was ist TLS?" sind zwar Gründe, aber keine sinnvollen).
/Mecki -
Re: Betrifft nur HTTP APIs!
Autor: shyps 10.06.15 - 14:09
Danke für die Klarstellung. :)
Ich hab gerade mal in den source von Gideros geschaut - so ne kostenlos gewordene, tolle Middleware. Und seinen Gideros UrlLoader bewerkstelligt es mittels NSMutableURLRequest, sein ignoreSslErrors via NSURLCredential.
Naja, ich werd's merken, wenn es nicht geht. Noch test ich meine App nur in Android rum. Bzgl. faul und billig warte ich mal auf Let's Encrypt.
2 mal bearbeitet, zuletzt am 10.06.15 14:10 durch shyps. -
Re: Betrifft nur HTTP APIs!
Autor: deefens 10.06.15 - 17:33
shyps schrieb:
--------------------------------------------------------------------------------
> Und seinen Gideros UrlLoader bewerkstelligt es
> mittels NSMutableURLRequest, sein ignoreSslErrors via NSURLCredential.
Gut zu wissen. Ich versteh nur Bahnhof :) -
Re: Betrifft nur HTTP APIs!
Autor: shyps 10.06.15 - 18:22
Es bedeutet nur, dass diese Middleware nicht das tut, was mecki beschrieben hat (API ausserhalb von IOS benutzen) und damit unsicheres HTTPS darin vielleicht bald geblockt wird. Willst du es denn verstehen oder welchen Zweck verfolgt dein Beitrag? :)
-
Re: Betrifft nur HTTP APIs!
Autor: /mecki78 11.06.15 - 01:14
shyps schrieb:
--------------------------------------------------------------------------------
> Und seinen Gideros UrlLoader bewerkstelligt es
> mittels NSMutableURLRequest, sein ignoreSslErrors via NSURLCredential.
Ein NSMutableURLRequest alleine nützen ja noch nichts. Irgendwas muss man ja damit machen, denn der beschreibt ja sonst nur wie eben der Request aussehen soll, also ob das ein GET, POST, HEAD ist, wie das Caching ist (darf er aus dem lokalen Cache beantwortet werden oder nicht), wie hoch der Timeout der Verbindung ist, und eben an welche URL der geht. Typischer Weise erzeugt man so einen Request und erzeugt dann eine NSURLConnection mit diesem Request und feuert dann los. Und hier würde APS dann zuschlagen.
Ich glaube übergangsweise ist das aber kein Problem, wenn du nur zu bestimmten Domains auf TLS verzichten willst (z.B. nur bei deinem eigenen Server). Noch darfst du die nämlich aus Ausnahmen listen. Solange das nur ganz konkrete Domains sind, musst du die auch nicht groß begründen (begründen musst du nur, wenn du beliebe Domains ohne TLS nutzen willst, weil dann ist die Frag, warum bitte muss deine App so etwas können?). Aber diese konkreten Ausnahmen sind nur übergangsweise, steht jetzt schon fest, dass die irgendwann rausfliegen werden (man hat sie soz. eingeführt und gleich für deprecated erklärt; so was hat Apple schon ein paar mal gemacht).
Das man an sich verschlüsseln muss, das finde ich völlig unkritisch, aber ATS schreibt auch vor wie! Er reicht nicht, dass dein Server einfach nur TLS kann, da gibt es noch weitere Einschränkungen (siehe Artikel, leider nicht konkret). Ich glaube er muss TLS 1.2 können (1.0 und 1.1 gehen wohl nicht, SSL schon dreimal nicht), er darf nicht nur RC4 zum verschlüsseln anbieten (er darf es auch anbieten, solange er auch was anderes anbietet, das iOS kann) und ich glaube die Schlüssellängen dürfen nicht zu kurz sein. Apple will hier wirklich auf Nummer Sicher gehen, dass die Verbindung auch sicher ist. TLS 1.0 und 1.1 haben bekannte Schwachstellen, RC4 gilt als geknackt und zu kurze Schlüssel sind per se unsicher.
/Mecki



