Onderzoeker: bestaande verbindingen in iOS 15.5 gaan buiten vpn-tunnel om

Beveiligingsonderzoeker Michael Horowitz claimt dat iOS 15.5 bestaande dataverbindingen niet sluit bij het gebruik van een vpn-dienst. Hierdoor is het mogelijk om een ip-adres van een gebruiker in te kijken zonder dat die dit verwacht.

Beveiligingsonderzoeker Michael Horowitz is nagegaan welke data door een iPad met iPadOS 15.4.1 wordt verstuurd nadat de vpn-functionaliteit op het toestel geactiveerd wordt. Hij deed beroep op de vpn-app van ProtonVPN met versienummer 3.1.3 en zag via logging dat het besturingssysteem buiten de vpn-tunnel om verbinding bleef maken met onder andere de servers van Apple. Sommige van de uitgaande requests van iOS 15.4.1 gingen naar Apple-servers die instonden voor de werking van FaceTime en Game Center, ook al gebruikte de man die diensten op dat moment niet.

Kort na zijn eerste test, ging Horowitz na of hij dezelfde resultaten kon oproepen bij iPadOS15.5. Hij maakte deze keer wel gebruik van een app van een andere vpn-provider, OVPN met appversie 0.5.0. De man zag na het opzetten van de vpn-verbinding dat er weer heel wat uitgaande requests waren die opnieuw buiten de vpn-tunnel om gingen. Deze requests gingen richting de servers van onder andere Apple en Amazon Web Services.

Het is niet de eerste keer dat Apple in het nieuws komt wegens problemen met de vpn-functionaliteit in iOS. In 2020 waarschuwde ProtonVPN immers voor hetzelfde probleem als wat Horowitz heeft aangetroffen. Toen ging het om iOS 13.3.1 en versie 13.4. ProtonVPN waarschuwde toen dat de ip-adressen van gebruikers inzichtelijk waren ondanks het gebruik van een vpn omdat sommige bestaande verbindingen uren konden blijven bestaan buiten de vpn-tunnel om. Het bedrijf stelde toen voor om de vliegtuigmodus in en uit te schakelen na het opzetten van de vpn. Dat moest volgens ProtonVPN bestaande verbindingen helpen afsluiten.

Actieve sessies op iPad van Michael Horowitz nadat vpn-dienst werd geactiveerd

Reacties (98)

[Myrdhin]

Ik ben ook benieuwd hoe het zit met de ingebouwde iOS VPN client. Mogelijk dat 3rd party VPN software op iOS niet compleet kan of mag ingrijpen op al het verkeer terwijl de interne client dat wel kan. Misschien vanwege secuity dat ze niet al het verkeer via een 3rd party app laten lopen echter aan de andere kant breekt dat ook weer een stukje veiligheid af.

[Reactie gewijzigd door Myrdhin op 22 juli 2024 15:50]

[Maurits van Baerle]

Het lijkt te gaan om dat die ingebouwde VPN module waar alle VPN clients bovenop gebouwd zijn wel al het verkeer door de tunnel kan laten leiden maar bij het opzetten van de tunnel niet de bestaande verbindingen verbreekt.

Als er dus al op OS niveau verbindingen bestaan (en dat zijn dus niet toevallig voornamelijk of enkel standaard verbindingen van het OS, luisteren naar inkomende Facetime telefoontjes, updates etc.)
dan blijven die buiten de tunnel om gaan.

Het is een slordigheid die, lijkt mij, best makkelijk te fixen zou moeten zijn. Maar alleen Apple kan het doen omdat het in een iOS module zit.

[batteries4ever]

Nou, dat is dan de positive interpretatie.
De negative is: Apple en Amazon zijn er net zo goed bij gebruikersinfo te hamsteren als Google en alle Appelaars die stellen dat Apple dat niet zou doen "omdat je al fors betaalt voor de hardware en ze dus hun eigen glazen in zouden gooien" hebben wellicht ongelijk....
je betaald fors voor de hardware en je persoonlijke gegevens worden alsnog gestolen...

[Bulkzooi]

Nou, dat is dan de positive interpretatie.
De negative is: Apple en Amazon zijn er net zo goed bij gebruikersinfo te hamsteren als Google

Als je denkt dat de data bij deze partijen (en Microsoft) blijft, dan heb je niet goed opgelet.

[Maurits van Baerle]

Ehm, Apple heeft er geen baat bij om bestaande verbindingen niet af te breken zodra een tunnel wordt opgebouwd.

Sterker nog, als Apple kwaad zou willen door zoveel mogelijk informatie te verzamelen dan zouden ze juist belang hebben bij het opnieuw op zetten van de verbindingen met hun servers via de VPN. Dan zouden ze namelijk weten dat gebruiker X af en toe een VPN opzet via extern IP Y. Door de bestaande verbindingen niet af te breken komt Apple juist niet te weten dat je een VPN gebruikt.

Daarom lijkt het op basis van de informatie die we nu hebben vooral een slordigheid tijdens het ontwerpen van de VPN module in combinatie met een laksheid door twee jaar lang na de eerste melding geen actie te ondernemen door het probleem op te lossen.

[Reactie gewijzigd door Maurits van Baerle op 22 juli 2024 15:50]

[batteries4ever]

Hallo Maurits: ik dacht eigenlijk aan wat anders: doel van een VPN is dat "alles" door de VPN gaat tenzij je het op een uitzonderingslijst zet. Daar zou dus ook het verkeer van en naar de Apple Servers toe horen, al kan dat ertoe lijden dat je een stukje functionaliteit verliest.

[Maurits van Baerle]

Dat is inderdaad de bedoeling. Maar, als je cynisch bent en verwacht dat Apple graag zoveel mogelijk informatie verzamelt, dan hebben ze dus niets aan dit foutje omdat ze nu de informatie over dat die gebruiker een VPN gebruikt mislopen.

[Bulkzooi]

Het lijkt te gaan om dat die ingebouwde VPN module waar alle VPN clients bovenop gebouwd zijn wel al het verkeer door de tunnel kan laten leiden maar bij het opzetten van de tunnel niet de bestaande verbindingen verbreekt.

Als er dus al op OS niveau verbindingen bestaan (en dat zijn dus niet toevallig voornamelijk of enkel standaard verbindingen van het OS, luisteren naar inkomende Facetime telefoontjes, updates etc.)
dan blijven die buiten de tunnel om gaan.

Het is een slordigheid die, lijkt mij, best makkelijk te fixen zou moeten zijn. Maar alleen Apple kan het doen omdat het in een iOS module zit.

Nou, sloridgheid is een understatement.

Het probleem is minimaal bekend sinds iOS 13.3.1 met ProtonVPN versie 13.4, ergens in maart 2020, tot en met het huidige iPadOS15.4+ met OVPN 0.5.0 of ProtonVPN 3.1.3 bestaat dit probleem dus.

Da's dus ~2,5 jaar, want intuïtief enkele vragen oproept:
1> Hoe betrouwbaar is pcap logging/monitoring?
2> Welke settings (Apple of 3rd-party) hebben überhaupt hier invloed op?
3> Hoe staat het e.e.a. omschreven in de betreffende EULA’s, ToS’s, etc.
4> Hoe verhouden deze antwoorden zich tot de privacy discussie?

