'Veel populaire iOS-apps versleutelen netwerkverkeer niet'

Een Duitse beveiligingsonderzoeker en voormalig Apple-werknemer heeft de veiligheid van de 200 in Duitsland populairste iOS-apps bekeken. Hij stelt dat 111 apps onder meer hun netwerkverkeer niet versleutelen.

De onderzoeker, Thomas Jansen, deelde zijn bevindingen met de Duitse krant Die Zeit. Doordat de apps geen versleutelde verbinding gebruiken of de bijbehorende certificaten niet voldoende controleren, kan bijvoorbeeld een aanvaller met een man-in-the-middle-positie op een draadloos netwerk gegevens onderscheppen. Zo zou hij onder meer logins of andere gevoelige gegevens in handen kunnen krijgen. Tot nu toe heeft Jansen 51 onveilige apps bij 24 ontwikkelaars gemeld, waarvan 16 hebben gereageerd en 5 een oplossing hebben geboden.

Linus Neumann van de Duitse Chaos Computer Club heeft de bevindingen van Jansen bekeken en zegt tegen de krant dat er voor het versturen van plaintext 'tegenwoordig geen argumenten meer bestaan'. Apple heeft niet op de bevindingen gereageerd. Het bedrijf wilde ontwikkelaars eigenlijk per 1 januari van dit jaar verplichten om van App Transport Security gebruik te maken, maar stelde deze deadline uit naar een onbekende datum.

De beveiligingsfunctie werd geïntroduceerd in iOS 9 en moet zorgen voor een beveiligde https-verbinding tussen een app en de bijbehorende backend. Apple geeft aan dat dit in alle gevallen toegepast zou moeten worden, maar er zijn uitzonderingen. Soms moet een app verbinding maken met een onbeveiligd domein, bijvoorbeeld van een cdn. In dat geval moet de ontwikkelaar dat domein specifiek vastleggen.

Reacties (81)

[Soldaatje]

Zou het kunnen zijn dat als je films gaat streamen of iets anders met veel netwerkverkeer de batterij sneller leeg gaat door het constant moeten ontsleutelen van de data op TLS niveau?
Of is dit verwaarloosbaar?

[jabwd]

De meeste moderne instructiesets hebben een vorm van support voor AES crypto instructies. Het valt eigenlijk reuze mee hoeveel extra overhead dit veroorzaakt. Dit gebeurd vaak echter wel pas op grotere data sets ( iOS, >2048bytes aan data dacht ik ), dus in veel gevallen worden software implementaties ook nog steeds gebruikt.

