Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Proton waarschuwt voor iOS 13.4-bug die ip-adres vpn-gebruikers kan vrijgeven

ProtonVPN heeft een kwetsbaarheid aangetroffen in iOS 13.3.1 en 13.4 die maakt dat vpn-verbindingen onder omstandigheden minder veilig zijn. Onder andere kunnen ip-adressen van gebruikers inzichtelijk worden.

ProtonVPN beschrijft dat een communitylid ontdekte dat iOS in versie 13.3.1 bij vpn-gebruik geen bestaande verbindingen sluit, een bug die ook in 13.4 blijkt te zitten en waar nog geen patch voor is. Voor de meeste verbindingen zal dat volgens ProtonVPN geen problemen opleveren, omdat die van korte duur zijn en uiteindelijk wel via de vpn-tunnel opgezet worden. Maar sommige verbindingen kunnen uren open blijven staan buiten de vpn-tunnel om, is de waarschuwing.

Het Zwitserse bedrijf geeft als voorbeeld het pushsysteem voor notificaties van iOS. "Maar het probleem kan elke app of dienst treffen, zoals applicaties voor instant messaging of webbeacons." De meeste verbindingen zijn tegenwoordig hoe dan ook versleuteld, maar wel kunnen servers in die omstandigheden het ip-adres van de gebruiker in plaats van die van de vpn-dienst inzien. Met name voor gebruikers in landen met repressieve regimes kan dat problemen voor gebruikers opleveren, aldus Proton.

Bovendien kunnen vpn-aanbieders het probleem niet rechtstreeks omzeilen, omdat iOS niet toestaat dat derde partijen verbindingen afsluiten. Wel heeft het bedrijf een workaround ontdekt, waarbij gebruikers verbinding moeten maken met de vpn en vervolgens de vliegtuigmodus in en uit moeten schakelen. De dienst kan niet garanderen dat dit het probleem volledig verhelpt.

iOS ProtonVPN Wireshark

Door Olaf van Miltenburg

Nieuwscoördinator

27-03-2020 • 11:19

55 Linkedin

Submitter: juliank

Reacties (55)

Wijzig sortering
Ik denk, dat de work around, niet een veilige oplossing is.
Door je netwerk uit en aan te zetten. Zullen bestaande connecties verbreken.
Maar als het het weer aanzet, zul je een wedstrijdje hebben, wie het eerste verbind.
Is het de VPN, die de routes default via de tunnel laat gaan.. Of is het een app, die sneller was met zijn verbinding op te zetten via de normale route?

[Reactie gewijzigd door wica op 27 maart 2020 12:48]

Ligt aan de config denk ik. Ik ben ook benieuwd of dit alleen met handmatig verbinden het geval is, of ook met always-on. Mijn iPhone is dusdanig ingesteld dat zodra hij het thuisnetwerk verlaat er geen internetverbindingen toegestaan wordt totdat de VPN verbinding tot stand komt, dat is een feature van iOS zelf die dit regelt. Ben benieuwd of er dan toch verbindingen open kunnen blijven staan, zou wel heel raar zijn.

Protongebruikers zullen gok ik vaker handmatig de VPN aan en uitzetten.


-edit- Ah, dit staat ook beschreven bij het artikel van Proton zelf:
Alternatively, Apple recommends using Always-on VPN to mitigate this issue. This method requires using device management, so unfortunately it doesn’t mitigate the issue for third-party applications such as ProtonVPN.
Mooi. :)

[Reactie gewijzigd door WhatsappHack op 27 maart 2020 12:31]

Mijn iPhone is dusdanig ingesteld dat zodra hij het thuisnetwerk verlaat er geen internetverbindingen toegestaan wordt totdat de VPN verbinding tot stand komt, dat is een feature van iOS zelf die dit regelt.
Ben wel benieuwd hoe je dit ingesteld hebt; ik zie daar niet standaard iets voor aanwezig of instelbaar op mijn iPhone. Alvast dank voor de toelichting.
Je moet een profiel maken en dan naar je iPhone sturen. Zie dit topic:
[iOS] Always on VPN