En wat GARANDEERT Apple?

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 or Mullvad.

Dit betreft dus niet enkel een iOS module; het betreft de gehele device/apparaat en alle 3rd-party software. Het lijkt erop dat Notifications, Updates, FaceTime en Game Center, alsmede Amazon Web Services een voorkeursbehandeling krijgen.

Apple Always-on VPN is overigens beschikbaar sinds iOS 8 en Google en Microsoft kunnen niet ver weg zijn, want het woord „bigtech" bestaat niet voor niks.

In november 2020 had je ook nog het verhaal m.b.t. de ContentFilterExclusionList, AppleSupport FB8817119, die verwijdert is in macOS 11.2 beta 2. Het probleem betrof 53 apps, o.a. iStore, iCloud en Maps.

This means socket filter firewalls (such as LuLu) can now comprehensively monitor & block all network traffic. macOS 11.2 beta 2 uprooted the privacy loophole after Big Sur privacy upgrade)

The bugs centered on Apple apps disapproving network kernel extensions (NKEs) in Big Sur (iOS11). However, Apple has provided no evidence or details of the malware attack.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 15:50]

[Maurits van Baerle]

Ik leidt nergens uit af dat er een voorkeursbehandeling wordt gegeven aan bepaald verkeer. Waar baseer je dat op?

Op basis van het artikel lijkt het er op dat, na het opzetten van de VPN tunnel door de VPN module, bestaande verbindingen niet worden verbroken. Dat zou je liever wel hebben zodat ze daarna via de tunnel lopen. Dat het uitgerekend verbindingen met de FaceTime en update server zijn die buiten de tunnel blijven, en niet bijvoorbeeld een email app of Whatsapp, geeft aan dat het basale verbindingen op OS niveau zijn.

Apple zou dit moeten oplossen door een vrij simpele wijziging in de VPN module die alle bestaande verbinding verbreekt na het opzetten van de tunnel. Dit gebeurt op een laag niveau en alle apps (zowel first als third party) leunen op die module dus je lost het voor allemaal in één keer op.

[Bulkzooi]

Ik leidt nergens uit af dat er een voorkeursbehandeling wordt gegeven aan bepaald verkeer. Waar baseer je dat op?

Ik baseer dat op technische waarheid, maar dit is laatst nog eens bevestigd door Patrick Wardle. https://twitter.com/patrickwardle/status/1327034191523975168

Apple heeft dat ook al "opgelost". Bovendien, ISP's passen QoS en dergelijke technieken toe, dus de infrastructuur is groter dan enkel een workstation, door bv. remote caching en/of de invloed van andere services zoals bv. NFC profiles of firewall configuraties.

Wat jij beschrijft is een soort sandbox'en, zoals de private-mode in de browser. De meeste verbindingen zijn tegenwoordig hoe dan ook versleuteld. Overigens, Proton adviseert iets met vliegtuigmodus als VPN-workaround.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 15:50]

[SgtElPotato]

Een externe VPN client maakt verbinding door middel van de ingebouwde client. Het is eigenlijk een schil wat je doet in de app, je moet de app toegang geven om een profiel aan te laten maken en vervolgens de app toestemming geven dat deze een VPN mag aan / uitzetten.

[xFeverr]

Niet helemaal. Je kunt een ‘Network Extension’ maken die een ‘Packet Tunnel Provider’ implementeert.

Die network extension wordt wel door iOS beheert. Dus die start de extensie en stuurt daar netwerkpakketten naar toe. Die kun je dan vervolgens afhandelen, met bijvoorbeeld een eigen VPN protocol. iOS heeft namelijk maar ondersteuning voor een beperkt aantal protocollen, een OpenVPN of Wireguard moeten dus door een ontwikkelaar geïmplementeerd worden.

Omdat iOS het verder beheert kun je ook elke VPN verbinding eenvoudig stoppen. iOS stopt dan met het doorgeven van pakketten en sluit de extensie af.

Een extensie op iOS is een soort mini-app zonder normale interface die bij je app zelf zit. Het draait verder zelfstandig, maar kan met de hoofdapp communiceren. Zo heb je ook extensies voor bijvoorbeeld Siri, die kunnen draaien zonder dat je app actief is. Of een File Provider, die integreert in fe Bestanden app. Of een Notification extension, als je eigen content in een melding wil renderen.

Meer informatie over Network Extensions vind je in de documentatie van Apple.

[SgtElPotato]

Thanks voor de aanvulling! Weer wat geleerd!

[begintmeta]

Ik moet zeggen dat ik het me dan wat onzinnig lijkt om verbinding te maken via apps die de interne cliënt weer gebruiken, in plaats van gewoon de interne cliënt te configureren via de OS-eigen interface. het gebruik van de third-party app geeft alleen extra onduidelijkheid/onzekerheid zoals ook uit de reacties hierboven blijkt

Verder ben ik benieuwd of iOS dan ook een WireGuard-cliënt ingebouwd heeft, die volgens het bronartikel ook is gebruikt. In dat geval lijkt het me tijd dat Apple die ook zonder third-party apps beschikbaar stelt.

Naast dat ze het verbreken of behouden van verbindingen configureerbaarder maken natuurlijk.

[Reactie gewijzigd door begintmeta op 22 juli 2024 15:50]

[HakanX]

Is net als browsers op iOS, mogen ook geen eigen renderer gebruiken, zijn verplicht die van Apple te gebruiken.

[lenwar]

Je mag inderdaad geen andere software engines gebruiken die niet meer iOS geleverd worden.
Dit zorgde ervoor dat Flash nooit beschikbaar was op iOS. Ik inderdaad geen andere web renderer. Maar is dat in de praktijk een probleem? Hoeveel mobiele sites kom jij tegen die het niet op de WebKit engine doen, maar wel op een andere engine?

Andere browsers zijn voornamelijk bezig met extra features/troep inbouwen. In de praktijk interesseert niemand het welke engine hun browser gebruikt toch? Als de site het maar doet

[!GN!T!ON]

Webkit is heeft in mijn ervaring best wel veel IE6 achtige trekjes, traag met ondersteuning van standaarden, of standaarden gewoon helemaal niet ondersteunen omdat ze zelf iets non-standard hebben gebouwd.

[lenwar]

Daar heb ik dan helemaal geen kennis van. Het enige dat ik zie is dat de websites die ik bezoek op m'n telefoon nooit problemen hebben die ik opmerk als een potentieel probleem in de engine.

Uit oprechte nieuwsgierigheid: Over wat voor standaarden hebben we het hier die ontbreken en/of waar Apple dan zelf wat voor bedacht heeft? Zijn dat echt basale zaken en core-componenten, of meer van die dingen dat websites pushberichten kunnen sturen en zo (wat ik persoon een verschrikkelijk concept vind, maar dat is puur persoonlijk)

[!GN!T!ON]

Dit is (net als met IE6 overigens) meer aan de development kant. Apple ondersteund(e) bijvoorbeeld geen videocodec die letterlijk -alle- andere browsers ondersteunde, want ze hadden een eigen videocodec. Kijk ook eens op https://caniuse.com/ daar staat safari (ruim) onderaan.