In sommige gevallen wordt er nu ook elliptic curve crypto gebruikt, wat veel kleiner keys nodig heeft dan RSA ( wat voornamelijk gebruikt wordt ). Een veilige RSA key begint nu eigenlijk pas bij 2048bits, waar een zeker gelijkwaardig EC ( albeit met een veilige curve https://safecurves.cr.yp.to ) maar 256bits heeft. Als je dan hierbij nog steeds AES als stream cipher gebruikt ( zodat je de hardware acceleration kan gebruiken ) is het nog efficiënter!

In het geval van websites kan het gebruik van TLS juist een groot voordeel zijn, aangezien het required is voor HTTP/2. HTTP/2 zorgt ervoor dat er niet meerdere keren een verbinding met dezelfde server gemaakt hoeft te worden om meerdere files binnen te trekken, CSS, JS html etc. Tuurlijk zou hetzelfde voordeel er zijn als de crypto niet vereist was, maar het is het waard om het op te noemen.

[Reactie gewijzigd door jabwd op 23 juli 2024 07:06]

[CAPSLOCK2000]

Of is dit verwaarloosbaar?

Op een moderne processor is het inderdaad verwaarloosbaar, mits je de juiste soorten encryptie gebruikt. Een moderne processor heeft namelijk ondersteuning voor encryptie ingebouwd. De zware handelingen kun je direct door je CPU laten doen op speciaal daarvoor gereserveerde hardware. Dat gaat razendsnel.

[oef!]

Met openvpn op mijn telefoon heb ik een andere ervaring. Als ik vanaf mijn s8 (moderne telefoon dus je zou denken dat het goed gaat) een openvpn verbinding opzet naar huis met 2048 bits AES "encryptie" dan sloopt dat mijn batterij. Al is het natuurlijk mogelijk dat een ander onderdeel van de app voor een extreem verbruik zorgt.

[Reactie gewijzigd door oef! op 23 juli 2024 07:06]

[CAPSLOCK2000]

Een zwak punt is dat je processor wel gevraagd moet worden om de crypto-hardware in te zetten. Een CPU kan niet zien dat ie bezig is met encryptie. Software moet dus aangepast worden om hier gebruik van te maken en dat is lang niet altijd het geval.

[analog_]

Maakt eigenlijk bijna niet uit, een Cortex M3 was goed genoeg voor 10Mbit aan software symmetrische XTR en dat is 5$ chip.

[EraYaN]

Nou is OpenVPN net een vrij nare die je daar zo noemt, daar wil nog wel eens de implementatie van de openvpn client het probleem zijn.

en ik neem aan dat je geen 2048 bits AES gebruikt, denk niet dat het uberhaupt een ding is voor OpenVPN. Hooguit is je certificaat (RSA) van die grootte. Je VPN tunnel zal AES128-CBC of AES256-CBC zijn of iets dergelijks.

[oef!]

Het is inderdaad aes256cbc. Al die acronymen worden mijn dood nog eens

[Rafe]

Kijk eens of je kan upgraden naar OpenVPN 2.4 en gebruik AES128-GCM. GCM is een stuk vlotter zoals dit stuk aantoont: https://medium.com/netfli...acy-at-scale-39c675d88f45

[Anonymoussaurus]

Nee, hij legt in feite een beveiligde tunnel aan, waar de data doorheen gaat. Het gaat om de verbinding die wordt versleutelt, niet om de data/content zelf. Je kan het zo zien: je legt 1 keer een tunnel aan (TLS tunnel in dit geval), en vervolgens kunnen de auto's (in dit geval de pakketjes/inloggegevens) door die tunnel rijden.

[DenBeke]

En hoe stuur je iets door een "beveiligd tunnel" zonder de data/content aan te passen (i.e. encrypten)? Dan vliegen de onbeveiligde pakketjes/data toch nog over het netwerk?

[Anonymoussaurus]

@Soldaatje Ik vraag me af of jullie het snappen, want ik heb het niet over batterij of rekenkracht, maar puur over het verschil.

Er is een verschil tussen een verbinding en de content die door de verbinding gaat. Voorbeeld om het begrijpelijk te maken: Stel dat WhatsApp niet de berichten versleutelt die door gebruikers worden verzonden, maar wél door een TLS-tunnel gaan. Dan kan je met een Man-in-the-middle alsnog de WhatsApp-berichten opvangen en zo lezen. Dat is ook iets wat @s1h4d0w zei.

[DenBeke]

Het punt van TLS is net dat je geen MITM kan doen, omdat je doormiddel van de certificaten je identiteit aantoont. Eens twee partijen een TLS verbinding hebben opgezet kan niemand de voorbij komende pakketten gaan decrypten, want ze worden elk op hun buurt versleuteld.

Je zet je connectie op door asynchroon je publieke sleutels uit te wisselen en dan ben je zeker dat de tegenpartij effectief de tegenpartij is waarmee je wenst te communiceren. (We gaan er hier vanuit dat er een CA aan te pas komt). Eens die asynchrone authenticatie gebeurd is, heb je een symmetrische sleutel waarmee je de datastream beveiligt, dus om @Soldaatje zijn vraag te antwoorden: ja er de data moet nog versleuteld worden. En dat kost rekenkracht. Wat de impact daarvan is op batterij/performantie durf ik niet te zeggen.

En ja, ik snap je verhaal dat het goed is da Whatsapp de berichten nog versleutelt, maar het zou me ten zeerste verbazen moest MITM mogelijk zijn bij Whatsapp.

[Anonymoussaurus]

Je voorkomt het niet, maar je verkleint de kans. Dat de website of applicatie een certificaat heeft, betekent niet dat de verbinding veilig is, want het zegt alleen dat persoon A en B met elkaar aan het communiceren zijn. Vóórdat deze verbinding wordt gemaakt, kan er prima een Man-in-the-middle plaatsvinden, waardoor de website een certificaat uitdeelt aan de aanvaller in plaats van aan de tegenpartij. Of wat dacht je van nepcertificaten? Daardoor denk je dat je met de goede server babbelt, maar dat is in werkelijkheid niet zo. Bronnen:

• nieuws: Onderzoeker laat Symantec certificaat intrekken met nepprivésleutel
• nieuws: 'Hackers gebruikten Stuxnet-certificaat om onderzoekers te misleiden'
• nieuws: Nederlands bedrijf ontdekt kwetsbaarheid voor uitgeven valse ssl-cert...
• nieuws: Aangepaste Dridex-malware vermomt zichzelf als certificaat

Maar goed, we zijn het er denk ik wel over eens dat het opzetten van een beveiligde verbinding wel kracht kost, maar dat is maar eenmalig, totdat je de verbinding weer verbreekt.

[Reactie gewijzigd door Anonymoussaurus op 23 juli 2024 07:06]

[EraYaN]

Als er een correcte TLS inplementatie gebruikt wordt, is dat prima af te vangen. Men kan ook gewoon de CA's pinnen, of zelfs de certificaten zelf.

En encrypten blijft echt kracht kosten hoor, ieder pakket (inclusief content) gaat gewoon door AES heen.

Probeer voor de gein maar eens een router met hoge VPN (ook een "tunnel") throughput te bouwen, daar zal echt een flinke CPU in moeten.

[analog_]

Voor bijvoorbeeld HTTP is opgelost door je public key v/h certificaat in DNS te publishen onder DNSSEC. Op dat punt moet je een CA certificaat (OS pretrusted preferably ) ownen om iets interessants te kunnen gaan doen (implementatie fouten buiten beschouwing). Client side kan bijvoorbeeld met eID en z'n fysieke token (je ID kaart).

[Reactie gewijzigd door analog_ op 23 juli 2024 07:06]

[johnkeates]

Nee, dat is niet hoe het werkt, je zit er totaal naast. De applicatie zelf hoeft inderdaad niks extra's te doen, want de encryptie gebeurt op de transport laag, niet op de applicatie laag. Dat houdt in dat alle data versleuteld wordt, voor dat het op de volgende laag komt die de data daadwerkelijk fysiek van A naar B brengt. Dit betekent dat *alles* versleuteld is, niet dat je een magische tunnel hebt waarbij er aan de 'buitenkant' magische crypto zit maar aan de 'binnenkant' leesbare data bestaat.

Normaal wordt de data in pakketjes dan A naar B gestuurd, dat betekent de inhoud, en de encapsulatie, bijvoorbeeld TCP headers en checksums, IP headers, Ethernet frames of 802.11 frames enz. Die frames zelf worden niet gecodeerd, en de IP pakketjes ook niet, en de TCP pakketjes daar weer in ook niet. De data in die TCP pakketjes is de TLS sessie, en die bevat wel gecodeerde data. Het is die TLS 'sessie' die de 'tunnel' is waar jij hebt over hebt, en alle data in dat pakketje wordt gecodeerd. HTTP verkeer, RTSP, MPEG transport streams, audio, alles. Dat is ook de reden waarom TLS in principe overal op toe te passen is, de applicatie hoeft er niet van op de hoogte te zijn, en kan z'n data als gebruikelijk verzenden en ontvangen. Eigenlijk zit het enige grote verschil in het openen van een socket. Je kan bij het openen aangeven dat je een TLS socket wil, en dan ben je er al. Alle opvolgende zaken kan je onveranderd laten.

Dus, om op de vraag in te gaan van de persoon die zich afvroeg of nu alles constant gecodeerd/decodeerd wordt: ja, dat is zo. Of het extra energie nodig heeft, ja, natuurlijk, maar niet zo veel als je zou denken door dat CPU's en SoC's om een beetje zuinig te kunnen zijn dedicated hardware hebben om snel en met weinig energie AES en andere cryptografische functies uit te voeren. Zo kan je in plaats van honderden cycles met een paar cycles hetzelfde crypto werk doen.

[Anonymoussaurus]

Ik weet niet hoe je erbij komt, maar encryptie gebeurd op de presentation layer, niet op de transportation layer: http://searchnetworking.t...-Stack-Layer-6-Encryption

Bedankt voor de informatie trouwens.

[Reactie gewijzigd door Anonymoussaurus op 23 juli 2024 07:06]

[johnkeates]

Haha, als er een layer is waar encryptie echt niks mee te maken heeft, dan is het wel de presentation layer!

Ik denk dat je je het beste maar even in de materie kan verdiepen voor dat je jezelf nog dieper in een kuil graaft.

[Anonymoussaurus]

Dat heb ik gedaan. Ik heb zelfs de 2 CCNA-cursussen doorgezocht en daar zeggen ze ook dat encryptie gebeurd op de transportation layer.

Laten we overigens wel gewoon normaal tegen elkaar doen, want het hoeft helemaal niet zo negatief te gaan .

[johnkeates]

Het blijft vreemd dat je hamert op die presentation layer of crypto 'tunnels'. Daar ging het om.

[Robbaman]

Wel grappig dat TLS letterlijk Transport Layer Security betekent

Op Wikipedia zijn ze iets genuanceerder over de OSI laag:

TLS and SSL do not fit neatly into any single layer of the OSI model or the TCP/IP model. TLS runs "on top of some reliable transport protocol (e.g., TCP)," which would imply that it is above the transport layer. It serves encryption to higher layers, which is normally the function of the presentation layer. However, applications generally use TLS as if it were a transport layer, even though applications using TLS must actively control initiating TLS handshakes and handling of exchanged authentication certificates.

[lepel]

Klopt, maar dit moet evengoed nog ontsleuteld worden. Als dit niet versleuteld was dan zou je met een MitM aanval evengoed nog alles kunnen afluisteren. Ontsleutelen vergt rekenkracht, maar volgens mij is dit inderdaad verwaarloosbaar. Het komt alleen de snelheid van het opzetten van een verbinding niet ten goede, maar tegenwoordig merk je daar ook amper nog iets van.

[Soldaatje]

De pakketjes zijn wel versleuteld dus ook de data zelf, het is gewoon een onbegrijpelijke brij die op een gegeven moment ontsleuteld moet worden op de telefoon, door een chip met AES instructie om het zo makkelijk mogelijk te maken maar toch.

[EvilItSelf]

Ook niet raar ook. Zo'n ERN nummer aanvragen om een app met encryptie te kunnen exporteren uit de VS, wat je via de App Store doet, is alles behalve een snel process.

[RobinJ1995]

Eh... HTTPS?

[WoBBeL]

Je moet juist een ERN nummer aanvragen als je HTTPS/SSL gebruikt in een app helaas.

Zie ook https://forums.developer.apple.com/thread/28499

[RobinJ1995]

... Zucht. Hoe zelfs. Dit is toch gewoon anti-privacy en anti-beveiliging? Dit kan toch gewoon niet meer in de 21ste eeuw...

[Reactie gewijzigd door RobinJ1995 op 23 juli 2024 07:06]

[supersnathan94]

Dat is US policy. Heeft niets met Apple an sich te maken die moeten zich gewoon houden aan wet en regelgeving.

[mmjjb]

Triest maar waar, dat je een licentie moet krijgen voor het gebruik van encryptie in je app.

Fijn land Amerika, het land waar te sterkte encrpyties maar beperkt toegestaan is...

Met betrekking tot Android/Google / ERN licentie:
"To publish an app on Google Play you need to agree that you follow U.S export regulations. This means if your app is using encryption and meets some rules you need to get an ERN (encryption registration number).

Depending of what kind of encryption you are using you might not need to apply for an ERN.
You do not need an ERN if

• Products with key lengths not exceeding 56 bits symmetric, 512 bits asymmetric and/or 112-bit elliptic curve.
• Mass market products with key lengths not exceeding 64 bits symmetric, or if no symmetric algorithms, not exceeding 768 bits asymmetric and/or 128 bits elliptic curve.
• Products that use encryption for authentication only.

"

Toevoeging 2:
Het gebruik van HTTPS is nu uitgezonderd / vereist geen licentie sinds September 2016
Mits de applicatie alleen gebruikt wordt binnen de US / Canada

Want ze willen de rest van de wereld / europeanen natuurlijk wel blijven afluisteren

Bron: https://stackoverflow.com...essages-encryption-policy
Bron2: https://stackoverflow.com...ryption/40919650#40919650

Edit: fout doorgestreept, bedankt @Bazi

[Reactie gewijzigd door mmjjb op 23 juli 2024 07:06]

[Armin]

Mits de applicatie alleen gebruikt wordt binnen de US / Canada

Nee, je leest dat punt verkeerd. Als de app enkel beschikbaar is binnen de US/Canada heb je uberhaupt geen export vergunning nodig, want "duh" geen export Die punten zoals opgesomd zijn of-of, geen en-en.

Uberhaupt was voor de meeste HTTPS/TLS apps al geen ERN nodig. Apple's formulier was vooral een 'eigen gat bedekken'. Microsoft bijvoorbeeld vereiste het niet en liet/laat het over aan de app makers, en je kunt er donder op op zeggen dat zij ook hun juristen er naar hadden laten kijken.

Voor HTTPS/TLS is echter hoe dan ook anno 2017 geen vergunning meer nodig, ook al is je app wereldwijd berschikbaar.

[supersnathan94]

Opzich ook wel logisch aangezien iedereen en zijn moeder tegenwoordig applicaties bouwt voor iOS. Je kan niet verwachten van die personen dat ze allemaal op de hoogte zijn van regelgeving mbt encryptie. Zeker bij het gebruik van HTTPS aangezien dat tegenwoordig toch de standaard is.

Als startende developer is het dus simpel over het hoofd te zien dat je zo’n vrijwaring moet regelen doordat je het simpelweg niet weet. Dat Apple aangeeft dat dit moet is in mijn ogen dan een goed gebaar om developers op weg te helpen goede, veilige en legale apps te bouwen. Daarnaast kan Apple natuurlijk dikke boets en dergelijke verwachten als blijkt dat ze dit willens en wetens gefaciliteerd hebben. Dus naast dat het CYA is, is het ook gewoon juridisch noodzakelijk.

Dat MS dit niet vroeg is dan ook niet heel slim maar aan de andere kant wel een slimme zet om meer mensen op je platform te laten developpen. Zo’n ERN nummertje kan natuurlijk wel een barriére zijn om je app over HTTPS te laten babbelen aangezien het dan veel meer moeite en administratie kost in de VS.

Express niet gebruiken van HTTPS is echter weer onveilig en MS kan dat met het platform niet veroorloven. Dan maar liever wel gewoon doen en achteraf hopen dat je geen leuke brief krijgt.

[Bazi]

Het gebruik van HTTPS is nu uitgezonderd / vereist geen licentie sinds September 2016
Mits de applicatie alleen gebruikt wordt binnen de US / Canada

Die mits is geen 'mits' maar óf. Als je simpelweg gebruik maakt van HTTPS en hiervoor de standaard iOS-functies voor gebruikt, óf de app alleen binnen de VS beschikbaar is, val je onder de uitzondering.

Je moet alleen jaarlijks een mail sturen naar de NSA met daarin een melding van je apps.

[Reactie gewijzigd door Bazi op 23 juli 2024 07:06]

[Sfynx]

Ik vraag me weleens af hoeveel van de app developers eigenlijk die "self-classification" sturen naar de NSA, het is eigenlijk ook een beetje belachelijk dat developers dat zelf moeten melden terwijl ze alleen maar een API in iOS gebruiken. Het lijkt me toch niet zo lastig voor Apple om dat namens de developer te doen als het altijd gaat om hetzelfde mass market product verhaal met zo'n .csv bestand... de developer verklaart tenslotte al bij het publiceren van de app dat die encryptie erin zit...
...ja inderdaad, ik haat dit soort onnodige bureaucratie

Wat zou de straf eigenlijk zijn als een willekeurige Henkie die gewoon een grappige app wil maken en er verder niet zoveel bij stil staat zoiets niet mailt naar de NSA?

Moet alle Android app bouwers die TLS gebruiken dat bij Google ook doen, ik ben er daar nog nooit op gewezen i.i.g...

[Reactie gewijzigd door Sfynx op 23 juli 2024 07:06]

[Armin]

Moet alle Android app bouwers die TLS gebruiken dat bij Google ook doen, ik ben er daar nog nooit op gewezen i.i.g...

Apple bedekt haar eigen gat wat beter. Immers, zo kan Apple in ieder geval zeggen dat ze het gevragd hebben. Microsoft vroeg het bijvoorbeeld ook niet.

[Bazi]

Helemaal mee eens! Het heeft mij ook heel wat zoekwerk gekost, en doorlezen van de juridische documenten hierover, om achter die uitzondering voor bijvoorbeeld https te komen. Tot voor kort zei Apple hier ook helemaal niets over, alleen de vraag 'gebruik je encryptie ja of nee'.

Sinds een paar weken is dat eindelijk verbeterd gelukkig, ze vermelden nu expliciet de uitzonderingen en een link voor de self-classification.

Nu is dat csv bestand wat je dan moet invullen ook een draak, want er is echt nergens te vinden hóe je dat precies moet invullen, ik heb het nog niet gevonden tenminste. Voor mij moet het komende januari voor het eerst gaan gebeuren, dus hopelijk is er tegen die tijd iets meer over te vinden.

[SPee]

En je kunt de app niet onder EU regelgeving uploaden?

[MrFax]

Nee, want Apple is een Amerikaans bedrijf, en die houdt zich liever aan hun eigen regelgeving. Het *kan* wel maar daar zou Apple zijn hele eco-systeem(alle apps gaan via Apple US) op moeten aanpassen.

[Reactie gewijzigd door MrFax op 23 juli 2024 07:06]

[xMuchux]

Dit is geen "willen", maar "moeten".

Het heeft allemaal te maken met EAR en als het over military producten gaat zelfs met ITAR. En lees vooral dat producten, hardware, software en technology (lees: kennis/informatie) kunnen zijn.

Op het moment dat we het hebben over een "American person", in dit geval Apple, (dit kan zijn daadwerklijk een persoon, maar ook een bedrijf) dan heeft deze te voldoen aan de EAR of ITAR. Zo niet? Dan kun je grote boetes verwachten of zelfs op de blacklist komen en je niets meer mag exporteren, zelfs buiten de VS als het over ITAR producten gaat.

Encryptie valt in dit geval onder EAR chapter 5 part 2 en zo kun je achterhalen of je een ECCN nummer raakt en een export licentie nodig hebt of niet. Want, ook hier weer ligt het er aan of je deze encryptie alleen gebruikt binnen 1 bepaald land (export naar bv NL) of dat je exporteert naar meerdere landen (export naar bv NL en dan weer herexporteerd naar Duitsland) en welke soort "technology" je wilt encrypten.

We hebben ook zo iets in Europa, maar dat zijn op het moment meer richtlijnen zo ver ik kan vinden.

Al met al is het een lastige zaak want ieder land heeft zo zijn eigen export controls en in EU zelfs Europese wetgeving wat de juridische zaak vaak (onnodig) complex maakt.

Ik kan hier nog wel een tijdje over doorgaan, maar als je meer wilt weten kun je de samenvatting op Wiki lezen.

[Reactie gewijzigd door xMuchux op 23 juli 2024 07:06]

[Darkstriker]

Bovendien zou Apple zich dan ineens aan veel meer Europese regelgeving moeten houden en die zijn natuurlijk veel strenger op privacy, verwerking van persoonsgegevens, consumentenbescherming etc. Op dat soort dingen zit Apple net zo min als Google te wachten

[Verwijderd]

Je suggereert nu dat Apple de Europese regelgevig overtreedt. Geef eens wat (onderbouwde) voorbeelden.

[Armin]

Zucht. Hoe zelfs. Dit is toch gewoon anti-privacy en anti-beveiliging?

Het hilarische is echter dat bescherming van de "privacy" een van de uitzonderingen was om geen ERN aan te hoeven vragen.

[BugBoy]

Waarom moeten alleen apps een ERN nummer hebben en wat is het doel hiervan?

[Lapa]

Waarom moeten alleen apps een ERN nummer hebben en wat is het doel hiervan?

Ik weet niet precies wat je daar mee bedoelt, maar deze regels zijn niet specifiek voor apps opgesteld. Het zijn juist regels die met name zijn opgesteld voor hardware, telecom apparatuur, enz. enz. Maar ze zijn bewust wel ruim genoeg opgesteld zodat software er ook onder valt, en daarmee ook apps.

Als je bedoelt, waarom wel apps en geen websites? Apps die je via de Apple App Store of Google Play distribueert, exporteer je juridisch gesproken vanuit de VS. De Microsoft Store kent deze regels bijvoorbeeld niet, omdat die ook vanuit Europa distribueert. Websites die zijn geen producten die je exporteert. Het is op een bepaalde manier een raar onderscheid, maar er zit wel een logica achter.

Als je bedoelt, waarom wel apps en geen andere software? Als je andere software vanuit de VS exporteert, gelden de regels net zo goed.

[Armin]

Je moet juist een ERN nummer aanvragen als je HTTPS/SSL gebruikt in een app helaas.

ERN's zijn zelden meer nodig. Uberhaupt was HTTPS/TLS al één van de uitzonderingen, maar sinds 2016 zijn ERN's uberhaupt al heel vaak niet meer nodig zelfs als je verder gaat dan HTTPS/TLS.

[Armin]

Je moet juist een ERN nummer aanvragen als je HTTPS/SSL gebruikt in een app helaas.

Zoals elders beschreven is dat niet meer waar. Dat was ook al vaak niet waar overigens, maar sinds 2016 is het expliciet uitgezonderd.

Daarvoor was het vaak al zo dat het viel onder de zogenaamde "Note 4" of "Mass Market" uitzondering.

[CAPSLOCK2000]

Eh... HTTPS?

Wat bedoel je?
HTTPS maakt toch ook gebruik van encryptie? Dat is toch net het hele punt?
In de VS heb je een vergunning nodig om crypto te exporteren en Apple eist dus dat apps met crypto zo'n vergunning aanvragen. Of die encryptie via HTTPS loopt of via een ander protocol lijkt me niet relevant.
Maar ik weet niet zo veel van iOS-apps. Mis ik iets?

[GekkePrutser]

Inderdaad, mijn idee met mijn app destijds was ook om https te gebruiken voor mijn API, immers https is in principe gewoon 'gratis' in je app (je hoeft alleen een andere functie call te doen). Heel simpel en het voegt heel veel veiligheid toe.

Maar, dan moet je weer moeilijk gaan doen met al dat juridische gezeur, toen was het gauw over.. Voor een gratis app ga ik daar geen tijd/geld in steken. Het ging ook niet om prive data (het was een soort browser van een publiek radionetwerk, de gebruiker voerde niets van prive data in, zelfs geen naam, callsign of login of wat dan ook) dus dan maar niet hoor... Heb er wel een uitgebreide pagina aan gewijd in het helpsysteem om uit te leggen wat er precies over de lijn ging.

Als je je eigen encryptie bouwt okee, daar kan ik me nog wat bij voorstellen (al ben ik het er ook niet mee eens, en is dat sowieso een heel slecht idee natuurlijk), maar voor het gewoon de ingebouwde https library aanroepen is het echt onzin. Die zogenaamde embargo landen kunnen de source code gewoon van Linux e.d. downloaden.

Het excuus van Apple is dat ze een Amerikaans bedrijf zijn, maar dat is Google ook en die heeft dit gezeur niet in hun play store. Tenminste, als je geen ERN aanvraagt dan kan je je app niet in embargo landen aanbieden (Noord-Korea, Iran enz) maar who cares.. Bij Apple moet je het altijd doen.

Zelf nooit een Android app gemaakt trouwens, maar dit haal ik uit hun help pagina hierover

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 07:06]

