Earlier quoted context omitted.
Even Mullvad?
Mullvad complies, but they go out of their way to keep very little information. If you don't have the information in the first place, you can't surrender it.
Attackers can decloak routing-based VPNs
151–160 of 238 posts
Re: Attackers can decloak routing-based VPNs
#152Earlier quoted context omitted.
What was the side channel attack? There’s no way I’m reading 20 pages of networking for absolute toddlers to try to find it.
The side channel attack lets the attacker determine whether or not you're trying to connect to certain IP addresses over your VPN. If you properly fix this, then even when the DHCP server is performing the attack, the traffic in question still goes through your VPN. If you just mitigate it, then when the DHCP server is performing the attack, the traffic will be dropped. The side channel is that if you just mitigate i…
Re: Attackers can decloak routing-based VPNs
#153Earlier quoted context omitted.
Let's walk through this step by step because there's a lot of confusion on your end. * Step one - You connect your computer to a network - yes you'll get a DHCP lease, and you'll get an ip address, and a default gateway. This default route will be added to your routing table. * Step two - If the TunnelVision exploit (DHCP option 121) is at play you'll also get a few MORE SPECIFIC routes than the default gateway. Thes…
I think you missed a step in your progression. Step one, you connect to the network and get routes. Step two, you connect your VPN. Step three, your host starts sending traffic. At this point, your firewall rules are now active and dropping any traffic you've told them to. Step four, you renew your DHCP lease and get new routes via option 121. Those routes might be malicious, or they might not. One of three things is…
C is what happens. But it doesn't happen the way you say at all.
Only the traffic heading to the new 121 routes are blocked - why is it blocked? because the routes are on the physical interface, and the firewall rules blocks all off-VPN traffic (except traffic to the VPN endpoint itself)
The tunnel stays up because the tunnel connection is over the physical interface. The VPN endpoint has a physical route from the host to the VPN endpoint which is whitelisted in the firewall. So new physical routes (which option 121 would push) don't impact anything as VPN endpoint route is physical anyway. Also it's impossible for the DHCP server to push a route MORE specific than the endpoint route (which is a /32) that already exists, so it can't be overridden (and it wouldn't matter anyway since it would still be a physical route, which is what is desired here).
Can you stop just talking and actually TRY it? it's all theoretical for you since you're not actually testing it and your theory is completely wrong.
I am actually testing it, so i know I am correct.
Re: Attackers can decloak routing-based VPNs
#154Earlier quoted context omitted.
Let's walk through this step by step because there's a lot of confusion on your end. * Step one - You connect your computer to a network - yes you'll get a DHCP lease, and you'll get an ip address, and a default gateway. This default route will be added to your routing table. * Step two - If the TunnelVision exploit (DHCP option 121) is at play you'll also get a few MORE SPECIFIC routes than the default gateway. Thes…
In your step 4, what happens when the VPN traffic gets routed over option 121 pushed routes? Don't you block it - thus blocking your entire VPN? > OR it will attempt to go through the more specific option 121 pushed malicious routes added by the compromised DHCP server (depending on the destination ip of the outbound packets). This right here... we don't want our VPN-secued traffic going out over routes broadcast by…
I think i know where you're confused. There is a firewall whitelist on the VPN endpoint route. Also it's impossible for the DHCP server to push a route more specific than this since it's a /32 route, so it's unaffected (together with the firewall rule allowing it) by anything the DHCP server attempts to do.
Re: Attackers can decloak routing-based VPNs
#155Earlier quoted context omitted.
What are these problems, exactly?
As I said above, a simple court order can destroy any attempt at privacy. All (serious) VPN providers claim they don't store logs. But that does not mean that a court can't force them to do so. When combined with a gag order you can have someone collecting all your traffic without you even realizing it. And that's just the VPN provider, which usually doesn't own any datacenters. The datacenter providers can also rece…
Re: Attackers can decloak routing-based VPNs
#156The threat model is that an arbitrary attacker can somehow become the DHCP server on your LAN, which is unlikely but not impossible. On the other hand, if you are using an ISP provided gateway device..
Re: Attackers can decloak routing-based VPNs
#157Earlier quoted context omitted.
Mullvad complies, but they go out of their way to keep very little information. If you don't have the information in the first place, you can't surrender it.
Beware that despite all marketing statements, VPN providers can easily be forced to store logs using court orders, even if they don't do it by default.
Re: Attackers can decloak routing-based VPNs
#158Re: Attackers can decloak routing-based VPNs
#159Earlier quoted context omitted.
> A kill switch is just Not always. Some VPNs have a kill switch feature for closing specified programs. Hopefully in addition to the firewall rule.
"closing specified programs" has to be the silliest thing i've ever heard. By the time you close it, it's probably already leaked thousands of packets. The leak of a SINGLE packet is already too much. Such an "application killing kill switch" is just marketing fluff, it makes zero sense from a security standpoint.
Re: Attackers can decloak routing-based VPNs
#160Earlier quoted context omitted.
As I said above, a simple court order can destroy any attempt at privacy. All (serious) VPN providers claim they don't store logs. But that does not mean that a court can't force them to do so. When combined with a gag order you can have someone collecting all your traffic without you even realizing it. And that's just the VPN provider, which usually doesn't own any datacenters. The datacenter providers can also rece…
You're spreading FUD, the Swedish government can't do shit to Mullvad but take their servers offline. Possibly if it was a matter of national security, at which point our recommendations are useless either way.
Consequently, you can assume that all other VPN providers who are still doing business in Europe are freely giving away their data to government agencies.