Hierdoor moet je als developer steeds apart voor apple / safari ontwikkelen, ipv 1x volgens de standaarden iets ontwikkelen en dat het overal werkt. Ook houd het ontwikkelingen op het web tegen, want ontwikkelaars gaan functies die alle andere browsers in sommige gevallen al jaren ondersteunen maar apple niet, dus word het of niet gebruikt, of ontwikkelaars moeten voor safari workarounds toevoegen.

Had dit zelf o.a. meegemaakt toen ik een webchat / video website aan het maken was a la skype / zoom. Alle browsers ondersteunde dezelfde videocodec en webrtc communicatie mogelijkheden, bijhalve safari. Daar moest dus een compleet andere oplossing naast gemaakt worden met videocodec transcoding, browser detectie enzovoorts.

En dat is op veel van deze technische ondersteuningspunten zo met safari. Ik vind het dan ook de meest klote browser om te moeten ondersteunen als developer.

[TheVivaldi]

Geen ervaring met iOS, maar op de computer kom ik af en toe een site tegen die het niet goed doet op QtWebEngine/Blink, dus ik kan me voorstellen dat het met WebKit (waar Blink uiteindelijk van afgeleid is) ook wel eens voorkomt.

[Bulkzooi]

Is net als browsers op iOS, mogen ook geen eigen renderer gebruiken, zijn verplicht die van Apple te gebruiken.

Ik denk dat de Appstores en games (metal) ook een plaatsje in dit render-verhaal hebben, mn. de toelatingsvereisten. Alsmede adobe producten/formats en flash (shockwave en Silverlight) technology. Da's laat maar zeggen alles waardoor HTML5 zo lang geduurd heeft en er interessante tech verloren is gegaan, zoals RSS.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 15:50]

[HenkEisDS]

3rd party vpns maken gebruik van dezelfde api lijkt me.

[Bulkzooi]

hier heb je wel een aardig overzicht:
https://mullvad.net/nl/why-mullvad-vpn/

We ondersteunen twee protocollen voor de VPN-tunnel, OpenVPN en WireGuard:

We beperken OpenVPN tot TLS 1.3 (als besturingskanaal) en AES-256-GCM (als gegevenskanaal). Dit is geïmplementeerd in OpenSSL.
Voor WireGuard implementeren we de standaard Linux-kernel wanneer beschikbaar. Anders gebruiken we wireguard-go.

[HenkEisDS]

?

[Bulkzooi]

?

Welke API heb je het dan over?

Split tunneling? Multihop? Shadowsocks-proxy?

[HenkEisDS]

Oh zo bedoel je. Ja dat schrijf ik misschien niet heel duidelijk.

De apis die apple ten beschikking stelt voor vpn app makers.
https://developer.apple.c...orkextension/nevpnmanager

[Bulkzooi]

De apis die apple ten beschikking stelt voor vpn app makers.
https://developer.apple.c...orkextension/nevpnmanager

tja, dan accepteert de dev een nieuwe versie van de API.

Da's voor devs en die hebben al een belang. lol, het is nog makkelijker/goedkoper om de meter te bewijzen, dan net zo lang next-next-next te klikken totdat je een devID van je appleID hebt gemaakt.

Dat zijn miljoenen pagina's, en bij Android nog een stuk meer. En dan mag je nog geen tweet sturen.

[GekkePrutser]

Dit vind ik nou niet zo heel opzichtbarend. Veel VPN's op Windows en macOS doen dat net zo. Ik gebruikte dit altijd als trucje om toch met mijn thuis-spullen te kunnen verbinden terwijl ik op de VPN van werk zat Gewoon eerst een SSH verbinding openen, dan de VPN opstarten, de SSH blijft gewoon staan. Dan daar alles doorheen tunnelen wat ik nodig had.

[Iblies]

Maar dat is het rare,

Hij deed beroep op de vpn-app van ProtonVPN met versienummer 3.1.3 en zag via logging dat het besturingssysteem buiten de vpn-tunnel om verbinding bleef maken met onder andere de servers van Apple.

De verbinding veranderd niet. Wat me dan opvalt is dat het het een compleet andere poort is, 56809

Dat het niet een reguliere poort is kan ik me voorstellen maar dit lijkt me een bewuste keus.

[GekkePrutser]

Nouja, sowieso sluit Apple hun eigen diensten uit van VPN. Dit dezen ze op de Mac ook maar dat is teruggedraaid na klachten. Maar op iOS is dit volgens mij nooit teruggedraaid.

Maar dat is een ander verhaal dan dat bestaande verbindingen blijven staan als je de VPN inschakelt.

Overigens wat ik in die screenshots zie is dat de 56xxx poorten de source (bron) poorten zijn. De bronpoort is altijd dynamisch of helemaal random, en is helemaal niet van belang.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 15:50]

[xbeam]

Apples iOS eigen diensten lopen (tegenwoordig)wel degelijk over VPN. Ik zie hier in de DPI van alle users de opgezette verbinding van Apple diensten voorbijkomen en ook heb ik een constante ruzie met FaceTime en Berichten/Messenger in combinatie met onze (root.crt) SSL en de (virus) inspectie van deze diensten. Dat ik uiteindelijk maar heb besloten deze van scanning uit te sluiten.

Wat ik wel kan beamen is dat waneer de verbindingen al zijn opgezegd voor dat de vpn ontwaakt/verbonden is de bestaande verbinding/routes blijven bestaan wat is op te lossen door de vpn altijd 24/7 te forceren. Wat in geval van zero trust ook de voor keur heeft.

Dit is ook wat door zijn peer group wordt omschreven als normaal/verwacht/bekend gedrag en waardoor zijn lek door sommige wordt toegeschreven aan zijn eigen of de app instellingen. Hierdoor zijn de meningen over zijn bevindingen erg verdeeld

https://news.ycombinator.com/item?id=32488308

hkpack 1 day ago | next [–]

I was developing VPN client for one of the popular VPN provider in the past for iOS and the solution was quite simple - enable on-demand VPN for 0.0.0.0/0
In this case, iOS will always wait until connection to VPN is established before sending any packets out.
Without on-demand, VPN may leak.
If I remember correctly, leaks occurred mostly after waking from sleep but before the tunnel had chance to be set up. Or in similar situations. Anyway, on-demand option solved all of them.

dcow 1 day ago | prev | next [–]

I wonder if the author tried using an On Demand VPN rule for the default route. That's always what I've done when setting this stuff up. Correct me if I'm wrong, but you don't need a device management profile to enable an on-demand VPN for all traffic. Then, reboot your phone and all application traffic, or traffic that isn't something system (APNS) or management/link-local (dhcp, mdns, etc.) will use the tunnel.

jart 1 day ago | root | parent | next [–]

The ProtonMail article said it only applies to pre-existing connections, because iOS doesn't force them to close when an app enables its VPN. I'd be reluctant to call that a leak, unless it contradicts Apple's documented behaviors, which as far as I can tell make no mention of a systemwide VPN except for corporate "always on" ones. Besides, is there any reason why you can't just toggle airplane after enabling a consumer VPN to kill off the old connections? Then it should probably be fine.
reply

[Reactie gewijzigd door xbeam op 22 juli 2024 15:50]

