iOS allows DNS request to escape the VPN tunnel
twitter.comAlways-on VPN that tunnels everything requires MDM commissioning. It's documented by Apple.
See the section "Always On VPN": https://support.apple.com/guide/deployment/vpn-overview-depa...
Is it dubious that Apple doesn't let VPN apps do this as well? Maybe. But this is known and documented.
So many times law enforcement take advantage of this too, to fingerprint devices. The number of people caught because someone leaks packets outside the VPN for a few seconds because they forgot to configure VPN to disable outbound data if VPN drops... I've long wondered if making always on VPN require MDM provisioning on iPhones was a sop to police/criminal investigation forces, especially after Apple's public fights with the FBI over matters like the locked San Bernadino phone etc. I bet very few crims installing VPNs are aware of that apple support doc.
If this was working as it arguably should and could be done easily without MDM provisioning, it would remove a genuinely useful avenue for law enforcement and add more fuel to the the FBI's dislike for Apple's security features.
You used FBI and the term law enforcement in the same sentence. Sad to say the respect I once had for what the FBI likes and dislikes has been greatly diminished by the political bias that seems to influence it’s actions. I look forward to the day when they are strictly law enforcement and without political agenda. We as a country need them.
I wonder if there's a small bit of pressure on the device manufacturers to keep DNS leaks happening for consumers. I'd love to be a fly on the wall at some of the NatSec-level conversations.
Should it be expected that individual users should be familiar with corporate deployment documentation just to know that their VPN app they bought actually leaks?
I assume this is because an evil VPN app could refuse to allow the phone to connect to apple for updates.
That would then mean the app maker can effectively steal control of the phone from Apple.
I'm not following. Your link appears to be specific to corporate environments. The title of the document is:
"VPN overview for Apple device deployment."
It further states "Secure access to private corporate networks is available in iOS ..."
An individual iPhone user who is not using a company issued device would not be beholden to MDM restrictions or profiles. Nor would access to "private corporate networks" be necessarily relevant.
It's written that way because the target audience is enterprise IT folks who are managing fleets of employee devices, but you can freely use MDM profiles as a consumer. It's certainly not user-friendly which is why I commented that the way it works for VPN clients installed as apps could be seen as a dubious implementation.
You can create and install mobileconfig profiles on any iPhone, even unmanaged.
Yes and if it's an unmanaged device it is by definition not being managed by an MDM. The title of the link makes it clear that the context is "device deployment." Further the section un the linked article states"Always On VPN"
">Always On VPN activation requires device supervision."
Supervision denotes a managed device"
"Supervision generally denotes that the device is owned by the organization, which provides additional control over its configuration and restrictions."[1]
No regular non-corporate iOS device user is ever likely to be downloading manually distributed mobile profiles.
[1] https://support.apple.com/guide/deployment/about-device-supe...
I once was invited to install a profile as a beta testing user. I guess this process is now streamlined through the TestFlight app though.
> We confirm that iOS 16 does communicate with Apple services outside an active VPN tunnel. Worse, it leaks DNS requests. #Apple services that escape the VPN connection include Health, Maps, Wallet.We used @ProtonVPN and #Wireshark
Wallet at least has a semi-plausible non-evil answer: Users who kick their VPN on to another country and try to use apple pay at checkout will unexpectedly get declined (because the purchase would appear to be coming from another country perhaps?).
Apple could fix that with proper UI though.
I don't see any reason why Apple Pay would use IP geolocation like that when it's running on a device that has GPS.
Fraud detection happens on the server side. The IP address is more reliable than GPS, because the client can fake GPS at any time.
But Apple Pay doesn't require internet (on the phone).
> I don't see any reason why Apple Pay would use IP geolocation like that when it's running on a device that has GPS.
One reason is that GPS doesn't work well (or at all) indoors, through cell-tower geolocation should work well enough for that case.
A compromised device can send a false location or the user may have disabled location. Geolocation has relatively predictable failures.
> I don't see any reason why Apple Pay would use IP geolocation like that when it's running on a device that has GPS.
I don't think contactless Apple Pay actually uses device geo[1] for authorization, but it's still worth noting that iOS devices without cell connectivity (ie WiFi-only iPads) don't have GPS anyway.
You can use Apple Pay on websites in Safari, though, which IIRC doesn't require location permissions to work.
1. You have to be able to use it in the same places you'd use a normal card, which means you can't rely on network connectivity of any kind.
Some Visa cards do [1] now, https://pbs.twimg.com/media/FQyVcUHXEAMSKbt?format=jpg&name=... and can refuse authorisation if it's not sent.
Apple's statement was "to prevent the sharing of fraud prevention assessments with your payment card network, you may select another card". I removed my Visa cards from Apple Pay.
I’d never come across that before, but quickly looking at the statement from Apple it seems like this only applies to browser and in-app purchases, not contactless transactions where you’re using your phone in lieu of a physical card:
"For cards with certain enhanced fraud prevention, when you attempt an online or in-app transaction, your device will evaluate information about your Apple ID, device, and location (if you have enabled Location Services), to develop fraud prevention assessments, which are used by Apple to identify and prevent fraud."
GPS can be easily spoofed.
Back in the university days, we (me + a few friends) used to get some radios and antennas to create a signal stronger than the one coming from satellites. It was always fun when the semester started and all freshmen were using Google Maps to navigate through the campus, but the map always showed their location in North Korea. Good ol' times.
I thought GPS worked by triangulation? How did you use one transmitter to specifically misdirect receivers to believing they were in North Korea?
> some radios and antennas
Still an impressive feat.
I'm calling shenanigans. I used to work in a lab where we had GPS repeaters to test consumer equipment. That alone costs big bucks. And, we had the FAA come down on us big time, because our GPS repeater broadcast outside the building too far and we got into some hot water.
If you were spoofing GPS campus wide over 1.544 GHz and had all your GPS sentences correct, with simple radios and antennas... and you hadn't got in trouble with Uncle Charlie or the FAA....
Just for clarification, it was not campus wide, only a small part between some institutes. Also, the hardware was not consumer grade thanks to the electrical engineering, geodesy and geoinformatics labs.
Still, it was illegal and could get everyone expelled, so I wouldn't do it again.
Spoofing GPS is trivial. Getting caught or not is a toss of the coin
Cheating the location on my phone is gravy.
Broadcasting an RF signal to spoof GPS (and especially across a campus), that my friend, is not trivial or cheap.
> not trivial or cheap
From your previous comment, it sounds like your experience may have been from a while ago? In 2022, it is fairly trivial and cheap: https://github.com/osqzss/gps-sdr-sim
I can not ;^) personally confirm that this works with a HackRF, which is like $300, but probably also with any other reasonable tx-capable sdr.
Trying to set up an alternate 3d volume of GPS space sounds very difficult.
But broadcasting a loud signal that tells everyone in range that they are at the same exact point doesn't seem too hard to me. Couldn't that even be as simple as replaying a single-antenna recording taken somewhere else?
Yes exactly.
Doesn't work well with some receivers that cache data from the real network and stay locked onto the much weaker real signal. But works with most receivers.
Isn't it only matters what payment terminal bank's country is?
I disagree completely.
* first, a purchase shouldn't require an internet connection. Humans have been doing commerce for millennia without it, and we have sophisticated pub/priv key schemes to figure this all out.
* second, it's a security hole. It's either a VPN or it's not.
Add Android to this: https://mullvad.net/en/blog/2022/10/10/android-leaks-connect...
Android only leaks connection checks.
While on IOS any system app doesn't use the VPN or DNS requests.
VPNs are useless on iOS, and its made to be this way, again the "privacy OS" isn't privacy focused at all.
From TFA: "Apple also said that the Always On VPN feature of MDM offers a fix. Mobile Device Management is over my head. […] According to Apple, MDM lets the corporate IT techies force all data leaving an iOS device to go to the company. But, MDM is is not available to consumers."
There appear to be several easy-to-use MDM solutions that cater to small businesses that would also work fine for families. Apple even has one, Apple Business Essentials.
That is like saying you can only lock your door if your neighbor has a key as well.
Related ProtonVpn article:
"We’ve raised this issue with Apple multiple times. Unfortunately, its fixes have been problematic. Apple has stated that their traffic being VPN-exempt is “expected”, and that “Always On VPN is only available on supervised devices enrolled in a mobile device management (MDM) solution”. We call on Apple to make a fully secure online experience accessible to everyone, not just those who enroll in a proprietary remote device management framework designed for enterprises."
https://protonvpn.com/blog/apple-ios-vulnerability-disclosur...
For those looking for a workaround, you can get a VPN router in my case, a GL.iNet Mango[0] router.
The great thing: even if the VPN connection drops, it doesn't leak your real/naked IP, and also /all/ traffic on an iOS device has to pass through the VPN. No special exceptions for Apple traffic.
The only caveat is you have to carry this when traveling, which means if you're traveling light, carrying this around could be burdensome. If you are at home most of the time though, such a router is invaluable.
[0] https://www.amazon.co.uk/GL-iNet-GL-MT300N-V2-Converter-Pre-...
And remember... This is WiFi.
But over the LTE connection, which is far harder to sniff without very expensive equipment, it could be doing almost anything. And you can't even check what it's doing.
can you not sniff it with services like nextdns?
I assume that anything evil going on wouldn't use the configured DNs servers... Just like things also bypass the configured VPN...
This type of feature is useful for places like China that need to imprison people that speak out against the ccp.
Our tech overlords are not immune to pressures if we teach them how it is abused.
That is why a detached but portable WiFi/5G router is for … to block these Apple shenanigans …
While your phone is in Airplane mode and regular (but your router’s) WiFi only network
Last that I heard, Raspberry Pi with VPN installed along with PiHole that you SSH/VNC (via iOS app) in to is your best option.
This doesn't stop apps using things like DNS over HTTPS etc. PiHole works pretty great today, but developers are getting sneakier and sneakier about how to obtain outbound DNS. It's not just unencrypted port 53 all the time anymore. Eventually devices will get the IP for the DNS record they want just fine, if they really want to.
PiHole arguably is getting less effective with each passing year as alternate DNS resolution methods like DNS over HTTPS etc gain traction, and defeating DNS over HTTPS is s a whack-a-mole game today, all you can really do is try to blacklist known DNS over HTTPS server IPs, which is a running battle.
My assumption is all ad driven applications who depend on resolving advert domains correctly to serve the ad content will one day all utilise methods like DNS over HTTPS to stop products like PiHole reducing revenue.
Apple has implemented a way for developers to do this already with DoT. If you are running a pihole I suggest you block. _dns[.]resolver[.]arpa. If not and your upstream DNS resolver supports DoT, this will tell clients who your upstream provider is and then they will send DoT requests out, bypassing your pihole. This is part of so called Discovery of Designated Resolvers (DDR).
> PiHole arguably is getting less effective with each passing year as alternate DNS resolution methods like DNS over HTTPS etc gain traction, and defeating DNS over HTTPS is s a whack-a-mole game today, all you can really do is try to blacklist known DNS over HTTPS server IPs, which is a running battle.
Aren't blocking ads another whack-a-mole? So it seems like more of the same.
Also, aren't there proxies that you can setup that can inspect HTTPS connections (so long as you install the proxy's cert on your machine). I suppose the whack-a-mole might be more practical if a few people used those regularly along with some kind of automated scanning for DNS over HTTPS.
The key difference is the point of control:
For PiHole today, most everything comes over port 53, and thus easy to track, monitor and block as required.
Tomorrow, DNS requests can be on any port, to any server, on any protocol. This makes trying to use a single point of control like the PiHole so much harder than it was in the past. Who is to say next week its HTTPS as the encrypted transport for DNS? Use whatever bizarre encryption scheme you like. It's your app... The app can just ignore whatever DNS server you suggested via DHCP or whatever and go back to its homebrew domain name resolution system.
> Who is to say next week its HTTPS as the encrypted transport for DNS?
That ship has already set sail, my friend :(.
Eventually ads, tracking, etc are just going to be proxied by the app server, along with normal app server traffic, to one IP and you can't do much effective filtering in the end.
> Also, aren't there proxies that you can setup that can inspect HTTPS connections (so long as you install the proxy's cert on your machine).
It's common for apps to prevent this with certificate pinning. They'll ignore the certs you've installed manually and will only connect to servers with certs signed by their in-house certificate authority.
> Aren't blocking ads another whack-a-mole?
Yes, but the mole-whacker is whoever controls the software doing the rendering. So on a personal computer, the ads are the moles. But on a locked down "phone", the user is the mole.
We will need to keep a list of DNS IPs to block access through ports 80 and 443.
And what happens when they start changing the port? It's a battle no one ultimately can win, in short term. The technical options available to get DNS by so many different means are so easy to implement, relatively speaking. Even a really junior engineer can likely invent their own DNS resolution protocol, its one of the simplest APIs to reinvent if all you care about is returning IP address for a given name.
80 and 443 are only used by convention for HTTP/HTTPS - you can use whatever the hell you like. There's also the option to not use HTTP(S) or DNS at all to obtain addresses, the list of ways you can avoid traditional methods is endless. Finally, you can just serve your DNS on same IP as back end of the app - block the IP and the app dies completely, meaning a simple IP block will not work etc etc. It's super easy to write some code that combines tens of methods, ensuring you get that DNS record no matter how hard the user tried to stop you.
FWIW people (including me) already do this, but its a blunt tool and not all that effective in many cases: https://gist.github.com/ckuethe/f71185f604be9cde370e702aa179...
Fine. Block that IP on every port.
I don't think you really appreciate the scale of the problem, when any protocol can be used. Port/IP blocks simply are too blunt now, and once again you are screwed if app provider uses the same IP for illegitimate DNS as legitimate services - you might not be able to block the IP at all and still access the services you need on that device or application. To give one example - imagine if netflix shared video on same IP as their private DNS service. They could even use the same port. Can't block the DNS without blocking the service.
Heaven forbid they use dynamic IP/port allocations too...
SSHing to another machine isn’t a solution, you’re just using a different machine.
The way to solve it and still continue to use iOS is to implement your VPN at the network layer. e.g. use one of those wifi routers with a VPN client built in.
They circumvent this by forcing certain traffic to circumvent your hardened WiFi by using the mobile network radios.
That is a possibility but the last I checked it was not the case.
iOS Airplane Mode
> The way to solve it and still continue to use iOS is to implement your VPN at the network layer. e.g. use one of those wifi routers with a VPN client built in.
That's a little impractical for a phone. You'd have to lug around some kind of VPN-enabled mobile hotspot, plus batteries to power it.
You’re right, it ain’t convenient… but mobile hotspots already have batteries.
Also Google / Android, but that doesn't get the clicks.
That’s because Google doesn’t market “Privacy” as their USP with giant billboards maybe?
Only connection checks.
iOS devices are leaky as hell. I once tried blackholing all requests besides those to a VPN service on a router level, and even then my iPhone would just fall back to mobile data for notifications and other Apple services.
Completely different situation. The iPhone falls back to mobile data if it can't get to the internet over WiFi.
It’s also optional (called “Wi-Fi Assist”).
Strange - I have Wi-Fi Assist disabled, but I still observed the behavior I described, which is why I left the comment to begin with.
I can't even imagine the uproar that would be a thread about Google doing this!
https://mullvad.net/en/blog/2022/10/10/android-leaks-connect... and I'll bet good money Android does the same thing if it can't get internet access over WiFi
I'm not defending Google in anyway, I'm sure they do, and I'd be the first to deride them too. But HN generally has a lot more forgiveness for apple, for some reason.
Apple does a lot of marketing around protecting user privacy better than the competition. In this case, iOS leaks more data than Android.