3 ms·

It's not at all a new idea. Cryptohippie has been claiming something like this for over a decade.[0] > Cryptohippie USA, Inc. provides access to the Cryptohip

It's not at all a new idea. Cryptohippie has been claiming something like this for over a decade.[0] > Cryptohippie USA, Inc. provides access to the Cryptohippie network, which is anonymous, thoroughly protected and globally distributed. This network creates anonymity and gives you very private access to standard Internet destinations. > Cryptohippie is unique: we don't require you to trust a single entity for your privacy. Our sales and network are run by separate companies in different jurisdictions. The sales company never sees network traffic and the network company never sees sales data. The network provider being Cryptohippie Inc., Panama.[1] And one of their services is "Anonymous Admin".[2] > System administrators are prime targets for blackmail, corruption and outside force, and are in a central position to undermine your communication and data security. > Cryptohippie Inc. operates an Anonymous Administrator pool that can be utilized to oversee critical enterprise infrastructure or administer highly sensitive information resources. > Anonymous Administrators can not be targeted by third parties. Not even Cryptohippie Inc. can give away their personal information or identity which could put them at risk of under force. > Using auditing and concurrent peer review processes, Anonymous Administrators are under your control and the risk of them becoming insider attackers is greatly reduced. > Only carefully tested, hand-picked specialists with a long standing relationship with Cryptohippie Inc. are available for client work. > Please be advised that Cryptohippie Inc. only facilitates the contact to the pool of administrators and helps with setting up processes for communication, auditing and payment escrow. We will not know what specific administrator works for your organization or what tasks you delegate to them. However, in case of conflict, we will mediate/arbitrate upon request. The argument, I gather, is that substantive acts require consensus of multiple anonymous admins. So rogue admins are not so much an issue. But still, as you say, how can users trust any of that? So yes, there is no "verify". 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. 0) https://secure.cryptohippie.com/products.php https://secure.cryptohippie.com/products.php 1) http://www.cryptohippie.net/ http://www.cryptohippie.net/ 2) http://www.cryptohippie.net/AnonAdmin.html http://www.cryptohippie.net/AnonAdmin.html Edit: About that "over a decade" comment, here's a snapshot from 2008: https://web.archive.org/web/20081006023454/http://cryptohippie.net/ https://web.archive.org/web/20081006023454/http://cryptohipp...

iudqnolq 7y ago
> 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

> 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