[BikkelZ]

Dat is niet waar, HTTPS hoort gewoon bij de standaard encryptie van je OS.

[GekkePrutser]

Toen ik de app maakte (2013 als ik het me goed herinner) moest dat wel degelijk. Ik heb het nog speciaal nagevraagd bij de developer support. Misschien nu niet meer zoals Bazi zegt, maar ik heb het niet meer bijgehouden. Het is heel erg lang zo geweest in elk geval.

[Bazi]

Sinds een jaar is dit ook een uitzondering, en hoeft dit niet meer als je gewoon HTTPS gebruikt. Alleen jaarlijks een mailtje sturen naar de NSA met een overzicht van je apps.

[BikkelZ]

Dat is al lang niet meer zo. HTTPS kun je gewoon gebruiken zowel binnen als buiten de VS:

https://stackoverflow.com...ryption/40919650#40919650

Dus tenzij je je eigen encryptiestack rolt hoef je helemaal niks.

[Bazi]

Als je alleen HTTPS gebruikt, en hiervoor gebruik maakt van de standaard iOS functies (dus niet zelf HTTPS communicatie gaat implementeren), dan is dit niet nodig. Dat is tegenwoordig een uitzondering.

Je moet alleen jaarlijks een mail sturen naar de NSA met een overzicht van je applicaties die hieronder vallen.

