Apple geeft app-ontwikkelaars meer tijd voor https-verplichting

Apple heeft de deadline voor het verplicht ondersteunen van App Transport Security verschoven. Ontwikkelaars moesten per 1 januari hun apps geschikt gemaakt hebben voor beveiligde https-verbindingen, maar krijgen nu meer tijd.

Apple heeft het schrappen van de deadline van 1 januari op zijn developer-site bekendgemaakt. Een nieuwe deadline geeft het bedrijf nog niet. Het bedrijf wil app-ontwikkelaars meer tijd geven om zich voor te bereiden, wat erop duidt dat lang niet alle ontwikkelaars klaar waren voor de implementatie.

Afgelopen zomer maakte Apple bekend de ondersteuning van App Transport Security verplicht te stellen bij apps die toegevoegd worden aan de App Store. ATS maakt gebruik van tls 1.2, de opvolger van het ssl-protocol voor versleutelde verbindingen. Het bedrijf introduceerde ATS met de komst van iOS 9 en OS X 10.11.

Lees meer

IT-banen

Reacties (44)

holoduke51
22 december 2016 20:30

Sommige mensen zijn hier wel heel makkelijk over de overschakeling van http naar https.

Anders dan bij websites is bij apps altijd sprake van backwards compatibility problemen. Er zijn altijd mensen die met oudere versies van de app rond lopen. Het kan zomaar 1 jaar duren voordat 95% over is op de nieuwste versie.
Het resultaat is dat een eenmaal toegepaste API voor een lange tijd in de lucht moet blijven. Dit geldt ook wanneer je overgaat op HTTPs. Je ben bijna verplicht om zowel http als https te draaien. Je wilt immers geen gebruikers verliezen.
Nu is dit vrij eenvoudig op te zetten als je vanaf scratch begint. Maar een bestaande infrastructuur vraagt soms een stuk meer werk. Zoals bij ons bedrijf
Wij hebben we een inschatting gemaakt van de operatie. Het gaat al snel richting de 20 a 40k om alles gereed te hebben:

- apps aanpassen
- certificaten regelen
- server infrastructuur aanpassen
- applicatie laag aanpassen.
- load balancers aanpasssen
- cdn providers aanpassen.

Veel bedrijven hebben hetzelfde probleem en nu heeft Apple het gelukkig erkent.
Overigens is er nog steeds een discussie of HTTPS echt nodig is voor GET API's waar geen gebruikers gegevens verstuurd worden. Maar goed, de overhead van HTTPs is bijna nul te noemen. Toch op een of andere manier beginnen veel bedrijven (wij ook) met HTTP services. Het zal misschien toch liggen aan het gezeur met certificaten wat in het verleden zeker een rol speelde. Nu eindelijk een stuk minder met diensten als LetsEncrypt etc.

xoniq
@holoduke51 • 22 december 2016 22:22

In Xcode moet je al een zeer lange tijd een aparte plist sleutel aanzetten om HTTP te ondersteunen naast HTTPS. Dus het is bij developers al heel lang bekend.
Het is niet zo dat het 'opeens' moet maar de deadline verlegd is verder. Zelfs als ze nu elke week een mailtje sturen, dan is men er over 3 jaar nog niet klaar voor, omdat men vaak denkt dat ze nog tijd zat hebben, en dan over 2,8 jaar denken; oh ja dat moet nog, en hebben ze ineens weer te weinig tijd voor de implementatie.

Als men bij de eerste signalen van HTTPS verplichting hiermee begonnen, was iedereen er zo onderhand wel klaar voor.

ro8in
@holoduke51 • 23 december 2016 07:49

Je kan toch gewoon de oude versie laten stoppen met werken en een melding weergeven dat ze de nieuwe moeten downloaden.

D4NG3R
@ro8in • 23 december 2016 08:33

De functionaliteit daarvoor moet echter al wel aanwezig zijn.

[Reactie gewijzigd door D4NG3R op 23 december 2016 08:48]

90710
@D4NG3R • 23 december 2016 08:44

Een beetje een logische eerste stap: zorg ervoor dat je een boodschap kan tonen als je applicatie geen verbinding met de server kan maken incl. een reden.

ro8in
@D4NG3R • 23 december 2016 09:22

Dat klopt, maar bij een online app lijkt me dat een verbinding check plus reden melding ongeveer zo het eerste is wat je inbouwt.
Als je dat niet hebt is het toch echt wel een beetje je eigen schuld dat je met de gebakken peren zit en niet die van Apple.