Daar vind je achtergrondinformatie en verschillende voorbeeldprofielen. :)

-edit-
Voor mensen die gewoon meteen de profielen willen hebben:
L2TP: https://gathering.tweaker...message/57122641#57122641
IKEv2: https://gathering.tweaker...message/59552130#59552130

[Reactie gewijzigd door WhatsappHack op 27 maart 2020 14:49]

Ik gebruik zelf passepartout als App waarin je dit met een switch kunt inschakelen en ook WiFi netwerken op een ‘safe’-list Kunt plaatsen. Deze heeft ook ondersteuning voor ProtonVPN en NordVPN, hoewel ik het zelf gebruik i.c.m. OpenVPN.

[Reactie gewijzigd door mrdemc op 29 maart 2020 04:19]

Goede tip voor OpenVPN gebruikers inderdaad :) Sowieso een mooie app zo te zien, nice. :)
Ik ben zelf niet zo'n fan van OpenVPN, IKEv2 all the way. :P ProtonVPN ondersteunt beiden protcollen trouwens.

Maar er is wel iets om rekening mee te houden: ik gok dat met deze app het probleem ook niet opgelost is, omdat de app handmatig de verbinding in/uitschakelt in plaats van dat iOS het zelf afhandelt. (En om ProtonVPN's blog te herhalen: "so unfortunately it doesn’t mitigate the issue for third-party applications such as ProtonVPN.") Alleen wordt OpenVPN niet standaard ondersteund, dus ik denk ook niet dat het mogelijk is om werkelijk "Always-On" te bewerkstelligen voor OpenVPN via die app noch op OS niveau. Althans: niet op de diepte waarmee iOS het zelf doet waarbij iOS dus zelf alle uitgaande verkeer blokkeert tot de VPN-verbinding tot stand gekomen is - en Proton's blog lijkt dat te bevestigen. Dus apps als ProtonVPN, OpenVPN, Passepartout, WireGuard, etc.: noem het maar op - die hebben allemaal te maken met dit probleem. Maar correct me if I'm wrong.

[Reactie gewijzigd door WhatsappHack op 27 maart 2020 18:37]

De App ondersteunt meerdere providers en soorten, waaronder dus Proton.
M.b.t. de always-on optie heb je gelijk, ik heb het net uitgeprobeerd en tussen het schakelen van een vertrouwd WiFi naar 4G had ik voor een seconde het IP-adres van 4G. Bij het altijd ingeschakeld houden van de VPN, dus ook op WiFi, lijkt de internetverbinding wel verbroken in de tussentijd.

[Reactie gewijzigd door mrdemc op 29 maart 2020 04:19]

Ik hou niet van het OpenVPN-protocol. ;) Wat traag, wordt nergens standaard ondersteund (altijd een extra app nodig) en niet de beste stabiliteit eigenlijk. IKEv2 daarentegen wordt door alle besturingssystemen standaard ondersteund, werkt daarmee ook op alle devices perfect met Always-ON, is snel en extreem stabiel: zelfs onder wisselende omstandigheden zoals slechte WiFi, wisselen tussen 4G en WiFi, et cetera blijft de tunnel overeind, het is bestand tegen korte onderbrekingen en houdt zelfs even je verbindingen open tot je je sessie hervat zodat je apps niet eens weten dat je even offline bent gegaan/gewisseld hebt tussen een netwerk. Als je het eenmaal hebt gebruikt wil je niet meer terug naar OpenVPN hehe. :P
Ik zal het eens uitproberen, klinkt heel prettig werkend in ieder geval, bedankt.

[Reactie gewijzigd door mrdemc op 28 maart 2020 15:14]