[xoniq]

Om geen HTTPS te gebruiken moet je al specifiek een regel aan de plist toevoegen, wat normaal gesproken gebruikt wordt voor development waar nog geen HTTPS beschikbaar is, het zijn dus ontwikkelaars die moedwillig HTTP gebruiken, kansloos.

[CAPSLOCK2000]

Geldt dat ook voor oudere apps? Ik vermoed dat dit een vrij recente ontwikkeling is en oudere apps wat tijd krijgen om zichzelf te vernieuwen. Goed van Apple dat ze het op deze manier doen, ik vind het een net compromis tussen developers de vrijheid geven en ze bijsturen om het juiste te doen.

[jabwd]

Dit geld inderdaad ook voor oudere apps. Oudere apps die niet geupdate zijn zullen simpelweg gewoon niet meer werken omdat het door het systeem geblokkeerd wordt.

Ik weet niet zeker of dit ook het geval is voor custom socket implementation, maar als je de Foundation API's gebruikt wat waarschijnlijk apps die toch al slecht zijn sowieso wel gebruiken ( NSURLSession etc. )

[xoniq]

Apple heeft al enige jaren het zo gemaakt dat je een aparte plist entry toe moet voegen om HTTPS te omzeilen. Dus men die HTTPS omzeilt, doet dat al jaren bewust.

