Trust broken when using VPN on iOS Exchange ActiveSync system client
I’ve come across what appears to be a design/function choice in iOS, but is inadvertently breaking the trust between VPN services and iOS users.
I’ve tested this using F-Secure’s Freedome VPN app as well as the Tunnelbear VPN app on iOS 11.2.5.
I don’t believe this to be an issue with the VPN apps per se. Instead, it’s a problem with how iOS is enabling it’s built-in system service, namely the Exchange ActiveSync client, to utilize the cellular data channel even while the iOS device is connected to wifi.
It took me a while to find out whether Apple allows apps to “force” data out the cellular channel even while wifi is enabled and connected. It turns out it is possible to code this in an iOS app using low-level APIs. But the caveat is Apple doesn’t have to accept your app. I came across a helpful post in the Apple Developer forums that does a better job of explaining this here.
It’s counter-intuitive for users to think their (usually metered) cellular data channel would be used by their mobile device for internet communications while they are connected to wifi. There does exist the “wifi-assist” feature that would auto-switch to cellular when wifi connectivity is determined poor enough (you can tell when this has happened by looking at the wifi/data icon in the top left corner), which can be toggled on or off. But using cellular when wifi is healthy and while the wifi symbol is clearly evident in the top left corner of the screen? Not intuitive, nor expected by the majority of users.
This becomes even more problematic for users of VPN services. There are 2 broad categories of consumer VPN user: Privacy/security conscious types and those that wish to get around geo-blocking services.
For the privacy-minded, it may be very surprising to learn that while their iOS device is connected to wifi+VPN, the unprotected cellular data channel is still being used for Exchange ActiveSync communications. Something interesting to note in the forum link referenced above:
Ok, so WWAN (cellular channel) can be used by critical services such as push notifications…which is a category one would reasonably expect the EAS client to fall under. The big problem here? This WWAN connection that remains active does not use the VPN service. This exposes the mobile device cellular data ip address and communications across the cellular interface.
I came across this while looking at my EAS logs for an unrelated issue. I was alarmed to see both my VPN ip and my unprotected cellular data ip showing up in the logs mere seconds apart.
Here’s an EAS log entry from my VPN ip:
And another log entry 2 seconds later from my cellular data ip:
Here are the corresponding tcpdump entries taken from my external OWA load-balancer. The first corresponds to the tcp session from my VPN ip:
And the second entry corresponding to the tcp session from my unprotected cellular data ip:
The EAS client in iOS was added back in 2008/2009. It is a system service in iOS. You can view system services that are allowed to use cellular data in iOS 11.2.5 by navigating to Settings > Cellular > “Cellular Data” heading and scroll aaaaallllll the way down to “System Services”:
That’s a large list of system services that use cellular data. I have only tested EAS so far, but what if this complete list of system services behaves in the same manner: not respecting the VPN session established on the wifi (the user’s clear intention to use VPN) and still uses an unprotected cellular interface at the same time?
To me, that seems like a privacy issue.
