iOS Vulnerability Prevents VPNs From Encrypting All Traffic

[konqerror]

Well, I can tell you that Anyconnect will tear down any active connections, assuming it’s configured correctly. My work VPN certainly does.

As I said, it can be configured but it is not default behavior and some clients do not even offer the option.

TCP is designed to retry after being torn down. It’s no biggie.

Retry is different. As I said, the connection must be dropped because the 4-tuple has changed. That means, for example, your SSH connection is terminated.

If the application is not OS link-state aware, RFC 1122 says it has to wait at least 100 seconds before dropping the connection. On most OSes, that's been extended to around 15 minutes.

 

[The Cappy]

I got caught out by the fact that if you tether a device to your phone it will bypass the phone’s VPN 😡🤦‍♂️

This definitely seems to violate the principle of least surprise.

 

[Will Tisdale 🎗]

As I said, it can be configured but it is not default behavior and some clients do not even offer the option.



Retry is different. As I said, the connection must be dropped because the 4-tuple has changed. That means, for example, your SSH connection is terminated.

If the application is not OS link-state aware, RFC 1122 says it has to wait at least 100 seconds before dropping the connection. On most OSes, that's been extended to around 15 minutes.

Well, that’s the point isn’t it. The connection has to be dropped, then the TCP connection will be retried.
Pretty sure that iOS apps should be link state aware.

It is default behaviour for Wireguard, OpenVPN if I recall correctly and IKEv2. The connections may not be ‘torn down’ but they are certainly routed to nowhere.

 

[Westside guy]

A TCP connection is defined by its origin IP, origin port, destination IP and destination port, known as its 4-tuple.

per packet, man, per packet.

 

[konqerror]

Well, that’s the point isn’t it. The connection has to be dropped, then the TCP connection will be retried.

On the application layer. Go try it with OpenSSH, it will not "retry" because it doesn't cache credentials and therefore cannot reopen a connection. In any case, your remote session will be killed, i.e. any running jobs in a UNIX OS will be terminated.

per packet, man, per packet.

No idea what you're talking about. What I said is 100% correct and I stand by it.

https://users.encs.concordia.ca/~dongyu/ELEC6851/lec11.pdf

 

[chucker23n1]

I’m sometimes stunned by the upvotes people get for posting incorrect information.

Where by "incorrect", you mean "doesn't fit my expectations".

If a VPN is configured to send all network traffic through the VPN when it’s running - which is typically what‘s done - then all traffic should be routing through it from the moment it’s enabled. Not just connections to new end points established afterward - all traffic.

Keep in mind that this means terminating existing connections. That means canceling downloads, stopping conference calls, etc. In practice, a lot of stuff will not handle reconnection gracefully.

Even if a VPN is configured to just carry traffic to a few specific end points (such as the OpenVPN tunnel to our servers, which I’m relying on heavily right now due to the stay at home order currently in place here in Washington): if you’re already connected to one of those end points before establishing the tunnel, you would expect all further traffic to go through the tunnel. The idea that you wouldn’t is ludicrous.

FWIW, the way Tunnelblick (Mac OpenVPN client) works for me in practice is that it will not kill existing connections on connect, but will kill all connections on disconnect, even if those connections are unrelated to the VPN. I find that slightly annoying because it means, for example, that an ongoing Time Machine backup will have to restart from scratch.
[automerge]1585257306[/automerge]

Why on earth would you assume it would “kill” the connection? It should just change the routing of subsequent packets between the two points. Internet Protocol shouldn’t care about the routing.

You cannot "change the routing of subsequent packets". You could if this were, say, SCTP. But we don't live in a world where multihomed connections are practical. In UDP and TCP, you have to close the socket and open a new one.

 

[Will Tisdale 🎗]

On the application layer. Go try it with OpenSSH, it will not "retry" because it doesn't cache credentials and therefore cannot reopen a connection. In any case, your remote session will be killed.



No idea what you're talking about. What I said is correct and I stand by it.

https://users.encs.concordia.ca/~dongyu/ELEC6851/lec11.pdf

Hence why I use mosh or preferably et.
I know OpenSSH doesn’t retry. It’s annoying and not fit for modern networks - it’s about 20 years out of date.
Most other applications successfully retry.

 

[konqerror]

Hence why I use mosh or preferably et.
I know OpenSSH doesn’t retry. It’s annoying and not fit for modern networks - it’s about 20 years out of date.
Most other applications successfully retry.

Still doesn't matter. Go do an actual experiment. Go unplug your modem from the wall and see how long it takes before stuff realizes the connection is dead. It's multiple minutes. A very poor UX.

Same well-known issue with the iPhone trying to hold on to crappy Wi-Fi in the parking lot.

 

[chucker23n1]

Hence why I use mosh or preferably et.
I know OpenSSH doesn’t retry. It’s annoying and not fit for modern networks - it’s about 20 years out of date.
Most other applications successfully retry.

Ehhhh, mosh is the exception rather than the norm. Good luck continuing something as simple and widespread as continuing an HTTP download, for example. You'll get "The network connection was lost". (You may be able to resume it, but case in point, I just did that in Safari, and it broke. )

 

[CarlJ]

iOS used to handle this correctly, then stopped.
Not tearing down existing connections completely undermines the point of a VPN.

Depends on the use - in some situations, you want, say, corporate traffic to go through the corporate VPN, while you want to leave other traffic un-redirected.

 

[Will Tisdale 🎗]

Still doesn't matter. Go do an actual experiment. Go unplug your modem from the wall and see how long it takes before stuff realizes the connection is dead. It's multiple minutes. A very poor UX.

Same well-known issue with the iPhone trying to hold on to crappy Wi-Fi in the parking lot.