[Sietse1990]

En als je klanten hebt waarvan het systeem niet op HTTPS te benaderen is en ze deze niet kunnen aanpassen? Als M.A.D. heb je niet altijd de keuze en daarom is deze regel er om toe te voegen. Beetje vreemd om dus de app ontwikkelaars kansloos te noemen terwijl ze geen invloed hebben op de API waarmee gecommuniceerd moet worden.

Begrijp me niet verkeerd, wij zijn bezig met een nieuwe versie van de applicaties die we hebben en we gaan meer eisen stellen waaronder dit er eentje is, maar dit wil wel zeggen dat een aantal klanten van ons de vernieuwde versie niet kunnen gaan gebruiken. Het verplicht stellen was voor ons een stok achter de deur als reden dat het niet kan, maar helaas hebben ze het weer eens uitgesteld.

[xoniq]

Vrijwel elke fatsoenlijke API kan gewoon via HTTPS communiceren. Als dat niet het geval is dan zou ik 't überhaupt laten liggen. En als je de API's zelf in 't beheer hebt, is bijvoorbeeld Let's Encrypt voldoende, gebruikt Tweakers ook, en is volledig gratis. Steeds meer online beheer panels bieden integratie met Let's Encrypt waardoor de drempels zelfs voor kleine partijen minder worden.

