3 ms·

> That's why I recommend nested VPN chains. You just need to trust that most of the VPN services in your chain are not working together for an adversary. In ge

> That's why I recommend nested VPN chains. You just need to trust that most of the VPN services in your chain are not working together for an adversary. In general in cryptography, it's possible to combine secure things and get a less-secure thing. I don't know if this is the case for VPNs. Have you analysed the issue in depth?

mirimir 7y ago
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.
- iudqnolq 7y ago
  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?
  - mirimir 7y ago
    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-anonymity-part-1 https://www.ivpn.net/privacy-guides/advanced-privacy-and-ano... 1) https://github.com/mirimir/vpnchains https://github.com/mirimir/vpnchains
    - iudqnolq 7y ago
      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.
      - mirimir 7y ago
        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.

mirimir 7y ago

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.

iudqnolq 7y ago
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?
- mirimir 7y ago
  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-anonymity-part-1 https://www.ivpn.net/privacy-guides/advanced-privacy-and-ano... 1) https://github.com/mirimir/vpnchains https://github.com/mirimir/vpnchains
  - iudqnolq 7y ago
    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.
    - mirimir 7y ago
      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.