[Bulkzooi]

Dit vind ik nou niet zo heel opzichtbarend. Veel VPN's op Windows en macOS doen dat net zo. Ik gebruikte dit altijd als trucje om toch met mijn thuis-spullen te kunnen verbinden terwijl ik op de VPN van werk zat Gewoon eerst een SSH verbinding openen, dan de VPN opstarten, de SSH blijft gewoon staan. Dan daar alles doorheen tunnelen wat ik nodig had.

ik gebruik zo al pakkumkbeet, 25 jaar, socks2http. Ook gelijktijdig met tightVNC en/of RDP. Werkt ook voor mail en sync'en met remote repo's en wat mij betreft hoeft dat echt niet allemaal parallel te gebeuren (MSMQ is een gedrocht, zoals dbus dat ook is) .

Apples iOS eigen diensten lopen (tegenwoordig)wel degelijk over VPN. Ik zie hier in de DPI van alle users de opgezette verbinding van Apple diensten voorbijkomen en ook heb ik een constante ruzie met FaceTime en Berichten/Messenger in combinatie met onze (root.crt) SSL en de (virus) inspectie van deze diensten. Dat ik uiteindelijk maar heb besloten deze van scanning uit te sluiten.

Oké, maar dit lost het probleem niet op. Ze noemen ook Mullvad als VPN dienst. Is dat een complete security oplossing met lulu firewall of zo? Of ik begrijp niet wat dpi is.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 15:50]

[xbeam]

Ik denk gezien achtergrond, het gebruik van socks2http en het vaker bij infosec berichten reageren dat je een prima begrip van Dpi (deep package inspection) hebt.
In mijn bericht bedoel ik er eenvoudig mee dat ik appel’s diensten van de out of the office iOS devices gewoon over onze firewall zie lopen.

[Reactie gewijzigd door xbeam op 22 juli 2024 15:50]

[Bulkzooi]

deep package inspection lijkt me sowieso een firewall-feature, geen desktop feature en al helemaal niet voor mobieltjes.

Dus voor werkstation beheerders is er weinig verandert aan de gebruikerservaring. Die weten wat ze uitleveren en wat ze toestaan.

Ik weet niet hoe diep die inspectie ingrijpt in de data workflows, maar ik hoop enkel dat het niet teveel impact heeft op privacy of open source principes.

Lol, en elke request gaat hopelijk over de firewall..

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 15:50]

[xbeam]

Dat is juist de discussie. volgens de vinder dit lek niet. Die zegt dat er buiten de vpn om request worden af gehandeld door de locale/personeel/thuis router van het netwerk waar telefoon zich op begeeft en dus niet via de vpn door de firewall van kantoor. Waar alle zoals Mullvad beveiligingen op zitten.

Als Apple service niet over VPN zouden gaan dan zou ik dus ook niet in de DPI van onze firewall terug zien.

DPI heeft zeker impact op de privacy van de gebruiker. Daarom zeggen we ook altijd geen porn kijken je werk laptop en telefoon want je baas (IT) kijkt mee.

DPI geeft de mogelijkheid dat om bijv virus in download te herkennen en dan de download vroegtijdig te stoppen. Is dit waterdicht? zeker niet maar het doen wel veel rotzooi voorkomen

[Reactie gewijzigd door xbeam op 22 juli 2024 15:50]

[Bulkzooi]

Dat is juist de discussie. volgens de vinder dit lek niet.

Als Apple service niet over VPN zouden gaan dan zou ik dus ook niet in de DPI van onze firewall terug zien.

Die verbindingen gaan niet over de firewall??? Hoe gaat die verbinding dan naar de bestemming?

Maar het probleem gold dus al ~2,5 jaar en het is dus voor beheerders enkel zorgen dat die update gaat draaien en misschien een nieuwe cursus volgen om het e.e.a. in te richten. Voor eind-gebruikers verandert er ook weinig. Een paar nieuwe FAQ's moet voldoende zijn.

En meestal is het niet de baas die mee kijkt; collega's, overijverige ambtenaren en losgeslagen admins zijn grotere problemen.

DPI geeft de mogelijkheid dat om bijv virus in download te herkennen

Een signature check? Da's toch niks nieuws? Daarom vond ik juist je eerste comment leuk:

Gewoon eerst een SSH verbinding openen, dan de VPN opstarten, de SSH blijft gewoon staan. Dan daar alles doorheen tunnelen

ik gebruik zo al pakkumkbeet, 25 jaar, socks2http. Ook gelijktijdig met tightVNC en/of RDP. Werkt ook voor mail en sync'en met remote repo's en wat mij betreft hoeft dat echt niet allemaal parallel te gebeuren (MSMQ is een gedrocht, zoals dbus dat ook is) .

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 15:50]

[xbeam]

We walking circles

[Bulkzooi]

Hoe bedoel je?

Jij zegt:

Dat is juist de discussie. volgens de vinder dit lek niet.

en daarbij claim je:

dat Apples iOS eigen diensten lopen (tegenwoordig) wel degelijk over VPN. Als Apple service niet over VPN zouden gaan dan zou ik dus ook niet in de DPI van onze firewall terug zien.

terwijl ik zeg dat socks2http deze discussie al pakkumkbeet 25 jaar gecodificeerd heeft. Voor een reden.

Heb je wel in overweging genomen dat SSH ook een signature-check heeft? Ik bedoel, je hebt een constante ruzie met FaceTime en Berichten/Messenger in combinatie met de (root.crt) SSL en de (virus) inspectie van deze diensten. Mijn ervaring is dat MSMQ een brak stukje MS infrastructuur is, maar ik ben niet zo bekent met Apple maar zo ver ik begrijp verandert er voor Apple devs weinig om een VPN-app te publiceren naar de Store.
https://developer.apple.c...orkextension/nevpnmanager

Ik denk vooral vanuit de eind-gebruiker, en mullvad lijkt me wel goed.
https://mullvad.net/nl/why-mullvad-vpn/
Op Windows kan je denken aan zoiets als WolfSSL

Microsoft zelf biedt Express-vpn aan:
https://answers.microsoft...ed-4545-9875-cf62852347fc

Behalve over libs moet je ook over VPN-tunnel-protocollen nadenken. Da's wat meer high-level, met OpenVPN versus WireGuard versus Lightway
https://codepre.com/nl/op...o-vpn-deberia-usar-2.html

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 15:50]

[xbeam]

Dude waar heb je allemaal over of we praten echt totaal langs elkaar heen of we draaien cirkels vanwege de bewoordingen. of je verwart mij misschien met @GekkePrutser in de discussie

Het type vpn tunnel is volgens mij in het bericht van de auteur helemaal niet relevant en het gebruik van proxy server volgens mij ook niet. Volgens hem routeert IOS gewoon niet al het verkeer over VPN ongeacht vpn applicatie terwijl dat wel zou moeten.

in de discussie gaf ik alleen maar dat ssl inspectie Apple’s verificatie certificaat breekt en diensten zoals Apple Messenger en FaceTime dit net zoals whatsapp vanwege het gebruik van ssl pinning herkennen wanneer er een third party root certificaat wordt gebruikt en dan gaan steiger wat betreft een man in the wissel. dat is waarom ik ze heb uit gesloten van inspectie.