En kansloos vind ik het om elke gebruiker van je app potentieel in gevaar te brengen om de privacy, omdat de ontwikkelaar niet in staat is om het op de juiste manier te ontwikkelen. Ongeacht waar de schuld ligt.

Ik snap wel dat je soms afhankelijk kan zijn van een api die niet over HTTPS gaat, maar spoor dan de ontwikkelaar van de API aan om HTTPS aan te bieden, of loop weg.

[Plompie]

Als dat zou makkelijk en duidelijk is zou er ook een simpel slotje in de App store getoond kunnen worden. Dan weten gebruikers iig waar ze aan toe zijn en komt er weer een beetje meer druk op ontwikkelaars om het anders/beter te doen.

[xoniq]

Het kan zo makkelijk. Als je de App zonder die aanpassing test, krijg je in de console ook foutmeldingen dat een onveilige verbinding officieel niet meer toegestaan is vanuit een App, en dat het enkel te omzeilen is, wat geen gegarandeerde oplossing is.

Het is gewoon heel slecht om gebruikers een onveilige verbinding te laten gebruiken door onkunde van de ontwikkelaar. We leven nu in een tijd dat veiligheid online steeds belangrijker wordt, waarom dat verwaarlozen omdat het iets van moeite kost...

[memphis]

En om wat voor soort dataverkeer gaat het dan? Als het gewoon big data verzameling is noem ik dit soort nieuws iets van een contradictie... Data voor (bijna privacy) misbruik dat voor waarborg van privacy versleuteld moet worden...

