Trying to make OpenVPN easy to use is admirable. If you're interested in a public-key (RSA) config then it's currently just a disaster to setup, even with the "easy RSA" helper scripts. In my experience the --up and --down hooks and routing are also terrible. I invested hours trying to get it working with a persistent TUN device (so daemons could bind to the endpoint IP before the VPN was up), but OpenVPN is just too bloated and tries to do too much for you, getting in the way.
I recommend people give tinc a try instead. Specifically version v1.1-pre*. It's an absolute doddle to setup, uses Ed25519 key pairs, and plays much more nicely with traditional network configuration.
Algo is great. It actually provisions the machine for you - you run it, and it creates a AWS or GCP or Azure or DO machine for you, installs everything, and spits out a mobileconfig (etc) at the end.
I want to turn Algo into something that a user can set up from their phone. Technical plumbing aside, do any of those hosting providers provide a billing API that allows users to add payment methods?
It would be pretty sweet if you could download an app, enter billing information and get a super fast private proxy.
What's more frustrating about claims like this are the premises that suggest IPSEC is somehow unknowable. IPSEC is far better studied than OpenVPN is, and its underlying protocol is simpler than TLS (which, of course, NSA is also routinely accused of having tampered with). More importantly: these are protocols, not ciphers. Not only can we read and simulate and test them, we can in fact prove things about them computationally.
I don't know how to articulate the succinct and conclusive argument that you're "not even wrong", but that's the territory that claim lands you in.
This isn't a coherent theory of NSA interference with IPSEC, but rather a collection of different theories, many of which pertain both to IPSEC and (via TLS) to OpenVPN.
* Here's a deep dive on that OpenBSD IPSEC backdoor theory (long story short: it wasn't one, though even if it had been, it would have affected only an old version of IPSEC): https://news.ycombinator.com/item?id=2014197
* Virtually everyone I know in cryptography believes BULLRUN to be a code name for Dual EC DRBG, which is a backdoor, and targets TLS.
* The Diffie-Hellman attack referred to here was discovered first in (you guessed it) TLS.
As for zero-day attacks again IPSEC software, that is no doubt a thing! But it's no less a thing for OpenSSL.
I don't understand how you manage to get to "IPSEC is less open than TLS", since they're both equally open.
Not IPSEC in itself, but the full stack (tunnel+encryption) implementation in (for example) macOS is completely closed. You could go for something like StrongSwan, but then you lose the advantage you mentioned, namely OS-integration.
Looks like AES-128-CBC and no regeneration of Diffie Hellman params. I'm not sure that's the greatest choice when you have full control over the endpoints.
I noticed DH params do get generated via easy-rsa (although not audited that code, so can't comment on how rigid it is, nor what keysize is being used so that could be defaulting to 1024 which isn't all that great nowadays)
OpenVPN is pretty slick for point-to-point connections into a cloud environment. We run the server side in a docker container on kubernetes and push the cluster services network routes as dhcp options to clients, so developers can work locally just as if their services were running in the cluster.
Pritunl - https://pritunl.com/ is an excellent and easy to deploy solution. It has AWS and Digital Ocean provisioning, extremely flexible and endlessly powerful. Free for a single server with unlimited users. The config files work with their client or OpenVPN clients.
This is a pretty cool project. FWIW, I have a suggestion for the code.
The right way to do this is to use terraform - which specializes in building production grade scripting templates to spin up clusters on a wide variety of cloud providers.
The Openvpn installation itself could be a docker VM.
That way you eliminate the need to build "will it work on cloud provider X and operating system Y?"
Tangentially: We set up StrongSwan recently to use as a VPN into Google Cloud, to allow developers (who all run macOS) to use the nodes seamlessly and interact with Kubernetes and other internal services over a secure connection.
But we met a roadblock when we tried to get DNS to work automatically -- we wanted the GCP boxes to be resolved to their internal IPs, so we set up a DNS server (dnsmasq) on GCP, but there seemed to be no way to tell the client to use it to resolve .internal. There's a plugin/extension available for IKEv1, apparently, but we couldn't find a way to do it for IKEv2. The only way was to configure each client machine's DNS server list (and default domain list) manually, which is not really acceptable.
For now we've switched to OpenVPN, which is fine but requires installing a third-party VPN client on macOS. I would love to know if we could solve the DNS issue and go back to IKEv2. Anyone done this?
The "typical" practice is to use an "up"/"down" scripts to modify the DNS servers when the VPN link goes up/down.
If you just want to use your GCP dnsmasq instance for the .internal top-level domain (not all DNS queries), then you'd want to run a resolver locally that you can configure to selectively forward queries.
This is pretty easy on Linux but I've never attempted it on MacOS. I realize it's probably not ideal but perhaps you can install dnsmasq or unbound on MacOS via homebrew or Macports?
The idea is to avoid any unnecessary client-side configuration aside from the connection itself. Adding a resolver on macOS is easy enough (just create a file /etc/resolver/internal for .internal, containing the IP of the DNS server), but the nice thing about OpenVPN is that you get the DNS config automatically.
For a simple openVPN set up I've used https://github.com/Nyr/openvpn-install with quite a lot of success. It's handy that it let's you add multiple users if you're using it in a commercial setting too.
I use this as well on DigitalOcean. It's easy to create new certs and put them on my various devices so I can disable if I need to. I'll have to check out some of the other ones listed here but I've been using it for a few years now without any issues.
Imagine something like this, wrapped in a nice and simple GUI and supporting a large and ever changing varienty of cloud providers and VPN protocols. That could strike a decent blow against spying and censorship by being significantly harder to block than any single popular service.
Algo VPN supports DigitalOcean, EC2, Google Cloud Engine, Azure, and your own local server. We'll add support for LightSail soon too: https://github.com/trailofbits/algo
Once the project stabilizes, we want to make a GUI that helps people deploy it but it's not that mature yet.
If you are running this from your own AWS account doesn't it have the problem of not anonymizing the traffic - since it can all be tied to your identity?
A VPN isn't always about anonymity. For instance: encrypting traffic in a coffee shop where any and all of your traffic can be sniffed.
Another popular use-case is streaming (paid-for/ad-supported) content from a different region of the globe that is blacked out in your region (and the rights-holders wonder why people still torrent).
If you work with AWS infrastructure in a VPC, sometimes it makes sense to use a VPN to access/manage VPC instances that don't have a public IP (e.g., app servers behind an ELB). Of course, one could also just tunnel through an exposed SSH server in the VPC, but a VPN server can offer a little more convenience and flexibility.
It's more like all non-HSTS traffic, unless you're paying extremely close attention. Otherwise a man in the middle attacker can just pretend the server doesn't support HTTPS and serve the page via HTTP.
And even when you're using HTTPS you're still leaking DNS queries etc.
Even when you're using SSL/TLS the traffic can still be seen on the network. The difference is that a sniffer will see cipher text rather than plain text.
Being able to directly connect to internal addresses from your local dev machine can have it's advantages. Consider the situation where you need to connect to services across a multitude of hosts in an internal network. Using static SSH tunnelling, mapping out each local port to remote host could be a challenge. You can run a SOCKS proxy through an SSH tunnel for dynamic port forwarding, but not everything supports SOCKS.
Another reason could be to bypass censorship / filtering for low volume web traffic websites. You may not trust a paid VPN service.
I've got two "jump boxes" running SSH accessible to 0/0. You can only SSH into any other hosts from one of those two and I do that dozens of times a day without even thinking about it.
It was a quick one-time set-it-up-and-forget-it (to configure "ProxyCommand" in ~/.ssh/config) kind of thing that just works.
There's an FAQ entry in the Algo readme about OpenVPN. The biggest tradeoff is that OpenVPN is a little bit easier to setup at the detriment of inheriting all the insecurities of SSL and the requirement to maintain 3rd party software (security updates etc).
For what it's worth, I used PiVPN (http://www.pivpn.io/) for a quick setup of OpenVPN on a RasPi3 earlier this year - can recommend for convenience, with no comment on security. My main goal was place-shifting...
Power of the cloud! Shouldn't this be ~instant? Maybe upload a very minimalist AMI or static overlay to a default AMI instead of whatever route is being used here (I didn't check)?
Well I haven't tried it so I'm not sure how big the AMI is or what the 3-minute process is, but for sure a script could (optionally) (re-)generate the (repeat build capable) minimal AMI, or the current process could be otherwise streamlined.
I recommend people give tinc a try instead. Specifically version v1.1-pre*. It's an absolute doddle to setup, uses Ed25519 key pairs, and plays much more nicely with traditional network configuration.
https://www.tinc-vpn.org/