Hacker News Reader

Comment by mirimir | Hacker News Reader

This isn't about cryptography. It's just that any VPN server must know the IP addresses it's communicating with. So with one VPN, someone can just look at the traffic logs.

But with two VPNs chained, neither one knows both your IP and the IPs of the sites that you access. And the longer the chain, the more collusion an adversary needs.

But yes, you're also encapsulating multiple levels of encryption. I do appreciate that potentially increasing the risk of breaking the encryption. However, I'm willing to accept that in exchange for not being so trivially findable.

View on HN

I didn't mean necessarily you'll break the crypto primatives, more that these kinds of systems can interact in weird ways if you don't go through everything very carefully.

How do you set up the chains? Do you mean?

    You ---[vpn_1]---> your server        
    server ---[vpn_2]---> ISP

Or do you do

        ===[vpn_1]=====
   You  ----[proxy_server_1]--- ISP 
        ===============

Or differently? There's no way to tunnel a VPN in a VPN COTS.

Off the top of my (nonexpert) head, some adversaries can try a bunch of different correlation attacks and if they can associate your traffic with any of your VPNs they can work to track your transactions to pay for it. So having more VPNs gives them a greater chance of being able to access the data of one and a greater chance of you screwing up the anonymous purchase of one.

Also I'm pretty sure you mostly have to trust the last VPN in your chain anyway. So why not just use only that one?

It's simple.

I connect to a server of one VPN service. Then, through that VPN tunnel, I connect to a server of a second VPN service. Then, through that VPN tunnel, I connect to a server of a third VPN service. That's what I mean by nested. I don't use custom VPN clients. Just OpenVPN.

In the setup that I'm currently using, one VPN client runs in a VirtualBox host machine. And the others run in pfSense VMs.[0] Each pfSense instance uses ~500MB RAM, however.

But it also works in a single machine, using routing and iptables rules.[1] For a chain of three VPNs, these OUTPUT rules prevent leaks, with internet traffic restricted to the third VPN tunnel (tun2):

   -A OUTPUT -o enp0s3 -d VPN0 -j ACCEPT
   -A OUTPUT -o tun0 -d VPN1 -j ACCEPT
   -A OUTPUT -o tun1 -d VPN2 -j ACCEPT
   -A OUTPUT -o tun2 -j ACCEPT
   -A OUTPUT -j DROP

VPN0, VPN1 and VPN2 are the IPv4 addresses of the VPN servers that I'm using. From different VPN services. The script that sets up the chain alters the routing so that each VPN connects through the previous one. There's no isolation between the different VPN clients, but that also makes it easy to switch chains periodically. Sort of like Tor.

I pay for the first VPN with a credit card. But the rest I pay with Bitcoin, which has been mixed multiple times through Tor, using a different mixing service at each step. I used Bitcoin that's been mixed more times for VPNs that I connect to less directly. And I never lease different VPNs with the same batch of mixed Bitcoin.

The last VPN know only what I connect to, and what VPN I connected from.

0) https://www.ivpn.net/privacy-guides/advanced-privacy-and-ano...

1) https://github.com/mirimir/vpnchains

Thanks for the reply. Guess SE was wrong about the configs. If you don't mind me asking, why cc for the first hop?

Also, vpnchains explicitly says they can't protect against adversaries with a global view od the network. That was the main weakness I assumed this would probably have. I'd buy that it protects from for instance VPN providers selling logs.

I use a card for the first one because it's gotta know my IP, and my ISP can link me to my IP.

Nothing can protect from adversaries with a global view of the internet. At least, for low-latency activity. If the latency is high enough, and there's lots of chaff, there's maybe a chance. Or at least, there are too many false positives to deal with.

Otherwise, you just make it harder. Once you have more than a couple VPNs in a chain, and especially if you switch chains frequently, latency varies a lot. So that likely helps too.

Edit: There is nothing in OpenVPN about routing one VPN through another. That's all done in the host networking stack, or using multiple routers with NAT forwarding. There is, however, a SOCKS5 proxy option, which you can use to route a VPN through Tor. Or you can just run a VPN server as an onion service.

You might want to look into wireguard.

It has much lower over-head then OpenVPN, and in your case the inter-connection latency/processing would be improved.

But why go through so much trouble instead of just using Tor, which AFAIK gives you 3 hops right out of the box?

I do use Tor. Which gives me three hops for clearnet sites, and seven hops for onion services. But I don't trust Tor enough to connect directly to it. Given the risk of malicious relays, and of 0days like "relay early" that increase their effectiveness. And then there's the likelihood that TLAs track all connections to the Tor network.

So the nested VPN chains isolate me from Tor entry guards. If Tor circuits get deanonymized, an adversary just learns a VPN exit. Or at least, an adversary that isn't doing global traffic analysis.

But as Mirimir, I don't need all that. I really don't need anonymity at all, except to protect my professional reputation. And being retired, that doesn't matter any more.

So anyway, nested VPN chains are arguably enough for people who aren't juicy targets. They almost certainly aren't as good as Tor, unless Tor is more compromised than it seems.

But what they are is lots faster. There's somewhat less latency than Tor. And bandwidth is much higher.

Reply on news.ycombinator.com