Oorspronkelijk moesten appontwikkelaars zorgen dat hun apps voor 1 januari 2017 geschikt zijn voor Apple’s nieuwe App Transport Security (ATS). Maar onlangs bleek al, dat veel ontwikkelaars die deadline niet gaat halen. Apple heeft daarom de datum opgeschoven naar een nog niet nader genoemde datum.
ATS verplicht voor nieuwe apps
ATS werd in iOS 9 en OS X 10.11 geïntroduceerd en zorgt ervoor dat apps alleen nog via beveiligde serververbindingen (https) kunnen communiceren. Tijdens WWDC 2016 werd aangekondigd dat het verplicht zou worden. Ontwikkelaars hebben anderhalf jaar de tijd gehad om eraan te wennen, dus de deadline van 1 januari 2017 kwam niet eens zo abrupt. Toch lijkt het voor veel ontwikkelaars een onmogelijke opgave.
In een korte verklaring op Apple’s Developer-website laat het bedrijf weten dat de verplichting om ATS te gebruiken is opgeschoven, zodat ontwikkelaars meer tijd hebben om zich voor te bereiden. Bij ATS word de beveiliging en de privacy van apps verbeterd doordat alle data via beveiligde verbindingen (https) verloopt. Steeds meer online diensten stappen daarop over, ook als ze geen financiële of privacygevoelige informatie hoeven te versturen, omdat de data minder makkelijk kan worden afgetapt.
ATS staat standaard ingeschakeld in de ontwikkeltools van Apple, maar ontwikkelaars kunnen het uitschakelen. In 2015 leidde de aankondiging van ATS zelfs tot wat ophef, omdat het protocol bepaalde Google-advertenties blokkeerde. Google bood ontwikkelaars vervolgens een trucje om ATS te omzeilen, maar dat leverde wel weer extra beveiligingsrisico’s op.
Taalfout gezien of andere suggestie hoe we dit artikel kunnen verbeteren? Laat het ons weten!
Het laatste nieuws over Apple van iCulture
- Meta brengt losstaande app voor Meta AI uit (maar wij kunnen er nog niet zo veel mee) (30-04)
- Bellen via de browser: 'Webversie WhatsApp krijgt optie voor (video)bellen' (29-04)
- WhatsApp gaat spraakberichten vernieuwen: dit verandert er (28-04)
- WhatsApp vanaf nu met extra beveiligde chats: zo krijg je meer privacy (23-04)
- Betalen om je account te delen? Ook bij HBO Max zul je eraan moeten geloven (en zoveel betaal je in de VS) (23-04)
Ik ondersteun het idee van de verplichting, maar ben blij dat het is uitgesteld!
Het ligt er namelijk lang niet altijd aan of de developers er klaar voor zijn.
Als je afhankelijk bent van apparatuur van derden (in mijn geval de Philips Hue Bridge die geen https ondersteund), kun je er zelf helaas weinig aan doen..
@Michiel: Je zou juist verwachten dat fabrikaten zoals Philips met hun Hue lineup dit zouden moeten ondersteunen in deze tijd.
Wat geeft dit aan? Werkt het zigbee protocol voor de beveiliging van een commando, of kan dus iedereen die de pakketjes kan opvangen zomaar informatie eruit halen of moeten ze dan wel in jouw LAN bevinden om deze te kapen?.
Kortom het kan van mij niet snel genoeg komen, steeds meer worden dit soort dingen qua hacken toegankelijker en ondanks dat jezelf er van bewust bent ben je gelijk ook afhankelijk van de beveiligingen van derden, dan hoop je maar dat je bij de grotere jongens enigszins ook betaald voor veiligheid.
Slechte zaak, en vreemde vorm van met twee maten meten tov verschillende soorten ‘verouderde’ apps. Laten ze dáár maar een irritante pop-up op geven als een app nog niet is aangepast, ipv op het veel ongevaarlijkere 32-bits zijn van een app 🤔
@Angelus: (Correctie:) standaard staat de bridge niet open van buiten en zul je dus toegang moeten hebben tot het LAN.
De huidige beveiliging bestaat uit de touch-link: een nieuwe app wil toegang tot jouw bridge, dan moet je binnen 30 seconden fysiek op de ’touch-link’ knop op de bridge drukken. Klinkt veilig..
Echter: de app krijgt dan een unieke identificatie (die bij elk commando in de http adres regel moet worden opgenomen 🤔) en daarmee is alles te doen op de bridge.
Zelf heb ik dit enigszins proberen te tackelen door mijn iOS (client)-app niet met de bridge te laten communiceren, maar met een macOS (server)-app in het netwerk zelf, die vervolgens alle communicatie met de bridge regelt. In dat geval zou dit inderdaad alleen zichtbaar zijn bij het sniffen in de LAN zelf.
Al sinds Apple vorig jaar met de voorgenomen maatregel kwam, is er met regelmaat aan Philips gevraagd wat ze van plan waren.. Buiten dat “https niet mogelijk is” en “ze in gesprek zijn met Apple over dit besluit” is er eigenlijk niks veranderd.
Inderdaad jammer dat ze ervoor kiezen om hierover met Apple te gaan praten ipv een veilige, structurele oplossing te bedenken.
@Michiel: bedankt voor je uitleg, hier heb je wat aan 🙂 ik heb zelf dan geen account gemaakt bij philips hue en laat het van buitenaf zijn werk doen doormiddel van me appletv, die figureert dus als hub en heeft dus in LAN zijn unieke verificatie code die dus waarschijnlijk niet beveiligd is.
Hoewel dit dus door Homekit gebeurd waar naar wat ik heb gelezen een sterke beveiliging heeft, weet ik dus niet of dit aberhaupt veiliger is. Beste beveiliging is om het helemaal uit te zetten, alles wat buiten je LAN plaats vindt.
Hierdoor ben ik dus laatst ook afgehaakt van slimme thermostaten, hoewel dit een leuke gadget gehalte geeft en mij zeker geld kan laten besparen, vind ik het erger dat ze aan me verwarming lopen te klote dan mijn lichten.