[DigitalExorcist]

Google en FB gebruiken ook gewoon HTTPS op hun websites.... omdat je je data vrijwillig aan ze geeft om te delen, en niet om onderweg gejat te worden.

[CAPSLOCK2000]

En om wat voor soort dataverkeer gaat het dan? Als het gewoon big data verzameling is noem ik dit soort nieuws iets van een contradictie... Data voor (bijna privacy) misbruik dat voor waarborg van privacy versleuteld moet worden...

Zelfs als het gaat om bigdata sleepnetten en vrijwillige inleverpunten (social media) heb ik liever dat ze het versleutelen. Dat Facebook en de NSA alles van me willen weten is al erg genoeg, anderen hoeven niet mee te kijken zodat zij ook nog een keer mijn data kunnen stelen.

[Luinwethion]

Ja, bij een web browser zie je wat voor verbinding je gebruikt, met een app gaat dat niet zo snel.

Kan Apple (en Google en MS) hier nog wat aan doen? Is het redelijk om https te verplichten bij apps?

[Reactie gewijzigd door Luinwethion op 23 juli 2024 07:06]

[Crysania]

Https is al de standaard. Op iOS moet je specifiek als app bouwer http toestaan voor bepaalde urls (of alles via wildcards)

Het is dus echt de fout van de ontwikkelaars