Dikke dank voor de info!
Is het de VPN, die de routes default via de tunnel laat gaan..
Ja, als het goed is wordt alles naar de vpn tunnel geroute. De data hoopt zich op bij de vpn tunnel totdat deze tot stand is gebracht en er dus data overgebracht kan worden. Er hoort dus geen data naar buiten te lekken buiten de VPN-tunnel om.

Eigenlijk is het dus gewoon een manier om de gebruiker alle connecties te laten force-closen omdat ios dit blijkbaar niet goed doet wanneer een vpn tunnel wordt gestart.

[Reactie gewijzigd door pietprecies01 op 27 maart 2020 12:30]

Ik heb geen idee hoe iOS met zijn netwerk omgaat.
Maar als ik op mijn Linux computer het netwerk uitzet, verwijderd die netjes alle routes. Dit is ook mijn verwachting.
Zet ik mijn netwerk weer aan, dan komen eerst de routes van mijn eigen netwerk binnen, en pas wanneer ik mijn VPN een schopje geeft (of na het automatisch verbinden). Krijg mijn computer de routes van de VPN.

Het kan ook niet anders. Daar de VPN via je normale netwerk naar buiten moet.

Zoals jij het stelt, zou de VPN verbinding, via zijn eigen VPN verbinding naar buiten moeten gaan.

[Reactie gewijzigd door wica op 27 maart 2020 12:50]

Weet alleen dit in mijn testing openvpn deze optie in ios biedt en deze werkt, maar weet niet hoe de standaard vpn client van ios en andere clients er mee omgaan
Ik vind het vooral een probleem dat bij in verhouding zoiets simpels , er een ander bedrijf achter moet komen in de praktijk.

Dat laat vragen open hoe test men dan updates daadwerkelijk, secuur en goed genoeg?

Of zit er een deel bij of in of restant van iets wat nu voorheen of toekomst zo gewild is , en een fout in die implicatie aanpassing of update hiervan. Veel giswerk als maar toch , na een update test je toch ook diverse communicatie en settings lijkt mij APPEL?

Vraag kan men een verborgen "bridge" achtig iets inbouwen andere ip range virtueel adapter enz , zonder dat men dit dan kan zien met zaken als Wireshark en co?

[Reactie gewijzigd door jahoorisieweer op 27 maart 2020 13:31]

Nu weet ik niet de veiligheid binnen iOS, maar kunnen apps/notificaties/etc niet bij de informatie van het netwerk van het eigen IP adres? Zegmaar de inconfig info van Windows (deel wat zegmaar voor de VPN zit). Dat geval kan een app toch gewoon die data 'via de VPN' sturen naar servers, waar zit dan precies de veiligheid daarin?
Daar gaat het niet om. Het gaat er om dat iemand die op het netwerk meeluistert (overheid / hacker die een publiek wifi netwerkje heeft opgezet, etc.) kan zien wie met wie communiceert. Dat is waarom je een VPN tunnel gebruikt.

En blijkbaar is het nu dus zo dat zelfs al zet je VPN aan, dat bestaande connecties, zo lang die open blijven, nog buiten de tunnel om lopen en dus zichtbaar zijn.
Precies, en voor de huis tuin en keuken gebruiker is dat misschien vervelend. Alleen voor bedrijven of overheden (Bijv. alle Rijksambtenaren) die gebruik maken van iOS devices met VPN is het een ander verhaal.
Ik ga ervan uit dat dat het lokale adres is, en niet het externe adres en het dus geen probleem oplevert (alhoewel dat voor ipv6 natuurlijk anders zit, maar dat terzijde)

[Reactie gewijzigd door pietprecies01 op 27 maart 2020 11:36]

