Back in August, a security researcher discovered a significant flaw in iOS VPN apps, and a second researcher has now discovered another minor flaw.
The first concern was that having a VPN app close all existing connections, but it didnt. The second issue is that many Apple applications transmit private data outside the VPN tunnel, including Health (above) and Wallet.
How iOS VPN apps (are supposed to) work
Normally, when you connect to a website or another server, your information is first sent to your ISP or mobile data carrier. It then sends it to the remote server. That means that your ISP can see who you are, and which sites and services you are accessing, while also putting you at risk from unprofessional Wi-Fi hotspots.
Your data is rather transmitted to a secure server by a VPN. An ISP, carrier, or hotspot operator can protect it. All they can see is that you are using a VPN. It''s like using a secret tunnel from your device to the VPN server.
Similarly, your IP address, location, or other identifying data aren''t accessible to the websites and servers you are accessing. Instead, your internet appears to be from the VPN server.
Flaw 1: Failing to close existing connections
Once you activate a VPN app, it should immediately close all existing (non-secure) data connections and then open them inside the secure tunnel. This is a high-quality process used by any VPN provider.
Michael Horowitz has revealed that non-secure connections are not only successful, but iOS does not permit VPN applications to close all existing connections.
Flaw 2: Many Apple apps are excluded
Tommy Mysk, a developer and security researcher, read our article and was amazed.
He conducted his own tests, looking into which IP addresses were being accessed when a VPN was active, and discovered that many stock Apple apps ignored the VPN tunnel and instead communicated directly with Apple servers.
iOS 16 does not communicate with Apple services outside an active VPN tunnel. Worst, it leaks DNS requests. #Apple services that have escaped the VPN connection include Health, Maps, and Wallet.
ISPs or hackers who are executing man-in-the-middle attacks, using easy-to-create fake Wi-Fi hotspots, are at jeopardy.
The tools that provided the leakage were:
The majority or all of the information required by these apps might include extremely personal information, from health concerns to payment cards.
With Wireshark in capturing the IP addresses accessible by the iPhone, you may watch his experiment:
We confirm that iOS 16 does communicate with Apple services outside an active VPN tunnel. Worse, it leaks DNS requests. #Apple services that fail the VPN connection include Health, Maps, and Wallet. We used @ProtonVPN and #Wireshark. More on this video: #CyberSecurity #Privacy pic.twitter.com/ReUmfa67ln
Mysk (@mysk_co) October 12, 2022
Android behaves in the same way with Google services, according to Mysk.
I know what you want yourself, and the answer is yes. Android communicates with Google services outside of an active VPN connection, even with the options Always-on and Block Connections without VPN. I used a Pixel phone running Android 13.
Appears intentional
I asked Mysk if they believed both companies would do this intentionally, perhaps to prevent an app from redirecting traffic or for performance reasons?
Yes, I believe it is deliberate. However, the amount of traffic we saw was much higher than we anticipated. There are apps on the iPhone that require frequent contact with Apple servers, such as Find My and Push Notifications. However, I do not see an issue of tunneling this traffic in the VPN connection.
If Apple has security concerns about VPN apps, he claims that it is easily addressable.
I believe that VPN applications should be classified as browsers and require an additional approval and entitlement from Apple.
Apple is concerned that a VPN service slowing traffic does not appear to be a concern, as push notifications use the VPN tunnel.
During iOS 14, we conducted a similar experiment and discovered that Push Notifications bypassed the VPN. It is no longer the case in iOS 16.