Google zegt dat tachtig procent van de Android-apps het dataverkeer versleutelt

Ongeveer tachtig procent van de Android-apps maakt momenteel volgens Google standaard gebruik van versleuteling bij het verzenden en ontvangen van data. Een jaar geleden was dat amper 25 procent.

Om het dataverkeer van een Android-toestel te beveiligen, kunnen ontwikkelaars hun apps voorzien van ondersteuning voor transport layer security. Volgens Google maakt op dit moment zo'n tachtig procent van de Android-apps gebruik van deze mogelijkheid. Het gaat om een aanzienlijke stijging: een jaar geleden werd het netwerkverkeer nog maar in een kwart van de gevallen met encryptie beveiligd, en tot mei 2018 vond er door apps zelfs helemaal geen versleuteling plaats.

Bij apps specifiek gemaakt voor Android 9 of 10 ligt de score nog hoger, met negentig procent apps die het netwerkverkeer standaard versleutelen. Volgens Google zal dat percentage nog stijgen. Sinds 1 november moeten alle nieuwe apps en appupdates namelijk minstens geschikt zijn voor Android 9. Eerder besloot Google al dat apps voor Android 9 standaard beschermd moeten worden door tls.

Nieuw in Android 10 is onder meer de ondersteuning van tls 1.3. Deze technologie zou beveiligde verbindingen mogelijk maken die tot veertig procent sneller zijn dan met tls 1.2.

Reacties (58)

[Trousercough]

Persoonlijk vind ik het groter nieuws dat schijnbaar 20% van de apps dit nog niet doet.

[gfgw]

Uit het artikel:

... tot mei 2018 vond er door apps zelfs helemaal geen versleuteling plaats.

@Trousercough

Persoonlijk vind ik het groter nieuws dat schijnbaar 20% van de apps dit nog niet doet.

In anderhalf jaar van 0 naar 80%, er zijn veranderingen die langer duren. Dus zo gek is het niet dat nog maar 20% van de apps dit nog niet doet.

[Ghxst]

Een developer van een app die voornamelijk lokaal wordt gebruikt en af en toe een paar GET requests maakt om een nieuws bericht of een paar foto's te laden heeft dan ook niet echt een overwegende rede om meer complexiteit en maintenance toe te voegen aan zijn hobby project waar hij of zij in zijn / haar vrije tijd aan werkt.

Begrijp me niet verkeerd, ik ben absoluut voorstander van HTTPS

[CH4OS]

Hangt van de selectie van de apps af. Zijn dat alleen apps voor nieuwe(re) Android versies, of letterlijk alle apps? Als het alle apps zijn, zijn er ook genoeg apps die intussen niet meer ontwikkeld worden, maar nog wel op de Play Store staan. Dan kun je je afvragen of die nog daadwerkelijk geüpdatet gaan worden, bijvoorbeeld.

[WoutervOorschot]

Je moet het anders zien, 20% heeft niet expliciet in een bestand in hun app aangegeven dat ze slechts versleuteld verkeer willen kunnen versturen en ontvangen.

Dan kunnen ze het alsnog gewoon allemaal versleuteld doen, daarom lijkt het nu ook alsof het allemaal pas wordt versleuteld sinds mei 2018, dat is waarschijnlijk eerder dat vanaf toen pas developers massaal api 28 (android 9) zijn gaan targetten, waar dit bestand verplicht is.

[junkchaser]

Vond ik ook! Lijkt me absoluut "not done" dat dit het geval is!

[erikdenv]

Ik gebruik een app die alle ATB-tochten in Nederland toont. De lijst wordt remote opgehaald. Waarom zouden die gegevens versleuteld verzonden moeten worden?

[xzenor]

Precies.. wachtwoorden en persoonlijke data moeten natuurlijk altijd via tls over het internet. Maar waarom zou je publieke data versleuteld op moeten halen? Als het kritische data is dan is het alsnog aan te raden want dan kan de data ook niet onderweg aangepast worden maar dat is vaak niet het geval.