Dat heeft verder niets met de VPN zelf te maken. Ik haal het alleen maar aan om aan te geven dat Apple zijn diensten niet uitsluit van vpn routering op iOS Anders zou dit probleem niet bestaan omdat Apple berichten en icloud dan niet via de bedrijfs firewall maar via de firewall van gebruiker thuis of telefoon maatschappij zou gaan.

The don’t inspect Dev pagina van de firewall legt waarschijnlijk beter uit wat mijn ruzie met deze diensten is en waarom ik ze uit eindelijk maar heb uitgesloten van scanning (probleem is wel dat je dus geen zicht en controle meer hebt op wat er via deze apps op de telefoon en laptops je netwerk binnen komt. https://developers.cloudf...-not-inspect-applications


Off topic:
Maar even ingaande op je

Ik denk vooral vanuit de eind-gebruiker, en mullvad lijkt me wel goed.
https://mullvad.net/nl/why-mullvad-vpn/

Als ik dan kijk naar wat ze bij mullvad zelf zeggen

Veilige jurisdictie
De wetten die voor ons als VPN-provider gebaseerd in Zweden relevant zijn, maken van onze locatie een veilige plaats voor ons en voor uw privacy.

Gezien deze juist vergaande jurisdicties van de sverige politie/veilheids diensten die gezien regelmatig not secure melding van firewall app hier mijn business Warp (WireGuard) naar NL lijken open te breken/blokkeren kan je juist beter niet voor mullvad maar gewoon voor een Nederlandse provider kiezen _
https://proprivacy.com/guides/swedish-privacy

When it comes to surveillance, however, all communications in and out of the country are monitored by the Swedish Defence Radio Authority (FRA), which has a close working relationship with the NSA.

Government Surveillance

Even before Sweden passed the FRA law in 2009, Privacy International ranked Sweden's privacy protection second worst in the EU.

The FRA law, however, gave the National Defence Radio Authority (Försvarets radioanstalt) powers to wiretap all telephone and Internet traffic that crossed Sweden's borders in order to combat foreign threats. It should be noted that this is something which it has been suspected of doing long beforehand.

Following the public outcry over the legislation being too far-reaching, the FRA law was quickly amended to require a court order on a case-by-case basis.

[Reactie gewijzigd door xbeam op 22 juli 2024 15:50]

[Bulkzooi]

Gezien deze juist vergaande jurisdicties van de sverige politie/veilheids diensten die gezien regelmatig not secure melding van firewall app hier mijn business Warp (WireGuard) naar NL lijken open te breken/blokkeren kan je juist beter niet voor mullvad maar gewoon voor een Nederlandse provider kiezen _
https://proprivacy.com/guides/swedish-privacy

Zowel de Cloud alsmede de wetten zijn moving targets. However, er zijn wel duidelijke momenten waarbij de functie van de wet omtrent Intellectuele Eigendommen fundamenteel en radicaal veranderen. Da's een filosofisch verhaal, zoals alle filosofie in de Cloud zit. Net als de luchtmacht, NASA, Branson en Musk.

Een privé persoon moet gewoon een lokale ISP pakken; maar die keuze is vrij insignificant gezien de werking van de industry en bv. roaming afspraken. Het is niet voor niks dat de individuele downloader historische bescherming geniet. En dan meer dankzij Zweden dan dankzij Nederland, die zich erg Hollands gedragen heeft tov Open Source. Om over Brein nog maar te zwijgen. Bovendien hebben die Zweden epische legacy achtergelaten, met de piratebay, het Sherwood Forest van web1.0. Zelfs de Fransen hebben een betere reputatie dan de Nederlanders, vooral dankzij FFMPEG en helemaal sinds streamen aan populairiteit won. Ook Spanje, met hun Guerilla Bluetooth en FreeBand mentaliteit heeft echt wel iets neergezet. Maar Nederland? lol, Tribler of zo?

En dan moet je nog 1 miljoen pagina's accepteren voordat je je sim registreert hebt op het netwerk, en nog eens een half miljoen voordat je je eerste tweet heb verzonden.

Zakelijk gezien zou ik eerder alles uitbesteden via obscure constructies en cdn's, en hier en daar een "groen" data center met een reklamebordje erop. No cure no pay basis, met een flinke boete clausule voor niet nagekomen leveringen.

Elke bit telt tenslotte.

Qua VPN-dienstverleners hoorde ik overigens ook goede dingen over NordVPN & WolfSSL. PolarSSL en OpenSSL zijn on hun way-out als ik het goed begrepen heb. Of die Nederlandse partij, die vanuit ram opereren.

Het ligt er ook aan waar je data allemaal naar toe moet. Zeker als je het hebt over privacy, want die data is al verdwenen in de dauw, wederom met Nederland en haar voortrekkersrol in het databankenrecht in een negatieve hoofdrol, voordat die voorbij de eerste meterkast is.

Technisch verhaal

Moet je nou nieuwe certificaten halen om die tunnels op te zetten? Hopelijk overlappen die van Cisco een beetje met die van MCSE zodat end-to-end encryption en point-to-point verbindingen niet in gevaar komen. Maar het is wel goed dat zulke partijen hun cursusmateriaal ram vol stoppen met jurisprudentie en en data filosophie. Hoef vaak zie je wel niet inrichtingsfouten vanwege slechte handleidingen?

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 15:50]

[xbeam]

[...]

Zakelijk gezien zou ik eerder alles uitbesteden via obscure constructies en cdn's, en hier en daar een "groen" data center met een reklamebordje erop. No cure no pay basis, met een flinke boete clausule voor niet nagekomen leveringen.

[...]

Moet je nou nieuwe certificaten halen om die tunnels op te zetten? Hopelijk overlappen die van Cisco een beetje met die van MCSE zodat end-to-end encryption en point-to-point verbindingen niet in gevaar komen. Maar het is wel goed dat zulke partijen hun cursusmateriaal ram vol stoppen met jurisprudentie en en data filosophie. Hoef vaak zie je wel niet inrichtingsfouten vanwege slechte handleidingen?

Gelukkig geen verplichte certificering. Als Dev(ops) kan trouwens voor privé gebruik van CF een NFR op alle tunnel en ZTA (CF one) diensten krijgen

Gebruik dan je eigen Root.crt en bent redelijk safe

[Reactie gewijzigd door xbeam op 22 juli 2024 15:50]

[GekkePrutser]

Apples iOS eigen diensten lopen (tegenwoordig)wel degelijk over VPN. Ik zie hier in de DPI van alle users de opgezette verbinding van Apple diensten voorbijkomen en ook heb ik een constante ruzie met FaceTime en Berichten/Messenger in combinatie met onze (root.crt) SSL en de (virus) inspectie van deze diensten. Dat ik uiteindelijk maar heb besloten deze van scanning uit te sluiten.

Okee, ik heb er geen super recente ervaring mee, laatste keer was iets meer dan 2 jaar geleden.