[Reactie gewijzigd door ro8in op 23 december 2016 09:24]

BoringDay
@holoduke51 • 22 december 2016 21:02

Code technisch lijkt het mij niet heel spannend en de frameworks voor UrlRequests/NetService zitten goed in elkaar op dat gebied. Certificaten zal wel een verhaal apart zijn (dat is vaak eenmaal ellende).

kozue
@holoduke51 • 23 december 2016 09:06

Je kunt de backend api gewoon heel simpel op beide laten draaien hoor. Ze zitten sowieso op een andere poort. De oude app zal dan tegen poort 80 praten, en dit blijven doen, en de nieuwe tegen poort 443. Het enige dat je extra nodig hebt is een certificaat (met iets als letsencrypt kost dat zelfs niks meer), en wat configuratie op de webserver. Geen aanpassingen aan de backend zelf voor nodig.

djwice
@holoduke51 • 26 december 2016 20:58

Welke data gaat er over http? Zijn er überhaupt apps die wel nieuwe data halen, maar geen persoonsgegevens sturen/ontvangen?

Anoniem: 366402
22 december 2016 23:22

In de meeste gevallen is het plaatsen van een reverse proxy met SSL, het gebruik van HTTPS CDN's indien nodig en een https verbinding initieren vanuit de app voldoende.
Dus het lijkt me niet zo heel spannend.

Ik vraag me enkel wel af hoe ver dit gaat.
In het geval met het IOT en lichtgewicht apparaten in je thuisnetwerk, wordt er dan ook verwacht dat het allemaal over https loopt? (Moet je bijv. een lamp met een geldig SSL certificaat hebben? Dat zal toch niet?) Of geldt het hier echt enkel voor apps die echt een backend server raadplegen op het internet?

Anoniem: 368883
@Anoniem: 366402 • 23 december 2016 10:08

Goeie vraag.

Deze apparaten werken meestal met een "bridge" via radiosignalen (ZigBee, of iets gelijkaardig). In het beste geval zit er al een vorm van encryptie in de communicatie tussen devices en bridge.

De apps zelf spreken enkel met de bridge via een webservice, dus daar zal wel iets van TLS op moeten draaien? De Philips Hue Bridge bijvoorbeeld, werkt via HTTP, en een vorm van token-based authentication. Ik neem aan dat deze bridge een firmware update zal moeten krijgen voor https? Ik vroeg me ook af of self-signed certificaten hier voldoende voor zijn.

BikkelZ
22 december 2016 19:37

Altijd een mooie reden om er bij klanten op aan te dringen HTTPS te gebruiken, het beeld dat Apple wel eens een app zou kunnen weigeren of updates blokkeren. En het is ook geen rocket science of duur om het te implementeren. Volgens mij is het wel goed om in de toekomst bij non-HTTPS apps een melding in beeld te tonen waarbij gemeld wordt dat er gebruik gemaakt wordt van onveilige verbindingen. Maar niet alle applicaties kunnen naar HTTPS als ze afhankelijk zijn van derden dus volledig blokkeren is ook niks.

[Reactie gewijzigd door BikkelZ op 22 december 2016 19:38]

klaaspolinder
@BikkelZ • 22 december 2016 19:47

Als app ontwikkelaar zou je je wel af kunnen vragen of je die 'derden' nog wel wilt gebruiken als ze anno 2016 nog geen HTTPS ondersteunen...

Eitot
@klaaspolinder • 22 december 2016 19:56

Het is niet alleen HTTPS, maar TLS 1.2. Inclusief ‘perfect-forward secrecy’. Dat gebruikt helaas ook nog niet iedereen.

Firefly III
@Eitot • 22 december 2016 20:18

Configuratie om dat in te stellen is één Google search.

WhiteDog
@Firefly III • 23 december 2016 00:01

En wat als de OpenSSL versie die bij je distro zit dat niet ondersteunt en men het niet gaat backporten? Niet elke ontwikkelaar heeft een eigen server, de tijd om een server meteen te herinstalleren, je wil geen andere dingen stuk maken, .. dan neemt het wel even tijd om een oplossing uit te werken hoor.