Is het netter om alles via tls te doen? Uiteraard. Maar het is niet voor alles noodzakelijk,

[Yggdrasil]

Omdat de eindgebruiker dat onderscheid niet kan en zou hoeven maken. Tegenwoordig is een aanzienlijk deel van de data die je mobiele device communiceert privé, dus is het beter om standaard álles te versleutelen dan de developer de mogelijk te geven de verkeerde keuze te maken en daarmee per ongeluk privé data te laten uitlekken.

En omdat het web niet meer de vriendelijke buurt is die het vroeger was. Een app die publieke data inlaadt van een externe bron is kwetsbaarder voor manipulatie door een kwaadwillende. Door het injecteren of fuzzen van data in die stroom kunnen fouten in je app mogelijk misbruikt worden, wat een risico is voor de eindgebruiker. TLS zorgt niet alleen voor encryptie maar ook voor authenticatie van de server en bescherming tegen modificatie in-transit. De encryptie is dus bijzaak in dit geval maar als developer weten dat je data van de juiste server laadt is wel belangrijk.

[mitchken]

Idd, ik vermoed wel dat dit dan voornamelijk over kleine of minder gebruikte apps zal gaan.

[Keypunchie]

Op naar de 100!

Wel een kanttekening, dat de data versleutelt wordt, betekent alleen maar dat mensen "op hetzelfde netwerk" (technisch gezien, overal waar het verkeer langskomt), niet kunnen meelezen.

Het is prima mogelijk dat jouw gegevens in transport versleuteld op een server van een bedrijf terecht komen en dat ze vervolgens er allemaal privacy-schendende zaken mee doen.

Encryptie van verkeer is maar een deel van de oplossing voor het beschermen van privacy.

[japie06]

Is er een manier om te zien of een bepaalde app gebruik maakt van een versleutelde verbinding?

[Keypunchie]

Alleen indirecte manieren (dus dat je je netwerkverkeer gaat monitoren met een tool als wireshark)

[jozuf]

wireshark en consorten.
of dit op je geroote android zetten;
https://www.kali.org/kali-linux-nethunter/

[me23]

Een nadeel hiervan is dat je als klant dus niet meer kunt controleren welke data er nu precies wordt verstuurd.

Ik weet dus niet zo goed wat ik hiervan moet vinden.

[Ghxst]

Dit is niet helemaal waar, het kan nog steeds al is het wel wat moeilijker (al helemaal vanaf Android 7 en hoger).

Het alternatief van een onbeveiligde verbinding betekent niet alleen dat jij als gebruiker kan zien welke gegevens er verstuurd worden, maar ook dat mensen die kwaad willen jou gegevens kunnen inzien als je je ooit ergens met het wifi verbind bijvoorbeeld (tenzij je een goede VPN gebruikt).

[mitchken]

Op jouw device is deze data wel nog leesbaar en kan deze onderschept en gelezen worden.
Het idee van dit artikel lijkt me meer te zijn dat hetgeen je verzend veiliger is geworden om niet onderschept te worden. Wat verzonden wordt blijft dezelfde data maar enkel voor jou en de ontvanger leesbaar.

[RebelwaClue]

Op jouw device is deze data wel nog leesbaar en kan deze onderschept en gelezen worden.

Dit is gedeeltelijk waar. Stel ik weten wat app A allemaal verstuurt naar server A, dan kan ik dat alleen maar zien op het device zelf. Maar om te zien wat app A over de lijn gooit, heb ik een sniffer app nodig die (naar mijn weten) root toegang nodig heeft. Het verkeer tussen app A en server A is wel veiliger (in theorie) maar dit betekent ook dat het makkelijker is voor app A meer data te sturen dan ze claimen.

[Schway]

Ik denk niet dat er 9.332621544×10¹⁵⁷ apps nog zijn.

[blinchik]