[Stoelpoot]

In principe zullen Apple en Google specifiek een flag kunnen vereisen bij apps (wat Apple dus al doet) waarheen verbindingen kunnen worden gemaakt. Het zou fijn zijn als, wanneer een app HTTP-verbindingen gebruikt, daar een prominente waarschuwing voor bestaat in de app store.

[Horatius]

Tja het is niet goed maar welke apps? Aangezien het vgm niet uitmaakt of je netwerkverkeer van een kleine freemium game wel of niet encrypted is.

[Stoelpoot]

Freemium = Microtransactions = Geld = Inloggen = Bankgegevens = Transacties.

Dat zou ik niet op straat willen hebben liggen...

[Horatius]

Vgm gaan transacties via de apple store en krijgt apple er een deel van, ook de reden dat je geen spotify premium kan krijgen door de app. Dus dat zou veilig moeten zijn maar ik bedoel gewoon over nutteloze apps waar geen belangrijke informatie overheen gaat, bijv 9292 of flappy bird. Dit soort dingen hoeven echt niet encrypted te zijn imho dus als er al 30 van dit soort apps in de lijst staan tja.

[Stoelpoot]

9292 = Reisplanning = Heen en terug = Werktijden = Vakantietijden = Inbraaktijden?

He, kijk nou, elke vrijdag gaat Randomguy weg richting Groningen en komt zondag pas terug. Laten we eens kijken wat er zaterdagnacht in z'n huis te vinden is.

Of: Kijk nou, Randomguy heeft gezocht naar de dichtstbijzijnde coffeeshop toen hij in Amsterdam was. Wat zou z'n werkgever ervan vinden als dat openbaar komt?

[Horatius]

In mijn geval is 9292 geen probleem aangezien ik deze alleen gebruik om een bus te pakken en deze zo onregelmatig gebruik dat je er niks aan hebt, maar je hebt gelijk dat was een fout voorbeeld van mij.

[Peran]

Weet iemand hoe dit met Windows/UWP zit?

[Verwijderd]

Slordig van Apple. Het gaat niet om 1 app maar om 51 stuks.

[Sietse1990]

En hoezo slordig van Apple? Het zijn apps die niet van Apple zelf zijn, maar andere populaire apps.

[Verwijderd]

Apple controleert toch alles voordat het in de app store komt?

Apple fans gaat er toch altijd prat op dat apps uit de appstore zo veilig zijn in tegenstelling tot apps uit de Google Play winkel? Niet dus.

[mrcage]

Is de verantwoordelijkheid van de ontwikkkelaar. Apple heeft hier alleen guidelines voor.
On topic. Gebruik geen WiFi voor applicaties waar persoonlijke informatie wordt gebruikt.

[Sietse1990]

Apple controleert alle apps, maar niet alles van de apps, dat is ook niet de plaats van Apple. Dat de App Store veilig is, is niet waar en ken ook niemand die dit zo zou claimen. Of de App Store veiliger is, zal eerder de discussie worden. Ontwikkelaars kunnen er alsnog zooi instoppen die bijvoorbeeld op een later moment actief wordt.

Hetzelfde geld voor bijvoorbeeld websites. Is het het probleem van SIDN dat niet alle websites data via een beveiligde verbinding sturen? Of ligt dat toch echt aan de beheerders van de website?

Mijn punt is, je zegt dat het slordig is van Apple terwijl Apple wel degelijk een striktere (handmatige) controle uitvoert dan bijvoorbeeld Google. Als dit nieuwsbericht anders was en dat het over Android ging, had je dit dan ook slordig van Google gevonden? Want die controleren tegenwoordig ook de apps, maar ook hier zitten veel apps tussen die verbinding maken over HTTP. Die zijn dus even schuldig als Apple?

[BugBoy]

De apps in de Apple Store zijn veilig, omdat ze vooraf gecontroleerd zijn en dus geen malware/virussen bevatten. Ook is de iOS API wat beperkter, waardoor applicaties minder informatie kunnen vergaren. Die combinatie maakt het veiliger dan Android. De keerzijde is dat je ook minder kunt als applicatie, ondanks dat iOS steeds opener wordt.

[Verwijderd]

Kan je dat ook beargumenteren dat het niet veilig is? Nee dat je niet Nomen...

[BikkelZ]

• Je moet specifiek aangeven dat je applicatie HTTP in plaats van HTTPS gebruikt
• Eigenlijk zou vanaf 1 januari al verplicht moeten zijn maar veel developers konden nog niet van HTTP af en Apple heeft het uitgesteld
• HTTP is niet per definitie onveilig, net zoals we niet iedere string moeten encrypten omdat er wellicht een password in kan zitten