Voor ipv6 is het niets anders. Het enige verschil is dat er meer (veel meer) adressen beschikbaar zijn.
Als je via wifi verbonden bent zit je achter een router die zelf ipadressen uitdeelt (ipv4 of v6), en die zit weer achter een modem, waar de router zijn externe ipadres van heeft.
Als je via je mobiele data verbonden bent ben je verbonden via een interne modem, dus het ipadres wat je telefoon dan heeft is het externe ipadres.
Voor ipv6 is het niets anders. Het enige verschil is dat er meer (veel meer) adressen beschikbaar zijn.
Dan moet je jezelf even inlezen in ipv6.
De eerste X aantal bits van het ipv6 adres van een apparaat is voor het huishouden hetzetlfde. Dit komt omdat we in tegenstelling tot ipv4 niet meer NAT gebruiken, maar we elk apparaat een uniek ipv6 adres geven. Waar vroeger je huis 1 ipv4 adres kreeg wat dan met NAT over meer lokale ip-adressen werdt verdeeld krijgt je tegenwoordig een blok van ipv6 adressen (bij kpn is dit wat ik kan vinden een /48 blok, wat beketent dat je 2^80 = 1.2×10^24 unieke adressen hebt) die je over de apparaten mag verdelen.
Hierdoor kan aan de hand van het ipv6 adres van het apparaat een goede inschatting worden gemaakt van waar het apparaat zich bevindt als ze aan het ipv6 address van de network interface kunnen komen (wat een lokaal programma zou kunnen).

Je kan dit ook zelf zien door op twee verschillende apparaten naar zo'n "wat is mijn ip" site te gaan en te zien dat je verschillende waardes ziet, maar dat het begin ervan overeen komt.

[Reactie gewijzigd door pietprecies01 op 27 maart 2020 13:55]

... inconfig ...
Je bedoelt ‘ifconfig’ ;)
Hij noemt Windows, dus het is "ipconfig"

Op Linux zou je liever zijn opvolger "ip" gebruiken.

[Reactie gewijzigd door ItsNotRudy op 27 maart 2020 11:53]

Was het niet ipconfig in Windows ?
Je bedoelt ‘ifconfig’ ;)
Found the debian user!
Mijn voorkeur gaat naar "ip a" en "ip r". Het is trouwens voor vrijwel elke distro hetzelfde.

[Reactie gewijzigd door mjz2cool op 27 maart 2020 12:29]

Interessant dat je voorkeur dezelfde manier is die vrijwel iedereen gebruikt voor interface beheer. De meeste distro's hebben geen ondersteuning meer voor ifconfig. Alleen de LTS versies zoals debian hebben het er nog in... De grap was dus dat ik de debian user kan vinden omdat hij als enige ifconfig nog herkent......

[Reactie gewijzigd door jokey99 op 27 maart 2020 12:53]

De meeste distros kunnen het nog ondersteunen, aldanniet met een extra pakket. Ik installeer standaard gewoon net-tools op CentOS 7+, daar zit ifconfig ook in. ;) Zelfde voor semanage om een voorbeeld te noemen. En nog steeds vaak dat ik "service" intik in plaats van het direct via systemctl te laten lopen... Ik ken de andere of nieuwe commando's wel, maar om de een of andere reden vind ik het prettiger werken en blijkt het best hardnekkig in m'n routines te zitten. :P Al is 't ook een stukje gemak en luiheid hoor, als je de pakketten niet installeert of oude commando's stopt te gebruiken dan ga je vanzelf over met je routine.

[Reactie gewijzigd door WhatsappHack op 27 maart 2020 14:27]

Bovendien kunnen vpn-aanbieders het probleem niet rechtstreeks omzeilen, omdat iOS niet toestaat dat derde partijen verbindingen afsluiten. Wel heeft het bedrijf een workaround ontdekt, waarbij gebruikers verbinding moeten maken met de vpn en vervolgens de vliegtuigmodus uit en in moeten schakelen. De dienst kan niet garanderen dat dit het probleem volledig verhelpt.