TLS 1.0 is trouwens nog gewoon een standaard. Deze word pas deprecated in 2018. TLS 1.1 zit er ook nog tussen. Waarom hebben die dingen nog een lifecycle als Apple en Google toch alleen maar het nieuwste van het nieuwste willen ondersteunen? Even buiten beschouwing gelaten dat TLS 1.0 e 1.1 er voor mij ook sneller uit mogen

kozue
@WhiteDog • 23 december 2016 09:13

Als je geen eigen server hebt wordt de server toch beheerd door een partij die professioneel servers beheert? Daar mag dan toch wel van verwacht worden dat ze uptodate worden gehouden? Zo nieuw is TLS 1.2 nou ook weer niet.
En als je een eigen server hebt wordt het tijd de software eens af te stoffen. Of er mee willen leven dat je app niet meer in de app store staat natuurlijk. In beide gevallen goed voor de gebruiker, dus goed gedaan van Apple.

jabwd
@kozue • 23 december 2016 09:40

Yeah ben het hier mee eens. Eigenlijk is de hele discussie gewoon "maar wat met de mensen die hun zooitje niet op orde hebben?!" Updaten is verschrikkelijk makkelijk, kost geen geld ( letsencrypt + cronjob = done ).

Het is al een verschrikkelijk lange tijd zo dat je lastig HTTP kan aanvragen via de API's op iOS.... als mensen dan zo veel liggen te snurken weet ik niet eens of hun app wel relevant is.

Firefly III
@WhiteDog • 23 december 2016 10:12

Jezus wat een ongelofelijk wazige hypotetische situatie. Maar inderdaad hoor, zes maanden is wel erg kort

Eitot
@BikkelZ • 22 december 2016 19:51

Ontwikkelaars kunnen voor dit laatste geval per (sub)domain een uitzondering aanvragen, mits ze dit kunnen motiveren. Ontwikkelaars konden voorheen probleemloos gebruik maken van een blanco uitzondering zonder dat dit in het review werd meegenomen, dit mag dan niet meer zodra ze dat gaan handhaven.

Diecke
@Eitot • 22 december 2016 20:20

Moeten bestaande apps ook geupdate worden om te blijven werken of geldt dit alleen voor nieuwe apps/updates?

Eitot
@Diecke • 22 december 2016 21:34

In principe alleen voor nieuwe apps en updates. App Transport Security is vereist als je de build met de SDK voor iOS 9 of 10 linkt. Je kunt nog steeds apps aanleveren die met een oudere SDK zijn gelinkt. In dat geval hoeft het dus niet.

Erulezz
22 december 2016 20:15

Hier ben ben ik voor een bepaald geval wel effe blij mee want ik was het eigenlijk een beetje vergeten

. Ik was er nog niet helemaal uit hoe ik het volgende ging oplossen;

In mijn apps is de verbinding naar de API (mijn server) al ruim een jaar via HTTPS, alleen de content van derden is nog in de meeste gevallen via http. Dit zijn allemaal plaatjes (verder nooit persoonlijke data oid) van wel honderden verschillende domeinen. Dit wijzigt ook regelmatig dus ik kan die niet allemaal whitelisten. Ja dat kan wel maar dat haalt het hele dynamische van de app weg. Dus als ik iets nieuws toevoeg dan moet ik ook een app update indienen. Dat schiet natuurlijk niet op.

Het beste lijkt mij een proxy zoals Tweakers ook geeft geïmplementeerd toen alles over ging naar HTTPS. Eens even op onderzoek uit

TotallyJorden
@Erulezz • 22 december 2016 20:21

Neem ergens een hostingpakket en een ssl certificaat af, en dan inderdaad als een proxy fungeren. Wat meer moeite en dataverkeer maar het werkt wel.

xoniq
@TotallyJorden • 22 december 2016 22:27

Of een eigen VPS met Lets Encrypt

werkt prima hoor.

xoniq
@Erulezz • 22 december 2016 22:25

want ik was het eigenlijk een beetje vergeten

Terwijl je in Xcode voor al je apps met een plist sleutel moet inschakelen dat HTTP voldoende is?

Xerxes249
@xoniq • 22 december 2016 22:56

Zolang je niet update boeit het niet

xoniq
@Xerxes249 • 22 december 2016 23:27

Wat niet, Xcode? Als je Xcode niet update mis je ook veel nuttige functionaliteit en de goede iteraties van Swift 2 en 3.

biteMark
@xoniq • 23 december 2016 01:21

Zo lang je de app update blijft die plist sleutel wel staan, die hoef je niet elke keer opnieuw te setten.