We hadden ook problemen met proxy instellingen die genegeerd werden, en bij ons netwerk gaat er niets naar buiten zonder proxy. Daardoor werkte er van alles niet (bijv. APNS) omdat hij gewoon domweg direct naar buiten probeerde te gaan. We hebben uiteindelijk speciaal voor iPhones (we hebben er 30.000) een aparte SSID geinstalleerd met directe toegang naar buiten, maar geen toegang tot het bedrijfsnetwerk. Hiervoor moeten ze dan VPN gebruiken, net als wanneer ze off-net zijn (dus eigenlijk zijn ze nooit meer direct op het eigen netwerk).

Inderdaad hebben we ook de inspectie uit moeten zetten hiervoor. Vervelend want zo kunnen we exfiltratie via Apple diensten niet in de gaten houden (Apple zegt namelijk van whitelist alles maar).

[xbeam]

Maar hoef je toch geen aparte SSID voor op te zetten. Wat Apple specifieke firewall of routing regels zou genoeg moeten zijn.

Of je implementeert op reeds bestaande SSID een Dynamische Vlan voor je Apple devices. Dan heeft de eind gebruiker er ook geen last/omkijken naar.

[GekkePrutser]

Dat wil ons netwerk team niet. Geen uitgaand verkeer zonder de proxy op het normale netwerk. Op Mac hebben we nog steeds hetzelfde probleem hierdoor. Apns werkt daar nog steeds niet.

En de dynamische vlans kon onze WiFi infrastructuur op dat moment niet maar dat staat inderdaad wel op de planning voor de toekomst.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 15:50]

[xbeam]

Call me if you need help 👌

[GekkePrutser]

Bedankt! Maar ik ga er niet meer over. Door organisatorische veranderingen was mijn oude baan niet echt uitdagend meer. Dus ik ben toen naar een andere functie gegaan.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 15:50]

[NielsFL]

Android heeft dit ook. Bestaande verbindingen worden niet verbroken wanneer je VPN verbind maar blijven lekker doorlopen buiten het VPN. Volgens mij is dit een "feature" om te voorkomen dat lopende zaken mislukken wanneer je een VPN start.

Hetzelfde geld overigens wanneer je van 4G overschakelt op Wi-Fi. Verbindingen die op 4G lopen blijven daar gewoon doorlopen tot ze klaar zijn.

[maxxie85]

Jouw truukje klinkt meer als dat de routing table ervoor zorgt dat verkeer voor jou thuis netwerk het over jou ssh interface gooit, dan een bestaande verbinding.
Kan mij niet voorstellen dat een tcp/udp sessie zo lang stand houdt.

[GekkePrutser]

Nope want als de VPN draait kon ik het niet meer opzetten. De vpn forceerde alles via VPN Via de routing table ja, en aanpassingen hieraan werden meteen teruggedraaid. Dit was de VPN van Juniper. Pulse Secure geloof ik.

En een SSH verbinding houdt zolang stand als je wil. Als het nodig is kan je keepalives aanzetten (er zijn zelfs 2 soorten van).

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 15:50]

[Bulkzooi]

Jouw truukje klinkt meer als dat de routing table ervoor zorgt dat verkeer voor jou thuis netwerk het over jou ssh interface gooit, dan een bestaande verbinding.
Kan mij niet voorstellen dat een tcp/udp sessie zo lang stand houdt.

Truukje?
Check anders socks2http eens. Die lib heeft een hele lange history, en tunnelt al het verkeer vanuit die ACPI-sessie naar specifieke IRQ ports. Een functie die normaal gesproken door het OS wordt uitgevoerd.

[maxxie85]

Hmm I stand corrected. Weer wat geleerd. Interessante materie.

[GertMenkel]

Geen enkel mobiel besturingssysteem is 100% overigens tegen beschermd. Zo kunnen op Android systeenapplicaties zelf kiezen aan welke interface ze hun sockets binden en daarmee iedere VPN praktisch omzeilen als ze dat willen.

Ik geloof niet dat er al fabrikanten gepakt zijn om dit gedrag, maar de code hiervoor is toch heel expliciet aanwezig in het Android-systeem. Ik snap het nut ook wel (je wilt dat een LTE-radio-daemon altijd met de radio-interface kan praten, bijvoorbeeld, en systeemservices die met meerdere interfaces werken moeten ook wat) maar aangezien er geen log of overzicht voor deze bindings is, is het wellicht de moeite waard te noemen.

[HakanX]

Nou je had BBOS die was daar 100% tegen beschermd, maar is kapot gemaakt. Het grootste verschil van dat OS was dat die van grond af aan met beveiliging in gedachte is opgebouwd, waar bij iOS en Android beveiliging later erin wordt gehackt. Daarom dat je zoveel beveiliging issues krijgt waar je de beveiliging kan omzeilen en gewoon "eronder" door kan gaan waar alles beschikbaar is.

[Brahiewahiewa]

Laten we wel wezen: BBOS is door de eigenaren kapot gemaakt; niet door concurenten of door overheids instanties

[HakanX]

Niet mee eens, steeds meer werd opzettelijk instabiel/niet werkend gemaakt. Vooral de Google webdiensten, dan heb je gelijk al het gevoel dat het halve internet niet werkt. Als je in de browser naar desktopmodus ging (andere UA kreeg je dan) dan werkte alles wel opeens. In die tijd was de mobiele webbrowser ook superieur aan alle andere met ondersteuning van standaarden en kreeg veruit de hoogste punten in testen, toch kreeg je op Google pagina's het bericht dat je een "verouderde browser" had en begon steeds meer niet te werken.
Facebook en WhatsApp werkten perfect, beter dan op Android, toch werden de apps uit de stores gehaald. Over WhatsApp was de reactie dat ze nieuwe technieken wilden gebruiken dat niet zou werken op BBOS. Dat was rond de tijd dat WhatsApp met videobellen kwam. Nou BB was de eerste die dat soort technieken en zelfs webrtc al ondersteunde. Verder hebben ze nog altijd niks beoeinds ingevoerd wat niet op BB zou werken.

Verder was er een hele media heisa continue om BB als bedrijf kapot te maken. Als je opzoek was naar een toestel en je gaat het internet af, haak je daardoor al af. Al deze dingen weet je vooral goed als je een BB gebruiker was, anderen kun je dit moeilijk laten geloven, omdat die het niet zelf hebben meegemaakt.
Je noemt verder ook overheden. Daar kan je bijna altijd alleen maar over speculeren, hard bewijs krijg je bijna nooit. Dat ze niet blij waren met de beveiliging van BB staat wel vast. Was natuurlijk wel een tweestrijd, want aan de andere kant liepen ze zel wel allemaal met Blackberry's vanwege de veiligheid.

[xbeam]

Overheden waren zo niet blij dat ze het allemaal zelf gebruikte

Overheden waren juist groot verbruiker.

[HakanX]

Ja dat noem ik zelf ook al blij voor hunzelf, minder blij dat ze niet bij anderen in kunnen neuzen. Maar dat begreep je wel denk ik.

[xbeam]

Zie smiley. Maar denk dat die 2 strijd alleen bij een hele specifieke afdeling binnen overheid speelt. Over het algemeen de beheerders van de meeste overheid organisaties er zeer content mee.

Al zag rond 2008/9 wel een tijdelijke duidelijke verschuiving van BES naar Windows mobile ontstaan vanwege de lagere AD implementatie kosten.

[Reactie gewijzigd door xbeam op 22 juli 2024 15:50]

