[HN Gopher] VPNs on iOS are a scam
___________________________________________________________________
VPNs on iOS are a scam
Author : alexpc201
Score : 162 points
Date : 2022-08-16 20:20 UTC (2 hours ago)
(HTM) web link (www.michaelhorowitz.com)
(TXT) w3m dump (www.michaelhorowitz.com)
| glerk wrote:
| Device-level VPNs are very useful for bypassing geographic
| restrictions, but I wouldn't rely on them for hiding traffic from
| ISPs, unless you are in control of 100% of what your device does.
| mmastrac wrote:
| Title should be: "VPNs on iOS are a scam", but a less
| sensationalist title might be: "VPNs on iOS leak traffic".
| rndgermandude wrote:
| It's not even the VPNs that leak, it's the Apple VPN
| implementation that does.
| [deleted]
| MikePlacid wrote:
| True. I've used VPN on iOS to play a second account on some
| online game. Worked like a charm, so it was definitely NOT a
| scam. If I wanted to hide my activity / identity from more
| serious people - I would never use iOS in the first place.
|
| But it's good to know that there are leaks, anyway.
|
| PS. And I guess all VPNs use the same base VPN functionality
| provided by iOS, so "is" looks a bit more appropriate than
| "scam".
| icehawk wrote:
| This how routing behavior has been on Mac OS for about 15 years
| now.
|
| Mac OS route selection always takes into account the source
| address of the IP packet in addition to the routes in the routing
| table.
|
| If a socket binds to a particular address, the Mac OS kernel will
| choose routes associated with the interface that address is on
| and ignore the others.
| tinus_hn wrote:
| Would be nice if someone who actually knows what he's doing
| looked into this. This guy might be on to something or he might
| be creating a whole lot of drama about nothing.
| rootusrootus wrote:
| For sure. I appreciate when someone admits they don't know
| something, because that is honest. But OTOH, there was a fair
| amount of "I don't know why this does what it does" in this
| blog post. I'd like to see this same topic worked up by someone
| with more knowledge.
| hkpack wrote:
| 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.
| Mo3 wrote:
| The article is really good and informative, but that title man..
| I almost didn't click and read it because of it
| martin1975 wrote:
| This should trend to the top of HN. Apple bills themselves as a
| privacy-centric company. I hope they clean this up asap.
| dfox wrote:
| iOS devices create lot of weird traffic on local network. And
| the only meanigful-ish other packet trace seems like APNS
| subscription update and some kind of iCloud traffic, there is
| probably zero reason why would you want that to go through
| "VPN" tunnel.
| kogir wrote:
| I think Apple is transparent about Always on VPN (blocking
| traffic except over the tunnel) requiring provisioning using MDM
| tools. Apple Configurator is free and allows anyone to set this
| up.
|
| Any other VPN is just best effort.
|
| https://support.apple.com/guide/deployment/vpn-overview-depa...
| cmeacham98 wrote:
| That Apple documents that 'normal' VPNs are broken on iOS
| doesn't change the fact that they're broken.
| mike_d wrote:
| VPNs were always meant to carry internal traffic to a private
| network, not the public internet (hence the name Virtual
| Private Network).
|
| The fact that a VPN server can send you a route for 0.0.0.0/0
| always was and always will be a happy accident.
| Aaargh20318 wrote:
| > VPNs were always meant to carry internal traffic to a
| private network, not the public internet
|
| This. And the idea that these so called 'VPN' services
| somehow improve your security and privacy on the internet
| is laughable. All they do is let you get onto the public,
| untrusted, internet through a different on-ramp. There is
| no point to them. The internet is just as untrustworthy
| through a VPN service as it is through any other internet
| connection.
| w14 wrote:
| > There is no point to them.
|
| What about this?
|
| "Under the provisions of the Investigatory Powers (IP)
| Act, it is now possible for the Law Enforcement Agency
| (LEA) community to lawfully obtain Internet Connection
| Records (ICR) in support of their investigations.
| Following the completion of some initial trial
| activities, work is now underway to provision a national
| ICR service."
|
| https://www.digitalmarketplace.service.gov.uk/digital-
| outcom...
| genewitch wrote:
| i will have agree with your definition, but the issue here
| isn't with the nomenclature, it's with the bill of goods
| being sold as a service.
|
| what people expect, and what is being sold, is an encrypted
| tunnel that all traffic goes through, to an endpoint. That
| this is called "VPN" is irrelevant.
|
| I have a GL-iNet Mango that i have setup to provide "always
| on wireguard" to a computer in a datacenter i control the
| public IP for. I haven't tested, but i expect all data sent
| to and from any devices connected to that Device's SSID to
| be tunneled via wireguard to the computer in the DC, and
| therefore, to all outside observers the DC is where my
| device is. Obviously the ISP can see the session, but since
| they have no say over the DC endpoint, they have no way of
| knowing what the traffic is or where it's going. It could
| just be me doing SSH or video streaming or backups to and
| from the datacenter, or i could be watching netflix or
| youtube.
|
| In that circumstance, an iOS device shouldn't be able to
| leak my local network's ostensible "public IP", since the
| actual transport layer is outside of the iOS device's
| control.
|
| With all of this being said, i don't think there's any way
| to guarantee that leaks are impossible without literally
| air-gapping your devices and forcing all traffic through
| something that cannot communicate with anything but the
| remote endpoint - that is, if the wireguard connection
| fails, all pings fail, all TCP/UDP/etc traffic times out,
| and so on. In this manner, probably all things sold as
| "secure VPN" or as a service that does that are scams. This
| is the issue that TFA is complaining about.
|
| in a situation where it's life and death - i would find an
| open wifi access point and connect a wireless bridge device
| (e.g. tp link TL-WR802N), with an STP ethernet cable to
| something similar to the gl-iNET mango, with 100% forced
| wireguard connectivity. I'd only consider this viable after
| doing tshark or tcpdump on the server i control log access
| to, to verify that my (local) MAC address and/or stuff like
| webrtc or whatever are blocked/dropped.
|
| sorry for the length, but i didn't want to make multiple
| comments all over the threads.
| cmeacham98 wrote:
| I'm not sure what your point is here?
|
| To be clear, is what you're saying that it is ok for VPNs
| to be broken (or at least less bad) because their most
| popular usage isn't what they were originally intended for?
|
| If that wasn't your point, what was?
| badrabbit wrote:
| You are wrong on this, the private part indicates the
| privacy it provides not the destination.
|
| Site to site VPNs do what you are saying where you connect
| one network to another. There have always been client-
| access VPNs whete hosts privately access some network. The
| Internet is a network and VPN provide private access to it,
| as in your privacy risk is reduced or eliminated until the
| point of the VPN termination.
|
| I have argued about VPNs again and again the only thing I
| keep learning is how useful they are.
| happyopossum wrote:
| > You are wrong on this, the private part indicates the
| privacy it provides not the destination.
|
| Sorry - that's just not the case, you're retconning VPN
| terminology. VPNs were originally implemented to replace
| dedicated WANs and dial-in access to private networks -
| they were not originally designed to provide privacy for
| individual access to the Internet. Heck, even the RFC for
| VPN terminology makes that clear (RFC 2764 is over 20
| years old).
|
| Oh, and this: > There have always been client-access VPNs
|
| If your first exposure to VPNs was from shady privacy-
| snake-oil salesmen, I can see how you'd think this, but
| take it from the people who were there before client
| based VPN access was even a thing: Site-to-Site VPN was
| the original use case for VPN, and you didn't waste
| tunnel bandwidth (encryption chips were slow and
| expensive back in the day) routing general internet
| traffic over your tunnel...
| na4ma4 wrote:
| > the private part indicates the privacy it provides not
| the destination.
|
| I wouldn't entirely agree with that (although out of
| context I do agree).
|
| It's a Virtual Private Network connection, you create a
| Virtual (not physical) Private Network (between your
| device and another device/server) there's no real
| difference between a site-to-site VPN and a client-access
| VPN other than if the devices at each end route more than
| just the partner traffic over the private network.
|
| If I connect a "site-to-site VPN" between my computer and
| your computer, if I add a route to send all traffic for a
| particular network to your computer as the next hop, that
| makes it "client-access" for that particular network, if
| I add a default route it then sends any internet request
| I make to your device as the next hop.
|
| If your device decides to forward the packets (and
| probably NAT them) then I now have some privacy for my
| internet traffic.
|
| VPNs were originally designed to replace dial-up modem
| connections since the internet was becoming more
| ubiquitous and it would be far cheaper for someone to
| connect to their local ISP then use a VPN to connect to
| their remote network (either personally or usually
| between sites), than dial directly to their other site
| (also it was usually far cheaper for one internet
| connection than a bank of modems and ISDN lines (if you
| wanted 56.6Kbps or 64Kbps connections)
| anyfoo wrote:
| > You are wrong on this, the private part indicates the
| privacy it provides not the destination.
|
| I remember using VPNs long before, to my knowledge,
| people were using them in the way you describe, and I was
| always under the impression that the "P" in VPN meant
| "connecting private networks" together over the Internet.
|
| This document from 2001 agrees with me:
| https://docs.microsoft.com/en-us/previous-
| versions/windows/i... "From the user's perspective, the
| VPN connection is a point-to-point connection between the
| user's computer and a corporate server. The nature of the
| intermediate internetwork is irrelevant to the user
| because it appears as if the data is being sent over a
| dedicated private link."
| xoa wrote:
| I hope Wireguard makes it into iOS/macOS at some point. Still
| early days relative to other protocols of course but it's so
| much simpler and more reliable (even beyond the security
| benefits). I use it extensively on both platforms for access to
| my own networks and services nowadays.
| codedokode wrote:
| I am not going to use WireGuard because I don't want
| unncessary code in the kernel. It is just unsafe.
| matthewmacleod wrote:
| There are several things wrong with this - to start with,
| WireGuard isn't in the iOS kernel.
| KindOne wrote:
| It already exists in the App Store. I've been using it since
| April 28th of this year.
|
| ios/ipad:
| https://apps.apple.com/us/app/wireguard/id1441195209
|
| macos: https://apps.apple.com/us/app/wireguard/id1451685025
| isatty wrote:
| WireGuard is already available on both platforms - or do you
| mean kernel space WireGuard without an additional app?
|
| Fwiw the existing app integrates seamlessly into the apple
| ecosystem.
| mdeeks wrote:
| I think the OP means so that it can be used without an app
| and so it can be used with Apple's "Always On VPN" setup.
| Right now I believe "Always On VPN" only works with the OS
| supported VPNs: IKEv2, L2TP, SSL VPN, and Cisco IPSEC
| https://support.apple.com/guide/deployment/vpn-overview-
| depa...
| happyopossum wrote:
| Nope, there are a ton of 3rd party SSL/other VPN clients
| that use the same frameworks that can be set to always on
| - the app just has to be written that way.
|
| Consumer VPNs typically aren't.
| isatty wrote:
| The WireGuard app works with always on.
| rapind wrote:
| Seems targeted at Enterprise customers, not your average
| consumer.
|
| Kind of a big deal that likely 90%+ of iOS VPN app users assume
| they're private when they're not. False advertising IMO, and
| Apple is getting their 30%.
| Youden wrote:
| The issue in the article isn't that the VPN is sometimes
| inactive, it's that when the VPN is active, some traffic
| escapes the VPN.
|
| As far as I can see the linked page doesn't say that your VPN
| will leak unless you're using Always On.
|
| Plus, that page documents the VPN features built in to iOS
| itself, not VPNs provided by apps.
| jart wrote:
| 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.
| mkingston wrote:
| That's a clever thought. Do you know whether connections
| could be established outside the tunnel after you disable
| airplane mode but before the tunnel is re-established?
| fzfaa wrote:
| I remember recently using Cloudflare Warp and using one of those
| webpages that tell you your IP address and it showed my real IP
| address. It was a bit weird.
| vbezhenar wrote:
| Warp is not designed to hide your address. If website is behind
| cloudflare, it'll know your IP address. If website is not
| behind cloudflare, your address will not be available.
| asldjajlfkj wrote:
| There was some communication (forum,discord) that this would
| change in the future. Apparently the plan was or is to hide
| the IP from pages on Cloudflare as well. But no idea if
| that's implemented yet.
| ceejayoz wrote:
| That doesn't sound right.
|
| https://blog.cloudflare.com/warp-for-desktop/
|
| > WARP was built on the philosophy that even people who don't
| know what "VPN" stands for should be able to still easily get
| the protection a VPN offers.
| tedunangst wrote:
| Crazy that cloudflare's marketing wouldn't be entirely
| forthcoming.
| Shank wrote:
| > From a technical perspective, WARP is a VPN. But it is
| designed for a very different audience than a traditional
| VPN. WARP is not designed to allow you to access geo-
| restricted content when you're traveling. It will not hide
| your IP address from the websites you visit. If you're
| looking for that kind of high-security protection then a
| traditional VPN or a service like Tor are likely better
| choices for you.
|
| See: https://blog.cloudflare.com/announcing-warp-plus/
| ceejayoz wrote:
| "get the protection a VPN offers" seems like poor
| wording, then.
| fzfaa wrote:
| Wow, that is really shady.
| Varloom wrote:
| secondcoming wrote:
| I downloaded that recently to check it out and it crippled my
| 5G speeds too.
| lizardactivist wrote:
| The iPhone was never made to be truly secure, so this is to be
| expected I suppose.
| dfox wrote:
| I think that the value of this article is perfectly summarized by
| the sentence "Not sure what SYN is."
| [deleted]
| jgtrosh wrote:
| Is Android better in this regard?
| TazeTSchnitzel wrote:
| Airplane Mode used to be a true "all wireless disabled" mode, but
| Apple have relaxed it a bit over time, possibly because it's so
| frequently used and there are so many services provided by WiFi
| and Bluetooth now that aren't related to the Internet (e.g.
| connecting to AirPods or an Apple Watch). They also relaxed what
| turning off WiFi and Bluetooth in the Control Center (separately
| from Airplane Mode) do, so that things like AirDrop still work.
| But I think the options in the Settings app are still meant to
| truly turn off wireless, rather than just mostly?
|
| Also: if Settings says you're connected to a WiFi network, but
| you don't see a WiFi icon at the top of the screen, I think that
| means there's no working Internet connection.
| derobert wrote:
| I think airplane mode is intended to comply with the rules for
| using the device on an airplane. That used to be no radios
| whatsoever (and device turned off during takeoff and landing).
|
| The rules on aircraft changed, so the feature was updated.
| happyopossum wrote:
| > Also: if Settings says you're connected to a WiFi network,
| but you don't see a WiFi icon at the top of the screen, I think
| that means there's no working Internet connection.
|
| Yup.
| hsbauauvhabzb wrote:
| I don't care for VPNs but I do want an adblocker. What are my
| options aside from using a public pihole dns or a vpn to a
| private dns server?
| ecliptik wrote:
| Tailscale + Pihole works well,
|
| https://tailscale.com/kb/1114/pi-hole/
| giobox wrote:
| I use this setup to get mobile adblock while on Verizon (iOS
| sadly has never let you override the default DNS server for
| cellular, just wifi). It works more or less perfectly, albeit
| with a noticeable hit to device battery life... so much so my
| wife who otherwise loves PiHole on the home network refuses
| to use it on her iPhone.
|
| Using iOS's built in support for browser adblockers is
| largely as effective and doesn't come with the battery life
| hit.
| haunter wrote:
| Firefox Focus then in Settings > Safari enable it as a content
| blocker
| LeoPanthera wrote:
| Ad blocking is entirely possible. Safari supports ad blocking
| natively. OS-level blocking can be achieved via a DNS filter
| which can be run on-device. I use AdGuard Pro to do both:
|
| https://adguard.com/en/adguard-ios-pro/overview.html
|
| But other choices are available too.
___________________________________________________________________
(page generated 2022-08-16 23:00 UTC)