T is dus een feature en geen bug
daarnaast, in vliegtuigmodes.. dan zou je toch helemaal geen verbinding moeten hebben?
Wat is de feature hier dan? ik zie alleen een bug.
Met het uit- en inschakelen van de vliegtuigmodus verbreek je alle bestaande verbindingen. Vervolgens worden deze na het inschakelen opnieuw opgezet via de vpn tunnel die ook meteen actief is.
Maar moet het dan niet in en uitschakelen zijn?
Iets lijkt me pas een feature als het de geplande bedoeling is wat er in de praktijk gebeurt. Daar lijkt hier geen sprake van te zijn om de volgende redenen:

Als je met een VPN verbinding maakt is het principe dat je bepaalde gegevens, zoals je IP-adres, niet prijs geeft.
Dat een derde partij geen verbinding kan afsluiten maakt niet dat het dus de bedoeling is dat het IP-adres wel inzichtelijk kan worden.
Uit niets blijkt dat het de bedoeling is dat het IP-adres inzichtelijk zou moeten worden.
Volgens mij heb je gelijk. Android en iOS hebben dit, naar mijn weten, altijd al zo gedaan. De rationale is - denk ik - dat je niet wil dan een VPN verbinding bestaande verbindingen onderbreekt. Iets dat voor de gebruiker een vervelende ervaring kan opleveren.

Bedenk bijvoorbeeld dat je iets aan het downloaden bent. Opeens besluit een andere app het bedrijfsintranet aan te spreken waardoor het on-demand VPN vanzelf verbind. Je wil niet dat dat de download daardoor onderbreekt.

De enige use-case waar je het andersom wil hebben zijn privacy-VPN's. En hoewel die wel in populariteit stijgen is dan volgens mij nog altijd niet de voornaamste use-case voor VPN on mobiel/tablet. Maar precies bij deze use-case wil je eigenlijk een always-on VPN, waar het probleem sowieso niet optreed.
Bovendien kunnen vpn-aanbieders het probleem niet rechtstreeks omzeilen, omdat iOS niet toestaat dat derde partijen verbindingen afsluiten. Wel heeft het bedrijf een workaround ontdekt, waarbij gebruikers verbinding moeten maken met de vpn en vervolgens de vliegtuigmodus uit en in moeten schakelen. De dienst kan niet garanderen dat dit het probleem volledig verhelpt.

T is dus een feature en geen bug
daarnaast, in vliegtuigmodes.. dan zou je toch helemaal geen verbinding moeten hebben?
Zeker wel. je kunt in airplane-mode gewoon weer je verbinding aanvinken. verder beperkt het zich alleen tot Safari-browser
Aparte werking op IOS dan. Ben hiero gewend dat als ik mn telefoon in vliegtuig modus gooi dat alle verbindingen verbroken worden. Wifi, bluetooth, en verbinding met je provider valt weer aan te zetten ja, maar daar spreken ze niet over. ze spreken over UIT en weer IN schakelen vd vliegtuig modus.

edit: staat hier ook nergens dat dit alleen om safari gaat?

[Reactie gewijzigd door JWL92 op 27 maart 2020 11:53]

Aparte werking op IOS dan. Ben hiero gewend dat als ik mn telefoon in vliegtuig modus gooi dat alle verbindingen verbroken worden. Wifi, bluetooth, en verbinding met je provider valt weer aan te zetten ja, maar daar spreken ze niet over. ze spreken over UIT en weer IN schakelen vd vliegtuig modus.

edit: staat hier ook nergens dat dit alleen om safari gaat?
dat is verkeerd geschreven van Olaf. uit en aan verbreekt verbinding, dan moet je (eerst) weer verbinding maken. btw; mobile data kun je niet aanzetten in Airplane-mode, alleen WiFi.
Maar daarna wel, en die gaan dan voortaan via vpn.
De IP-adressen hadden sowiezo al achterhaald kunnen worden omdat er al verbindingen waren voordat de VPN connectie werd gelegd, dus wat dat betreft vind ik het een beetje vergezocht ...

