5 ms·

Sorry if I seem stupid but what are the security implications ? As far as I understood the attacker can : - Detect an active VPN connection (and maybe close i

Sorry if I seem stupid but what are the security implications ? As far as I understood the attacker can : - Detect an active VPN connection (and maybe close it/monitor it) - Attempt to inject packets : for this part I am skeptical of the usefulness. The connection between the server and the client are normally encrypted, meaning that the injected packets will be dropped or can be used to forcefully close the connection making it a DoS attack.

ratiolat 7y ago
Perhaps this means that the attacker can insert traffic and kernel handles it like it came from the tunnel interface? ELI5 would be in order indeed.
loeg 7y ago
They can inject TCP data which looks — to the application — like it came over the VPN, but it didn't actually. The vulnerability here is unencrypted TCP streams running (purportedly) over a VPN. Not TLS streams (HTTPS and HTTP/2.0+), unless you've also got a TLS 0-day. (And maybe also unencrypted UDP sessions and unencrypted services, but that's less clear to me.)
- bscphil 7y ago
  Oh my god. I had to read this twice, but what you said here finally made me realize the severity of this. Thanks. (I also now understand why the kernel developers might be looking at it as a vulnernablity. Neighbors in your subnet should not be able to inject packets into your computer's internal routes.)
tetha 7y ago
> The connection between the server and the client are normally encrypted Keyword: Normally. What about DNS? DNS without DNSSEC via an untrusted AP cannot be trusted, that's for certain. Hence, you recommend your user to activate VPN first to avoid such attacks because now it's encrypted. Suddenly, that might change and your trusted-page.internal resolves to a different hostname. This /should/ be preventable via HSTS and certs for example with HTTP, but those are assumptions again. Or what about RDP? It's not encrypted, so you hide it in a VPN - mostly due to the cleartext password. But suddenly there's a vector that might be able to inject data into an RDP stream inside a VPN connection. > - Detect an active VPN connection (and maybe close it/monitor it) Not just that. They can detect TCP connections inside the VPN connection. Hence, you can start tracking if users of an access point accept anti-gov.com even if they go through a VPN. It might be detectable on the client side and it should be possible to mitigate this via configuration, but that's still plenty scary.
- loeg 7y ago
  Or in short, the authentication premise of VPN-routed traffic can be violated by an attacker without knowing the authentication keys, due to some misalignment of (in some cases, valid) routing behavior and VPN integration.

ratiolat 7y ago

Perhaps this means that the attacker can insert traffic and kernel handles it like it came from the tunnel interface? ELI5 would be in order indeed.

loeg 7y ago

They can inject TCP data which looks — to the application — like it came over the VPN, but it didn't actually. The vulnerability here is unencrypted TCP streams running (purportedly) over a VPN. Not TLS streams (HTTPS and HTTP/2.0+), unless you've also got a TLS 0-day. (And maybe also unencrypted UDP sessions and unencrypted services, but that's less clear to me.)

bscphil 7y ago
Oh my god. I had to read this twice, but what you said here finally made me realize the severity of this. Thanks. (I also now understand why the kernel developers might be looking at it as a vulnernablity. Neighbors in your subnet should not be able to inject packets into your computer's internal routes.)

tetha 7y ago

> The connection between the server and the client are normally encrypted Keyword: Normally. What about DNS? DNS without DNSSEC via an untrusted AP cannot be trusted, that's for certain. Hence, you recommend your user to activate VPN first to avoid such attacks because now it's encrypted. Suddenly, that might change and your trusted-page.internal resolves to a different hostname. This /should/ be preventable via HSTS and certs for example with HTTP, but those are assumptions again. Or what about RDP? It's not encrypted, so you hide it in a VPN - mostly due to the cleartext password. But suddenly there's a vector that might be able to inject data into an RDP stream inside a VPN connection. > - Detect an active VPN connection (and maybe close it/monitor it) Not just that. They can detect TCP connections inside the VPN connection. Hence, you can start tracking if users of an access point accept anti-gov.com even if they go through a VPN. It might be detectable on the client side and it should be possible to mitigate this via configuration, but that's still plenty scary.

loeg 7y ago
Or in short, the authentication premise of VPN-routed traffic can be violated by an attacker without knowing the authentication keys, due to some misalignment of (in some cases, valid) routing behavior and VPN integration.