[Bulkzooi]

Al zag rond 2008/9 wel een tijdelijke duidelijke verschuiving van BES naar Windows mobile ontstaan vanwege de lagere AD implementatie kosten.

En dat Blackberry verhaal van Rutte betrof sinds 2013 of zo? Vaag verhaal; waarom had die geen Alcatel en waarom pakt hij voor veiligheidsredenen een mobiel uit een niet-NATO land?? Ik snap sowieso niet dat hij geen satelliet-telefoon gebruikt voor belangrijke gesprekken en berichten. Dat deed mijn pa al in de jaren 80, een Motorola.

Maar inderdaad, ik kan me MS Continuum nog herinneren, met Windows 8.1. Was wel cool, maar een fiasco van $8 miljard. Dat was het volgende avontuur van Microsoft into mobile, met de opvolging van Windows CE en Pocket PC, gericht op de mobiele zakelijke en pro gebruikers. Behalve de AD integratie, was vooral mail-sync van groot belang. Dat was ergens tussen 3g en 4G denk ik, met gprs, en velen syncten toen via bijlagen in de mail want Outlook.com bestond nog niet en hotmail had maar een kleine mailbox, en liet maar 5 of 10 Mb aan bijlage toe.

Ik zelf privé vondt die Nokia's met Symbian ook altijd fijn werken. Die heb ik best een paar versleten, o.a. E80 & N95's, vooral vanwege de goede media-features. Totdat whatsapp echt niet meer werkte, hoewel toen Cyanogenmod ook al goed werkte.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 15:50]

[TheVivaldi]

Bij WhatsApp was het sowieso een smoesje van hun kant, want ze gingen wel door met de ondersteuning van de Windows Phone-/Mobile-app, een eveneens klein platform waarvan nota bene het einde al was aangekondigd door Microsoft (!)

[MOEL]

Ik denk dat de kwaliteit van dit onderzoek van meneer Michael Horowitz wordt opgesomd in wat hij hier zegt:

Not sure what SYN is.

Sorry, maar als je zo weinig van de TCP/IP stack weet, hoeveel waarde kunnen we dan hechten aan wat je test?

Op HN kwam dit artikel een paar dagen gelden ook voorbij, en de consensus is dat geen enkele huis-tuin-en-keuken VPN oplossing werkt zoals de eindgebruiker verwacht.

[joker1977]

Ik ben het met je eens dat ik ook verwacht dat iemand die serieus VPN-verbindingen test op eenieder toestel, ook moet weten wat de SYN-flag is.

Maar dat neemt niet weg dat het best 'gaar' is dat er TCP/IP-verkeer buiten de VPN-tunnel om gaat. Ironisch genoeg zouden juist pakketjes met de SYN-flag niet zomaar buiten de tunnel om moeten gaan. Immers, dat zijn nieuwe verbindingen (per definitie).

Je reactie dat kennis van de SYN-flag vereist is om deze test goed uit te voeren deel ik dan ook niet: Ik zie het een beetje als een test van een auto: Als er volgens de handleiding een toerenbegrenzer op 5000 rpm zit en een leek zonder rijbewijs kan zondermeer 8000 rpm halen en het blok opblazen dan kun je de kennis van de tester in twijfel trekken, maar feit is dat de fabrikant de brut niet op orde heeft.

Dat geldt in beginsel ook voor VPN-toepassingen. Het doel van de VPN-oplossingen is dat er geen verkeer buiten de tunnel om loopt.

[Zezura]

Je hebt enig sinds wel gelijk, maar het doel van VPN is niet altijd GEEN verkeer buiten de tunnel om.
Soms is het letterlijk gewoon een verbinding met een netwerk, naast je internet route.

[rdfeij]

True maar bij een VPN service (anders dan bijvoorbeeld een zakelijke VPN) verwacht je nu juist dat ALLE verkeer door de VPN gaat om privacy redenen. Je eigen IP mag op dat moment nergens meer gebruikt worden.
Actieve sessies zouden eventueel nog actief kunnen blijven, maar nieuwe moeten dan zeker weten door de VPN gaan. Dit verhaal klinkt bijna alsof er een paar keiharde high-prio static routes gemaakt zijn richting bepaalde services zodat ze niet door de VPN gaan.

Overigens gaat bij ons bij onze zakelijke VPN ook alle verkeer richting kantoor. Dit ook als een stukje veiligheid als we bijvoorbeeld in het buitenland zitten. (Ook heel makkelijk voor Netflix omdat die een NL ip te zien krijgt. Geen waarschuwingen over inloggen vanuit een vreemde locatie )

[Zezura]

Ja klopt, mijn eigen VPN tunnelt ook alles.
Ik denk dat tegenwoordig de meest gebruikte doel voor VPN’s is dat je al het verkeer tunnelt.

[xbeam]

Dat is het eigenlijk meestal VPN is van oudsher bedacht om vanuit een remote locatie toegang tot local services op een andere locatie te krijgen. Het vinkje in Windows all traffic over this tunnel is niet voor niets een extra optie.

[Reactie gewijzigd door xbeam op 22 juli 2024 15:50]

[DVBNL]

Precies, er zijn 2 usecases voor VPN. Slechts toegang tot een remote netwerk waarbij je meestal ervoor kiest om je lokale DNS/Gateway te gebruiken of je route juist alles over de tunnel voor anonimiteit om voor de buitenwereld je source IP te hiden.

Een simpele DNS leak is dan al tricky laat staan het leaken met SYN packets of wat dan ook.
Het is dus niet echt handig imo, maar als je dan echt 100% anoniem wilt zien gebruik je ook geen iPhone lijkt mij

[Brahiewahiewa]

...Ironisch genoeg zouden juist pakketjes met de SYN-flag niet zomaar buiten de tunnel om moeten gaan. Immers, dat zijn nieuwe verbindingen (per definitie)...

Niet waar. Je kunt bijvoorbeeld in een bestaande samba sessie een file-transfer initiëren; gaat ook gewoon via SYN, ACK-SYN, ACK

[joker1977]

Het ontbeert mij aan genoeg kennis over Samba, maar mijn eerste vermoeden is dat het dan toch een nieuwe verbinding is ? Vermoedelijk wordt er een nieuwe socket geopend aan de client-side en die meldt zich bij de remote Samba-server met een 1e packet met daarin de SYN-flag ?

Let wel: Ook al zijn er al verbindingen actief tussen de client en server - zodra er een nieuwe socket wordt geopend (met ongetwijfeld een nieuwe port aan de client-side) is dat formeel een 'nieuwe' verbinding vanuit het TCP/IP standpunt.

Neemt niet weg dat het opvallend is dat juist SYN-flagged packages er doorheen lekken.

[xbeam]

Zag het bericht gisteren al in een bericht voorbij komen waarbij ik ook al dacht hoe serieus moet ik dit nemen. Mijn eerste reactie/gevoel bij kop en inleiding het cybersecurity hub & The hacker news link/bericht was een beetje van “advertorial”

[Reactie gewijzigd door xbeam op 22 juli 2024 15:50]

[Bulkzooi]

Sorry, maar als Michael Horowitz zo weinig van de TCP/IP stack weet, hoeveel waarde kunnen we dan hechten aan wat je test?

