ANSWERED User generated key files & certs

[vashtanerada 0]

I can't help but think that if I were the NSA (or pick your favourite TLA agency), setting up a VPN service somewhere would be an awfully good way to pick up the more interesting traffic; more signal with less noise if you will.

 

Since AirVPN generates our keys and our certs, and could theoretically then decrypt our traffic, that seems a big gap. Ease of use and support are of course a concern, but would AirVPN consider allowing user generated certs for proficient users, possibly on a different account level? AirVPN would never see a key, and our traffic just that much more secure. I expect user confidence would be correspondingly higher.

[Staff 9765]

Hello,

 

probably you don't have the slightest clue about what you're saying about keys and certificates but your fears are legitimate. That's already what happens (see Diffie Hellmann negotiation in a public key infrastructure), but it does not make any difference, we still potentially can see your traffic (only the traffic without an additional encryption layer). You need partition of trust if you can't afford to trust us. If we were running a "honeypot" or anyway conducting a sinister operation, we would not be promoting partition of trust since our "birth". Please read here:

https://airvpn.org/topic/54-using-airvpn-over-tor/?do=findComment&comment=1745

 

A practical example that opens the doors to multiple trust partitions:

https://airvpn.org/tor

 

Kind regards

[vashtanerada 0]

Thanks, split trust makes very good sense, but now you have me concerned that in my nine years' CISSP, I've missed something gravely important and may not have the slightest clue on the topic after all. I had understood a private key is meant to be known only to the user, Is OpenVPN/OpenSSL an exception? Honestly, I'm curious. If the key provided and held by both of us is only for the exchange of a symmetric pubkey matched to a privkey only on the client end and that Air never sees, I have it wrong and would be grateful for a link and some education. Crypto isn't my strong suit, but I really thought I had that bit down.

 

Thanks again for emphasizing the split trust issue. In that regard I have been lazy. No hurry, but now I feel like I'm missing a critical piece of the puzzle. Any help welcome.

 

Prost,

Vash

[Staff 9765]

Hello,

 

the basic concept is that regardless of the key exchange method and cipher used in an end-to-end encrypted connection, both ends are able to see the unencrypted payload (otherwise any gateway of the VPN to the Internet could not work, obviously). That's why you need to add encryption layer(s) in every and each case you can't afford to trust VPN, TOR exit-nodes etc. operators, or the security/safety of their servers. On top of that, not only you can add an encryption layer, but you can also hide your real IP address to the VPN or TOR servers.

 

The additional step is hiding both your traffic AND your IP address, an argument which is treated implicitly in the linked post. One quick method (there are many, this is just a didactic example) is connecting over OpenVPN over TOR a host machine, and connecting over TOR on a guest (virtualized) OS, attached to the host via NAT (setup successfully tested with VirtualBox, but there should be no problems at all with VMWare as well). The resulting setup will therefore have the following features:

 

- on the host machine, traffic is "tunneled over" OpenVPN over TOR ("fixed" circuit)

- on the guest machine, traffic (ONLY of the applications configured to connect over TOR proxy) is "tunneled over" TOR (not "fixed" circuit) over OpenVPN over TOR.

 

As a result: AirVPN servers can't see your real IP address, packets payload, origins, destinations, used protocols and applications from/to your VM. Also, the traffic is pushed into two different TOR circuits. While this setup provides very poor performance, it also provides an extraordinarily high anonymity layer (which can be crumbled by human errors of the system operator, social engineering or by a compromised machine with keylogger, spyware etc.) for critical purposes.

 

The above setup should also greatly lower (or maybe even crumble) the efficacy of traffic analysis by an adversary who controls Internet exchanges (see for example http://freehaven.net/anonbib/#murdoch-pet2007 ) but further research on the topic is necessary.

 

Kind regards

[vashtanerada 0]

Put like that, of course! Now I see where I really had the wrong model in my head. Thank you for taking the time responding to what was in retrospect, not an especially brilliant question. Love the service, and great support. Cheers.