Onlangs was ik bezig met het debuggen van een app en had ik een mitm proxy geinstalleerd, waarbij ik het certificaat als "trusted" had geinstalleerd.

Werkte prima voor de app waar ik het voor nodig had, maar ik was ook positief verbaasd dat de meeste apps ook aan certificaat controle doen (dus kijken of het het juiste certificaat is dat ze verwachten, en niet zomaar elk trusted certificaat aanvaarden). Whatsapp, eBay, .... wilden allemaal niet opstarten met via de mitm proxy!

[WoutervOorschot]

Gaat het dan om webrequests? Dan is het toch afhankelijk van de server (http/https) of het encrypted is? Het lijkt me sterk dat voor mei 2018 apps hun dataverkeer niet versleutelden, dat is toch iets wat al veel langer standaard is?

[Ghxst]

In voorgaande jaren was een niet beveiligde verbinding over HTTP vrij standaard voor de majority van apps die te vinden zijn in de store.

Google heeft steeds meer functies die tegenwoordig een HTTPS verbinding vereisen en het wordt voor developers steeds makkelijker om zelf een certificaat te installeren.

Goede vooruitgang.

[Devion]

TLS kan ook gebruikt worden m.b.t. diverse protocollen - o.a. UDP (DTLS) bijv.
Maar je zou idd verwachten dat iedereen tegenwoordig gewoon een letsencrypt cert pakt.

[CH4OS]

Als de server alleen HTTPS/TLS verbindingen accepteerd, moet de client wel de boel versleuteld weten te versturen; ze moeten de taal immers wel begrijpen, dat heb je in normale gesprekken ook, immers.

[WoutervOorschot]

Ja maar zelfs dan lijkt het me toch heel gek dat voor mei 2018 niks versleuteld zou zijn, je login session naar facebook bijvoorbeeld kan toch al jaren niet meer over http?

Ik weet in ieder geval heel zeker dat ik voor mei een app in de play store had die al de requests over https deed.

[CH4OS]

Ja maar zelfs dan lijkt het me toch heel gek dat voor mei 2018 niks versleuteld zou zijn, je login session naar facebook bijvoorbeeld kan toch al jaren niet meer over http?

Hangt van de 'secure' setting van het cookie af. Als die true is, dan wordt het cookie over HTTPS alleen geaccepteerd. De sessie ID is dan natuurlijk sowieso een hash, maar hoeft niet per se ook secure verzonden te zijn.

Ik weet in ieder geval heel zeker dat ik voor mei een app in de play store had die al de requests over https deed.

Hoe meer er over HTTPS/TLS gaat hoe beter.

[Yggdrasil]

Hangt van de 'secure' setting van het cookie af.

Maar ook van de configuratie van de server/applicatie. Facebook is een goed voorbeeld van een site die geen login toestaat via onversleutelde verbinding. Zelfs als je een non-secure sessiecookie zou hebben en je stuurt die naar een non-HTTPS login API van Facebook dan kom je er echt niet in. Je wordt geredirect naar de HTTPS-versie en moet opnieuw submitten. Ik denk dat @WoutervOorschot daarop doelt.

[Vetsmelter]

Wel, mocht een extern audit bureau of twee bevestigen dat alles wat ik doe op mijn Android telefoon ook versleuteld is van Google zelf dan zou dat een start van een mooi verhaal kunnen zijn.

[grrfield]

Het gaat hier enkel over "het verzenden" en "ontvangen" van data.

NB: de titel laat doorschijnen dat het allesomvattend is, maar volgens mij wordt alles wat versleuteld verstuurd wordt, ook versleuteld ontvangen. Het alternatief zou pas echt goed fout zijn . Het lijkt er verder op dat je data bij Google gewoon "veilig" is. I beg to differ.

[Vetsmelter]