Op HN kwam dit artikel een paar dagen gelden ook voorbij, en de consensus is dat geen enkele huis-tuin-en-keuken VPN oplossing werkt zoals de eindgebruiker verwacht.

Ik denk dat het een Amerikaan is die de Bigtech agenda verdedigt. Hij weet natuurlijk dat die alle tcp-verkeer omleiden naar udp en dat dit ook op dns-level gebeurd, met al die cdn's en caching mechanismes. Bovendien is het gouden business, data.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 15:50]

[Boxman]

Stukje bij beetje gaat dat pro-privacy imago van Apple nu wel de nek om. Ze laten steekjes vallen en advertentie revenue krijgt een steeds hogere prioriteit.. Jammer!

[Anoniem: 9278]

Dit is al sinds ios13 bekend.

[Boxman]

Dat maakt het niet bepaald beter, right? Deste meer reden dat het allang gefixt had moeten zijn.

[AibohphobiA BoB]

Apple heeft beveiliging nooit serieus genomen.

[WhatsappHack]

Always-on profiel gebruiken, dan bestaat dit gedrag niet. Ik vraag me af of dit overigens niet “by design” is. Met always-on gebeurt dit namelijk niet en als je handmatig de VPN inschakelt, bijvoorbeeld willekeurig: wil je dan meteen dat alles wat je hebt draaien de verbinding volledig verliest - dus alsof je het netwerk uit/aan togglet…? Je actieve downloads zullen stoppen, terminal sessies worden beëindigd, desnoods je IRC zonder bouncer klapt er uit en noem maar op. Bedoel; als je dat wil is dat prima hoor (en dat kan idd via airplane mode al is dat wat omslachtig), maar waarom gebruik je dan dus niet een Always-On oplossing dat hier juist voor gemaakt is en dat allemaal faciliteert…? (En anders dan de naam suggereert kan je een profiel zo schrijven dat je uitzonderingen hebt. Zoals bepaalde IP-ranges of bijvoorbeeld dat het niet inschakelt op je thuisnetwerk…)

Overigens, als je dus geen always-on gebruikt maar handmatig je VPN in en uitschakelt: dan is het toch je eigen schuld als je IP wordt prijsgegeven als je al verbindingen hebt gelegd of ben ik nou gek? Hoe moet de telefoon ruiken dat je verkeer van voor je de VPN inschakelde eigenlijk ook uitsluitend op de VPN wilde hebben? En wat maakt het uit als je de verbinding dus al gelegd had voor de VPN aanging? Dan hebben ze je IP toch al. Als ik app A start zonder dat de VPN aanstaat, dan geef ik m’n IP prijs dan al prijs. Wederom cirkelen we dus terug naar: gebruik dan Always-On wat *exact* voor dit doeleinde is ontworpen…? Naja.

[Jay-v]

Dat is hier op Tweakers niet heel duidelijk geschreven. In de blog staat duidelijk dat ook enkele nieuwe verbindingen buiten de VPN omgaan en dus een 'leak' zijn.

Twenty eight minutes after the VPN connection was established, this showed up in the log.

12:26:33 SRC=10.1.2.3 DST=137.220.51.178 LEN=589 PROTO=TCP SPT=57026 DPT=443 SYN

Een SYN is een nieuwe TCP verbinding die buiten de VPN wordt opgezet. Lijkt me niet de bedoeling.

[Progadgets]

Always-om kan je op een iPhone toch niet gewoon inschakelen?

[blorf]

Het is bij een VPN niet de bedoeling dat deelnemende computers naast de VPN-service nog andere verbindingen mogen maken.

[-Colossalman-]

Leuk dat het source ip afgeschermt wordt, maar dat is toch je VPN provider? Wat zegt het plaatje dan precies?

[Rob]

Dat is niet de VPN provider. Het plaatje komt van een apparaat dat tussen de iPad en het internet zat. Dit apparaat zou dus alleen maar de connectie naar de VPN provider moeten kunnen 'zien'.

[Bulkzooi]

het artikel linkt ook naar een artikel uit maart 2020, toen Proton dit probleem reeds publiceerde, waarbij een screenshot van pcap staat.

De windows-variant is WireShark en beide zijn gebaseerd op tcpdump.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 15:50]

[Accretion]

Een PepWave/PepLink router, te zien aan de UI stijl.

Het punt is dat Apple Push niet via de IPSec tunnel / VPN gaat.

[HakanX]

Het punt is dat Apple Push niet via de IPSec tunnel / VPN gaat.

Waarom zou dat niet kunnen? Als je op je router zelf VPN insteld, werkt Apple push toch ook gewoon?

[Accretion]

Als je op je iPhone VPN aan zet; gaat Apple Push nog steeds buiten de VPN om en is dan dus niet veilig.

Het gaat om de situatie waarin jij niet het beheer over de router hebt.

[HakanX]

Ja dat begrijp ik, maar dat is dus omdat Apple dat opzettelijk blokkeert en geen technische limitatie bij gebruik van VPN. Over hun beweegreden kunnen we alleen maar speculeren, die -1's laat ik aan iemand anders over

[Z80]

Heb je wel gelezen waar het over gaat? Namelijk een vpn app op de phone.
En er wordt niets geblokkeerd. Maar een bestaande verbinding, ongeacht of deze in gebruik is, gaat buiten de vpn om zodra er over deze verbinding data gaat.
Wat eigenlijk dient te gebeuren bij het activeren van een vpn tunnel is het afsluiten van alle data verbindingen en deze indien nodig via de tunnel opnieuw opzetten. Maar hier gaat het OS dus de mist in.

[HenkEisDS]

Nee dat is zijn eigen IP. Destination zou overal het IP van de VPN provider moeten zijn, maar dat is niet zo.

[divvid]

Zo raar is dat toch niet? Forticlient doet het is ook zo. Vanuit mijn werk kan ik een huis vlan niet bereiken. Als ik op het thuis netwerk zit uiteraard wel. Met Forticlient thuis ingeschakeld zie ik een werk adres, maar ik kan prima een ssh naar mijn andere vlan opzetten, die, als echt alle pakketten over de vpn zouden lopen, niet zichtbaar zou moeten zijn?

Als je echt privacy wilt, laat de router dan je vpn opzetten

[Bor]

Doel je niet gewoon op Split tunneling wat je ka toestaan en verbieden met Fortinet?

[divvid]

Zou best kunnen, ik ben slechts een gebruiker van de client.

[jabwd]

Hopelijk veroorzaakt dit genoeg hitte dat ook macOS gepatched wordt en ook apple services gewoon over de VPN gaan.

[Reactie gewijzigd door jabwd op 22 juli 2024 15:50]

[Proditor]

Ik dacht dat dat na de ophef die Objective-See hierover maakte gepatched was?

-edit-
Ja dus: https://privacysavvy.com/...rewalls-vpns-mac-big-sur/

Ik had dit toentertijd behoorlijk close gevolgd dus was even in de war.

[Reactie gewijzigd door Proditor op 22 juli 2024 15:50]

[jabwd]

Oh dat wist ik niet, dat is heel goed iig. Moet toegeven heb het ook niet heel erg gevolgd allemaal.