xoniq
@biteMark • 23 december 2016 08:02

Maar wel als je een app project start, of het voor een concept is of retail, dan wordt je er toch wel aan herinnerd.

biteMark
@xoniq • 23 december 2016 09:20

Klopt, maar de vraag hierboven ging over updaten

xoniq
@biteMark • 23 december 2016 10:05

Nee hoor. Puur over dat ie https vermijd omdat de CDN's geen https gebruiken.

Xerxes249
@xoniq • 23 december 2016 02:41

Nee, ik bedoelde dat je het best kan vergeten als je je app niet regelmatig update. Dan kom je niet elke keer die xcode warning tegen om de simpele reden dat je gewoon niet naar die app omkijkt

Anoniem: 578046
@Erulezz • 22 december 2016 20:20

Over de eigen proxy zou je ook nog eens een CDN zoals Cloudflare kunnen gebruiken. Dat scheelt centen en de content is zo beter bereikbaar voor de eindgebruiker. En met HTTPS werkt het ook gewoon.

WeeJeWel
@Erulezz • 23 december 2016 01:06

Uit de WWDC video:

We're also offering a Web Content Exception. So, here sometimes your app needs to load arbitrary content from around the web and of course you can't guarantee that's using HTTPS. So, if you're WKWebView, then you can just set this key in your app's Info.plist.

JJ93
22 december 2016 20:51

Tja, naar mijn mening hebben developers lang genoeg de tijd gehad voor de HTTPS-implementatie. In ieder geval goed dat Apple pusht om dit te implementeren. Als je het nu nog niet voor elkaar had terwijl je dondersgoed wist dat de deadline er aan kwam... Maarja, nu is er alsnog uitstel van executie.

xoniq
@JJ93 • 22 december 2016 22:26

Ach dit is gewoon een laatste waarschuwing, om mensen die het vergeten zijn even wakker te schudden.

dreambofh
22 december 2016 21:45

We hebben een paar api's behoorlijk wat content bronnen etc jaren geleden al op HTTPS gezet. Geen centje pijn. Tevens een meldinf naar de oude app gebruikers dat ze moesten updaten, ook geen probleem. Juist alleen een vooruitgang, geen oude dingen meer onderhouden!

lf2
23 december 2016 09:36

Super jammer van Apple om zoiets verplicht te maken. Er zijn genoeg apps die plain data ophalen waar security niet eens voor nodig is

Wrm moet bijvoorbeeld weer informatie nou over https gaan ?

Extra kostenpost voor apps waar men niet eens voor wilt betalen. Soms kan je ook niet zo veel als de externe api dat niet eens heeft

Flitskikker
23 december 2016 15:57

Weet iemand of dit alleen voor productie geldt? Mijn lokale ontwikkel-/test-API's zijn meestal niet (meteen) HTTPS.

Probook8979
22 december 2016 21:18

Hoe zit 't als een (smart)lamp simpelweg niet overweg kan met https?

jeroen3
@Probook8979 • 22 december 2016 21:37

Die raakt obsolete. Welkom in de wereld van de internet of things.

Tozz
@jeroen3 • 23 december 2016 08:54

Ik ben totaal onbekend met Apple, maar als ik even snel Google op App Transport Security dan lees ik dat ze HTTPS vereisen.

Een lamp aansturen kan ook met iets anders dan HTTP. bv. een simpel TCP socket of een UDP packet. Dat hoeft niet over HTTPS/SSL/TLS.

Kortom, (zoals in een andere post werd gevraagd) volgens mij hoeft niet elke lamp een SSL certificaat te hebben en raakt dit lampen mogelijk helemaal niet, als ze niet via HTTP worden aangestuurd.

En volgens mij, maar correct me if i'm wrong, bv. de Philips Hue lampen zijn niet heel makkelijk door derden aan te sturen. Het is geen simpel HTTP request. Dat zal met meer lampen het geval zijn.

Lethalis
23 december 2016 16:03

Grappig, op mijn werk waren we ook nog niet klaar voor deze deadline.

Dus mij komt dit wel goed uit

Op dit item kan niet meer gereageerd worden.

Apple geeft app-ontwikkelaars meer tijd voor https-verplichting

Lees meer

IT-banen

Reacties (44)

Sorteer op:

Weergave:

Tweakers maakt gebruik van cookies

Toestemming beheren

Functioneel en analytisch

Relevantere advertenties

Ingesloten content van derden