Inderdaad, wat je intypt of inspreekt of op je schempje (in je gencrypteerde email // messenger app) leest wordt door Google & Partners reeds onderschept en eeuwig bewaard vooraleer het versleuteld verzonden wordt door één van die 80% apps met versleutelde gegegevensuitwisseling naar hun server / peers.

Dat Google alles per default onderschept is een aanname die we verplicht zijn te maken -in het kader van discussie beveiliging/ versleuteling- vooraleer het tegendeel is bewezen.

Dit artikel over een deelfacet zou kunnen de indruk wekken alsof we dra op de beide oren kunnen slapen mbt tot databeveiliging (economische strategieën, ontwerpen, ..je liefdesleven en al dat andere dat je al lang niet meer te verbergen hebt). We'd beg to differ indeed, sir.

[Naafkap]

Ik ben benieuwd hoe dit getal bij iOS ligt. Iemand daar cijfers van?

[Milt]

Apple wilde het verplicht gaan stellen maar heeft daar later toch vanaf gezien. Waarschijnlijk omdat nog maar weinig developers er gehoor aan hadden gegeven. Helaas lijkt de situatie niet echt verbetert zoals blijkt uit deze steekproef onder 30.000+ apps. Slechts 27% gebruikt App Transport Security (ATS), oftewel SSL/TLS.

[Yggdrasil]

Dat is echter maar een deel van het verhaal. Uit het artikel:

but acknowledged that disabled ATS does not necessarily mean all communications are unencrypted. “It just means that system safeguards are disabled and hence there is much more room for error.”

Het is dus mogelijk dat apps TLS gebruiken zonder dat via ATS kenbaar te maken. Toch zou ik heel graag zien dat dit verplicht wordt.

Volgens het artikel is de grootste hindernis dat vooral advertentie-netwerken nog niet altijd HTTPS gebruiken, waardoor developers het, onder druk van tijd en budget, maar helemaal uitschakelen i.p.v. uitzonderingen te definiëren voor die domeinen.

[418O2]

100% denk ik, volgens mij is dat verplicht voor iOS Apps

[Aaargh!]

tot mei 2018 vond er door apps zelfs helemaal geen versleuteling plaats.

Dit is natuurlijk niet correct, en dat staat ook niet in het gelinkte artikel. Zou wel raar zijn als er voor mei 2018 geen enkele Android app gebruik maakte van HTTPS.

Het gaat hier om het expliciet niet toestaan van onversleutelde verbindingen door een setting op te nemen in het manifest van een applicatie. Als je dit doet van worden alle onversleutelde verbindingen automatisch tegengehouden door de Android runtime. Dit is natuurlijk iets totaal anders dan dat apps geen versleutelde verbindingen gebruikten, zat apps die dat wel deden.

[Dreamvoid]

Encryptie is goed, maar idd als iemand halverwege de sleutel ook heeft dan word je er alsnog niet echt wijzer van.

[mjz2cool]

Dan heb je de encryptie niet goed voor elkaar, en moet je een nieuwe sleutel generen.

[Dreamvoid]

In principe wel, maar een app moet je ook maar vertrouwen - die kan de sleutel uiteindelijk gewoon naar zijn moederbedrijf sturen, daar heb je als gebruiker geen controle over. Dit soort versleuteld verkeer geeft je idd beveiliging tegen random mensen die je verkeer langs zien komen, maar wat de app zelf doet is uiteindelijk een black box.

[mjz2cool]

Maar dat bedrijf kan sowieso al de data wel lezen, het gaat hier om het dataverkeer wat wordt versleuteld met tls, de versleuteling van de data zelf staat hier los van.

[Ghxst]

Dit is alleen een probleem wanneer je device compromised is.

Als dat het geval is dan heb je grotere problemen.

[Dreamvoid]

Nee hoor dat hoeft niet - dit kan ook gewoon 'by design' zijn in de applicatie zelf.

[Ghxst]

Uiteraard had mijn comment betrekking op versleutelde data verbinding via TLS zoals vermeld in het artikel

[CH4OS]

Dit is alleen een probleem wanneer je device compromised is.

Helaas, er bestaat ook zoiets als een 'man in the middle attack', een tussenpartij die ook de private key heeft en de berichten dus gewoon kan ontsleutelen. Echter kun je er dan wel vanuit gaan dat er dan dingen gebeuren die je eigenlijk niet wilt.

[Reactie gewijzigd door CH4OS op 23 juli 2024 11:55]

[Ghxst]

Hoe verkrijgt deze "man in the middle" dan precies de private key?

In dit geval zou het bedrijf deze vrij moeten geven en dat is eigenlijk het zelfde als toegang geven tot je back-end, en in dat geval is een MITM overbodig.

[CH4OS]

Hoe verkrijgt deze "man in the middle" dan precies de private key?

In dit geval zou het bedrijf deze vrij moeten geven en dat is eigenlijk het zelfde als toegang geven tot je back-end, en in dat geval is een MITM overbodig.

Man in the Middle is meer het principe, er zijn meer mogelijkheden waarop een je een dergelijke aanval kan doen. Verdiep jezelf daarom even in de materie.

Een private key (meestal simpelweg een file) kan natuurlijk op verschillende manieren lekken, dat hoeft niet alleen als iemand abusievelijk toegang is gegeven tot de back-end. Sterker nog, de back-end kan maar zo achter een constructie zitten dat de back-end niet eens zelf de HTTPS afhandeld, maar dat een terminator dat doet, bijvoorbeeld via een (reverse) proxy of de loadbalancer..

Een andere manier is via DNS; je laat dan de DNS-server een ander IP-adres aan een domein koppelen zodat het eerst naar malafide (proxy)server Y gaat, die op zijn beurt naar het juiste domein gaat. Maar doordat de client met server Y praat en een valide certificate chain teruggeeft, zul je ook gewoon een groen slotje zien, de client weet immers niet beter dan dat het goed is. Er zijn dus meerdere manieren hiervoor mogelijk om een man in the middle attack te bewerkstelligen.

MITM-attacks vaker voor dan je denkt:
nieuws: Man-in-the-middle-aanval treft Fox-IT
nieuws: 'Outlook.com-gebruikers in China kampten met mitm-aanval'
nieuws: Ongepatcht lek in QNAP-firmware laat mitm-aanvaller nas-apparaten ove...
nieuws: Nieuwe man-in-the-middle-aanval voor Windows blootgelegd
nieuws: Isp's Kazachstan moeten https-verkeer onderscheppen op last van overheid - Er worden zelfs ISP's verplicht om dat te doen!

Dus nee, Man in the Middle attacks behelzen meer dan jij denkt. De hack bij Diginotar had ook MITM attacks zelfs kunnen betekenen en dan had je het niet eens gezien en gewoon geloofd, omdat de certificate chain dan gewoon op orde was geweest (en je dus zelfs een prima groene HTTPS verbinding op kan zetten), alleen een totaal andere partij zou dan het certificaat hebben ondertekend. Gelukkig is dat teniet gedaan door de hele certificate authority de das om te doen.

[Reactie gewijzigd door CH4OS op 23 juli 2024 11:55]

[Ghxst]

Tenzij de server of de CA compromised is ga jij niet in het bezit komen van de private key die nodig is om versleutelde data te ontsleutelen.

Is dat niet het geval en voer je bijvoorbeeld een aanval uit via DNS om zo de data te ontvangen die eigenlijk bedoeld is voor de legitieme server, dan zit je als nog met het probleem dat de traffic die binnen komt versleuteld is met een public key waar jij niet de bijhorende private key van hebt.

Wil je gebruik maken van een local CA, zodat je wel in bezit bent van de private key, dan zit je met het probleem dat de client deze CA dus niet kent en de certificaten niet in bezit heeft om de data te versleutelen.

Daarnaast, omdat deze publieke keys bekend zijn, kun je als developer ook kiezen om te checken of de public key van het door de server aangeboden certificaat eigenlijk wel klopt, ook al is de certifcate store van de client dan compromised, dan kan de app of service nog steeds aangeven dat er iets niet klopt en geen data versturen.
Op die manier is onder andere de hack bij diginota aan het licht gekomen, chrome gaf/geeft voor belangriijke domeinen niet "maarzo een groen slotje omdat alles lijkt te kloppen".

[CH4OS]

Tenzij de server of de CA compromised is ga jij niet in het bezit komen van de private key die nodig is om versleutelde data te ontsleutelen.

Nogmaals, het is een file, er zijn dus meerdere manieren waarop een file kan lekken, stommiteit van de beheerder, een lek in een package waardoor toegang tot het filesysteem kan worden verkregen, een remote code execution lek, ik noem even wat dingen...

Is dat niet het geval en voer je bijvoorbeeld een aanval uit via DNS om zo de data te ontvangen die eigenlijk bedoeld is voor de legitieme server, dan zit je als nog met het probleem dat de traffic die binnen komt versleuteld is met een public key waar jij niet de bijhorende private key van hebt.

Nee, je zit dan als soort proxyserver er tussen. De client weet niet van de proxy, accepteert dan die versleuteling en de proxy haalt de data op bij de doelserver, via een andere encrypted connectie.

Wil je gebruik maken van een local CA, zodat je wel in bezit bent van de private key, dan zit je met het probleem dat de client deze CA dus niet kent en de certificaten niet in bezit heeft om de data te versleutelen.

Er hoeft niet eens een local CA benodigd te zijn en zoals in Kazachstan, kun je natuurlijk ook eerst het root certificaat van de local CA installeren op de client, dan verdwijnt de foutmelding als sneeuw voor de zon.

[Reactie gewijzigd door CH4OS op 23 juli 2024 11:55]

[Ghxst]

> Nogmaals, het is een file, er zijn dus meerdere manieren waarop een file kan lekken, stommiteit van de beheerder, een lek in een package waardoor toegang tot het filesysteem kan worden verkregen, een remote code execution lek, ik noem even wat dingen...

Juist, zoals ik zei, dan is de server dus compromised.

> Nee, je zit dan als soort proxyserver er tussen. De client weet niet van de proxy, accepteert dan die versleuteling en de proxy haalt de data op bij de doelserver, via een andere encrypted connectie.

Dit werkt dus alleen als de cliënt de CA accepteert die jou server gebruikt.

> Er hoeft niet eens een local CA benodigd te zijn en zoals in Kazachstan, kun je natuurlijk ook eerst het root certificaat van de local CA installeren op de client, dan verdwijnt de foutmelding als sneeuw voor de zon.

In Kazachstan heeft iedereen dus ook een certificaat moeten installeren tot dat de CA die gebruikt werd door de meeste bedrijven ingebakken werden.

En daarnaast, lees je eigen even in over de hoeveelheid problemen Kazachstan wel niet heeft gehad met grote services die gewoon simpelweg niet meer werkte omdat public key pinning werd gebruikt.

Ik voer deze aanvallen wekelijks uit omdat het onderdeel van mijn werk is

[Reactie gewijzigd door Ghxst op 23 juli 2024 11:55]

[CH4OS]

Juist, zoals ik zei, dan is de server dus compromised.

Ja, maar hoeft niet per definitie de back-end open en bloot te staan.

Dit werkt dus alleen als de cliënt de CA accepteert die jou server gebruikt.

Klopt, maar hoeft dus geen local CA te zijn, maakt het wel gemakkelijker. Alleen moet je dan clientside zorgen dat het root certificaat geinstalleerd wordt.

In Kazachstan heeft iedereen dus ook een certificaat moeten installeren tot dat de CA die gebruikt werd door de meeste bedrijven ingebakken werden.

Klopt, maar dat staat ook in het artikel dat ik reeds gelinkt heb.

En daarnaast, lees je eigen even in over de hoeveelheid problemen Kazachstan wel niet heeft gehad met grote services die gewoon simpelweg niet meer werkte omdat public key pinning werd gebruikt.

HPKP is intussen inderdaad ook al achterhaald en word steeds meer uitgefaseerd.

[memphis]

Ik snap de veiligheidsredenen maar de apps die dit al vanaf het begin deden, kunnen die dan iets te verbergen hebben? Dan noem ik onwettig gehamsterde data.

[Keypunchie]

Ik snap de veiligheidsredenen maar de apps die dit al vanaf het begin deden, kunnen die dan iets te verbergen hebben?

Heb jij iets te verbergen als je je post in een envelop verstuurd?

Want dat is TLS in principe, een envelop die je data "verbergt" voor iedere postbode- en sorteerder op de route, in de analogie netwerkbeheerders en -providers.

Antwoord is dus nee: Degenen die dit al deden hadden ontwikkelaars die gewoon uit zichzelf wat privacy- en beveiligingsbewuster waren dan de rest.

[sys64738]

Alleen hier ben jij niet degene die de envelop vult. De app bepaalt wat hij in de envelop stopt en je kunt het niet controleren want hij likt hem al dicht voordat jij ziet dat de envelop op de bus gaat.

De meeste apps zullen netjes data versturen die nodig is om te doen wat jij wilt doen en niet meer dan dat. Maar als een bad app besluit jouw locatie of foto's mee te sturen, kun je dat niet detecteren.

[Keypunchie]

Ik snap waar de analogie misgaat en je punt. Overigens kun je daar in een gecontroleerde omgeving nog wel wat mee doen (praktisch alle apps gebruiken de OS-functionaliteiten, dus je kunt de enveloplikker aanpassen ;-)).

