Live data from Hacker News

Important security vulnerabilities in OpenVPN

guidovranken.wordpress.com

71–80 of 97 posts

Re: Important security vulnerabilities in OpenVPN

#71
post #59

OpenVPN is very complicated and for that reason I use sshuttle[1] which is very simple. It does require that you own an sshd running on an endpoint somewhere (like a VPS or an EC2 instance or your own server somewhere) - but if you can clear that hurdle, you end up with a very elegant and simple solution. [1] https://github.com/sshuttle/sshuttle

The first line on the sshuttle GitHub page says 'does not require admin'. Why even have installation instructions via 'sudo' then?

A benefit of installing using your system package manager is that you can rely on your distro to manage the security of the package. If you just `pip install` it, you need to personally watch for new security bugs and upgrade (or backport them to your current version, which is what e.g. Debian will do for you). You'd also need to do that for all of the dependencies.

Up to you if you trust your distro's security team, of course :). I trust mine.

Re: Important security vulnerabilities in OpenVPN

#73
post #18

Vulnerability #2 is a good example of why OpenSSL is a minefield even for a competent coder. For such a security-critical library it's pretty insane that the API is so unfriendly, bordering on hostile. > The correct way to do this is to call GENERAL_NAMES_free. This is because sk_GENERAL_NAME_free frees only the containing structure, whereas GENERAL_NAMES_free frees the structure AND its items. And later: > Here, the…

There's no reason they couldn't use more object-oriented return methods to make it easier to grok what's going on.

Re: Important security vulnerabilities in OpenVPN

#74

I was thinking of switching to L2TP instead. Would there be any downsides? I tried out this script once and it worked well: https://github.com/hwdsl2/setup-ipsec-vpn

L2TP doesn't traverse NATs and other network firewalls very well. Which isn't relevant if you yourself control all of the hardware between endpoints (e.g. point2point) but if you plan on using it on public networks (e.g. Starbucks WiFi) then expect to run into it being blocked sometimes.

OpenVPN was designed for the "Starbucks WiFi" scenario, it can traverse a NAT, and uses standard TLS. It therefore appears like any other HTTPS traffic and will be very infrequently blocked.

There's nothing inherently wrong with L2TP/IPSec; it is secure and fast. Just nicer to blend in with other TLS traffic for reliability reasons.

For a specific example, GoGo Internet (in-flight WiFi), doesn't allow L2TP/IPsec unless you use UDP encapsulation. OpenVPN works out of the box.

Re: Important security vulnerabilities in OpenVPN

#75
post #71

Earlier quoted context omitted.

The first line on the sshuttle GitHub page says 'does not require admin'. Why even have installation instructions via 'sudo' then?

A benefit of installing using your system package manager is that you can rely on your distro to manage the security of the package. If you just `pip install` it, you need to personally watch for new security bugs and upgrade (or backport them to your current version, which is what e.g. Debian will do for you). You'd also need to do that for all of the dependencies. Up to you if you trust your distro's security team,…

I did not say anything about package managers. I trust my distro and its suppplied packages just like you trust yours and aim to use official packages as much as I can.

The instructions in README.md say "sudo pip install" and "sudo ./setup.py". To me, that is a bad idea. Things that are manually installed should be kept in completely separate directories. My preference is to install such packages in my home directory, which should in no way require sudo.

Re: Important security vulnerabilities in OpenVPN

#76
post #59

OpenVPN is very complicated and for that reason I use sshuttle[1] which is very simple. It does require that you own an sshd running on an endpoint somewhere (like a VPS or an EC2 instance or your own server somewhere) - but if you can clear that hurdle, you end up with a very elegant and simple solution. [1] https://github.com/sshuttle/sshuttle

For Mac users, Sidestep [1] offers a similar VPN over SSH experience. It's the only VPN product I've ever used that I've never had an issue with...it just works (no doubt due to the bulletproof nature of SSH).

[1] http://chetansurpur.com/projects/sidestep/

Re: Important security vulnerabilities in OpenVPN

#77
post #59

OpenVPN is very complicated and for that reason I use sshuttle[1] which is very simple. It does require that you own an sshd running on an endpoint somewhere (like a VPS or an EC2 instance or your own server somewhere) - but if you can clear that hurdle, you end up with a very elegant and simple solution. [1] https://github.com/sshuttle/sshuttle

tinc is also a popular lightweight VPN, although it's targeted for embedded. It does nevertheless support the libreSSL fork mentioned upthread. https://www.tinc-vpn.org/

+1 for tinc

Re: Important security vulnerabilities in OpenVPN

#78
It's good to see that 2 donations, totaling 0.80260293 BTC (~2000 euro) are made to Guido's wallet [0]. Probably not worth his time, but since he states it was "a labor of love" it's still a nice extra!

Edit: corrected BTC amount.

[0] https://blockchain.info/address/1D5vYkiLwRptKP1LCnt4V1TPUgk7...

Re: Important security vulnerabilities in OpenVPN

#79

Man, I'm eager for WireGuard to hit 1.0. It's very elegant, and I could build a policy layer on it in a couple days which doesn't suck.

Indeed, wireguard looks like it's going to be the bee's knees. It still has a lot of development ahead of it, though.

Re: Important security vulnerabilities in OpenVPN

#80
post #79

Man, I'm eager for WireGuard to hit 1.0. It's very elegant, and I could build a policy layer on it in a couple days which doesn't suck.

Indeed, wireguard looks like it's going to be the bee's knees. It still has a lot of development ahead of it, though.

Shouldn't take too long, though. It's still about 10kSLoC and it's been more/less feature frozen for over a year. I get the feeling that it's already probably safer than most deployed VPN systems. Most of the recent work seems to be forward porting, reworking the ratelimiter, and tweaks to the treatment of randomness.
Post reply on HN