That’s a pointless experiment, because the modem is three hops away from the device I’m on now, so of course it’s going to take a while to realise the connection has gone. But that’s entirely not what this whole thread is about.

If I put this iPhone that I’m on into airplane mode, apps will know about it immediately.
Same as if I turn the VPN on on this iPhone (well, they should, but it’s a bit buggy at the min as per the article).
[automerge]1585258135[/automerge]

Depends on the use - in some situations, you want, say, corporate traffic to go through the corporate VPN, while you want to leave other traffic un-redirected.

Yup, but that’s defined by the server policies in my experience, and what the server tells the client to do.

 

[konqerror]

That’s a pointless experiment, because the modem is three hops away from the device I’m on now, so of course it’s going to take a while to realise the connection has gone. But that’s entirely not what this whole thread is about.

No it's not. It's the exact same situation for non-link state aware applications for VPN clients that can trigger OS link-state changes. For applications that are unaware of link-state changes or VPN clients that can't do that or for connectionless UDP applications, the connection looks like a black hole.

Go tell Apple it isn't a big deal and their use of MPTCP is a waste of time.

 

[Will Tisdale 🎗]

Ehhhh, mosh is the exception rather than the norm. Good luck continuing something as simple and widespread as continuing an HTTP download, for example. You'll get "The network connection was lost". (You may be able to resume it, but case in point, I just did that in Safari, and it broke. )

Mosh uses UDP, that’s why, so it just flings datagrams until it gets one back.

Yes, you will have downloads fail when you start a VPN. What do you expect? If you use something like wget you can resume it later, but that depends on the client. Web browser downloads are still very crude, even in 2020.
[automerge]1585258449[/automerge]

No it's not. It's the exact same situation for non-link state aware applications for VPN clients that can trigger OS link-state changes. For applications that are unaware of link-state changes or VPN clients that can't do that or for connectionless UDP applications, the connection looks like a black hole.

But there shouldn’t be any ‘non link-state aware’ applications in iOS. So I’m not sure what you’re on about.

 

[ScottishDuck]

VPNs - why let companies profit from your data for free when you can pay us to profit from your data instead

 

[Will Tisdale 🎗]

VPNs - why let companies profit from your data for free when you can pay us to profit from your data instead

lol, not if you set your own vpn up with endpoints that you trust. But you’re right, these vpn services are dodgy as hell.

 

[mannyvel]

Apps generally shouldn't be able to reconnect, or at least they should reject all reconnection attempts if the attempt is from a different IP. That's just to prevent connection hijacking.

For the actual behavior, Apple should actually terminate all connections when the VPN comes up if and "send all traffic" is checked. In that case you're essentially killing the old interface and pulling up a new one. This is definitely a bug, and might be related to an old split tunnel bug that used to be in iOS a few years ago.

 

[chucker23n1]

Yes, you will have downloads fail when you start a VPN. What do you expect?

I expect, in 2020, that multihoming and transparent resume are solved problem; alas, they're not.

If you use something like wget you can resume it later, but that depends on the client. Web browser downloads are still very crude, even in 2020.

And yet you said, "Most other applications successfully retry.", which clearly isn't true.

 

[Will Tisdale 🎗]

I expect, in 2020, that multihoming and transparent resume are solved problem; alas, they're not.



And yet you said, "Most other applications successfully retry.", which clearly isn't true.

Prove it. Just because a web browser fails a long download it doesn’t mean it won’t retry loading a page. Clearly bs.

 

[Jimmy James]

Relax. It’s just a NSA back door.

Nothing to hide, nothing to fear.
~Joseph Goebbles (Nazi Propaganda Minister).

/sarcasm

 

[chucker23n1]

Prove it. Just because a web browser fails a long download it doesn’t mean it won’t retry loading a page. Clearly bs.

So just to be clear, you think downloading something in a browser is so unusual that it doesn't fall under "most apps"?

 

[konqerror]

Prove it. Just because a web browser fails a long download it doesn’t mean it won’t retry loading a page. Clearly bs.

So you've never seen that page asking you to manually refresh because the last action was a POST? That page that warns you that you might buy whatever is in your cart twice?

You're the one who's arguing for the sake of arguing.

I expect, in 2020, that multihoming and transparent resume are solved problem; alas, they're not.

Legacy protocols; hard to change. Also these features introduce security concerns (hijacking), so you have to be very careful.

 

[bbplayer5]

But your ISP can easily identify the sites you are visiting, as they have knowledge of your end and the far end of the connection. Who uses a VPN for porn anyway? 🙄

DNS over HTTPS. You're welcome.

 

[throAU]

More annoyingly - if an IPSEC VPN terminates in macOS, you get no notification.

Usually this will mean you can't get to your servers at work and you'll notice, but if you're using it for other stuff then maybe not. And you may just fall through to sending the machine traffic "in the clear" without realizing it (if, for example it has both internal private and external public DNS names).

 

[agathezol]

DNS over HTTPS. You're welcome.

The ISP still sees the destination IP and port originating from you, they can get a pretty good idea of what you're up to, even without your DNS queries (though DNS queries are a treasure trove for user profiling).

Total nerd quibble, but the DNS over HTTPS push is just dumb. TLS exists for this reason - DNS over TLS is consistent with how we've secured previously unsecured protocols. There's no reason to tunnel DNS over HTTPS.

 

[throAU]

Total nerd quibble, but the DNS over HTTPS push is just dumb. TLS exists for this reason - DNS over TLS is consistent with how we've secured previously unsecured protocols. There's no reason to tunnel DNS over HTTPS.

Being a network nerd, i generally agree, but apparently with modern HTTPS this request can be pipelined using the same connection as the data for a remote server (that is already connected).

So there's no constant open/close tcp connection setup and tear down.

It can be more performant.