Maar vertrouwen in een app zul je nooit alleen met de techniek moeten doen.

Ik heb liever software van een partij die ik vertrouw, die ik niet 100% kan controleren, dan software van een partij die ik *niet* vertrouw en 100% moet controleren.

En als Apple-gebruiker heb ik ook nog ‘app review’ als buffer tussen mij en slechtwillende apps, voor wat het waard is

[Reactie gewijzigd door Keypunchie op 23 juli 2024 11:55]

[mitchken]

Het enige dat deze verbergen is jouw data voor derde partijen onderweg.
Zodoende zullen al deze apps nog hetzelfde doorsturen, alleen zal er onderweg niemand kunnen meelezen met de inhoud zoals wachtwoorden, tokens, ...

[Yggdrasil]

Nee, dat is een omgekeerde beredenering. Apps hebben zich ook in het verleden niet laten tegenhouden door wel of geen encryptie. Zat voorbeelden van apps die teveel data verzamelden én die onversleuteld verstuurden naar een server. Dat een app wél TLS gebruikt zegt dus niks over de inhoud van de data.

[Verwijderd]

Dus dat wilt zeggen dat android even veilig is als ios? Of hoe moet ik dat zien kwa versleutelde verbindingen

[Yggdrasil]

Helaas is het op iOS niet zo geweldig gesteld als ik verwacht had. Apple heeft App Transport Security (ATP) optioneel gemaakt ondanks eerdere plannen om het verplicht te stellen. Uit dat onderzoek blijkt 68% geen ATP te gebruiken. Developers kunnen buiten ATP om nog wel TLS gebruiken maar dat is niet makkelijk te meten. Blijkbaar ondersteunen diverse advertentie-netwerken nog geen HTTPS dus kiezen met name gratis apps ervoor om het uit te schakelen. ATP blijkt ook wat complex te zijn wat natuurlijk niet helpt.

Naar mijn idee wordt het inmiddels hoog tijd dat Apple TLS gewoon verplicht stelt en de advertentie markt dwingt om te moderniseren.

[wimdebok]

Spyware met versleuteld verkeer?