Uiteraard wel vervelend dat al het vervolg verkeer niet over de VPN gaat.
Is dit wel een (nieuwe) bug? Voor zover ik weet verbreken zowel Android als iOS geen bestaande verbindingen wanneer je met VPN verbind. (De meeste apps zullen wel zelf opnieuw verbinden bij elke netwerk wijziging maar dat staat daar los van.)
Slechte zaak voor Apple, een bedrijf die propagandeert privacy hoog in het vaandel te hebben. Hopelijk komt er snel een oplossing. Dit zit er dus eigenlijk al in sinds (eind)januari 2020. Het betekent overigens ook dat de data niet meer versleuteld is die je verstuurd.
Dus als je privacy hoog in het vaandel hebt, is je software automatisch bug vrij? :P
Ook Apple zal altijd last blijven houden van bugs, net als elk ander bedrijf dat software maakt.
Hoe het bedrijf in kwestie omgaat met die bugs, scheid de goede van de slechte developers.
Niet het hebben van bugs opzich.
Goed punt, al verwacht ik dat Apple wel zou sturen op het sneller oplossen van beveiligingsbugs. Ik verwacht dat ze bij Apple een vorm van een beslis kwadrant gebruiken om de prioritering van bugs op te pakken. Als je prat gaat op security, verwacht ik dat deze bug binnen het hoge prioriteit kwadrant valt.
ProtonVPN heeft dit begin februari gemeld, dus Apple heeft m.i. tijd genoeg gehad om dit aan te pakken. Dus ik vermoed dat het meer binnen de aansturing (Oftewel prioritering) van de developers zit dan de developers zelf.
Dus nee, als je de privacy hoog in het vaandel hebt, is je software niet automatisch bug vrij. Het is alleen de vraag waar leg je de focus op en welke bugs pak je met welke prioriteit op.

[Reactie gewijzigd door Ganymedus op 27 maart 2020 11:44]

Waar staat dat Apple dit al sinds begin februari weet? In de link zie ik alleen dat Protonvpn contact heeft gehad met apple, niet wanneer.
Direct van ProtonVPN:
Last year, we discovered a vulnerability in iOS that causes connections to bypass VPN encryption. This is a bug in iOS that impacts all VPNs. We have informed Apple, and we are now sharing details so you can stay safe.
https://twitter.com/ProtonVPN/status/1242906274112712704
Of het nog versleuteld is hangt af van de oorspronkelijke verbinding zelf natuurlijk. Als dat een versleutelde verbinding was, dan blijft dat zo.
Eens, ik refereerde naar de versleuteling die uitgevoerd wordt door de VPN app zelf.
Waarom zou je je deur op slot doen, ben je bang dat er wat gestolen word? Zo'n krom iets. Iedereen heeft wat te verbergen. Of het nu je credit card gegevens zijn, je SOFI nummer, de foto's van je vriendin, of wat dan ook. Je privacy proberen te beschermen zou een algemeen iets moeten zijn. Een VPN gebruiken is hierbij een hulpmiddel. Het is niet een directe bescherming, maar valt in het gehele plaatje.
Omdat je VPN niet gebruikt om wat te willen verbergen?
Of wel natuurlijk. Ligt helemaal aan de situatie waar je een VPN voor gebruikt :) In gestoorde regimes kan je leven er vanaf hangen. ;)

Maar ook zonder de noodzaak iets te verbergen te hebben biedt een VPN tal van voordelen voor een heel scala aan doeleinden natuurlijk. :) En iets verbergen is soms een heel goed plan, zoals op onbeveiligde publieke WiFi...

[Reactie gewijzigd door WhatsappHack op 27 maart 2020 12:40]

Omdat ik misschien Amerikaanse content wil zien die alleen aan Amerikaanse ip's wordt geserveerd bijvoorbeeld?

Op dit item kan niet meer gereageerd worden.


Apple iPhone SE (2020) Microsoft Xbox Series X LG CX Google Pixel 4a CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True