Important security vulnerabilities in OpenVPN

Post by okasaki » Wed, Jun 21, 2017, 5:40 PM UTC

MichaelGG wrote: post #81

UnoriginalGuy wrote: post #74

Earlier quoted context omitted.

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…

Where does this idea that OpenVPN is TLS come from? No, it does not appear like HTTPS nor does it use TLS for the traffic. OpenVPN has its completely own encapsulation protocol, and it stuffs a few TLS packets inside that to do key exchange, nothing more. (And it's key exchange is odd as they re-implement TLS PRF ... on top of TLS.) t. Recently implemented an OpenVPN client.

Post by MichaelGG » Wed, Jun 21, 2017, 6:02 PM UTC

okasaki wrote: post #82

MichaelGG wrote: post #81

Earlier quoted context omitted.

Where does this idea that OpenVPN is TLS come from? No, it does not appear like HTTPS nor does it use TLS for the traffic. OpenVPN has its completely own encapsulation protocol, and it stuffs a few TLS packets inside that to do key exchange, nothing more. (And it's key exchange is odd as they re-implement TLS PRF ... on top of TLS.) t. Recently implemented an OpenVPN client.

The man page says it supports TLS

Post by pjmlp » Wed, Jun 21, 2017, 6:17 PM UTC

omginternets wrote: post #56

tinco wrote: post #53

Earlier quoted context omitted.

Over the past years Apache httpd has had 187 vulnerabilities, 24 of which had potential remote code execution consequences. I'm not saying anyone is ever going to find another RCE in Apache. I'll even go as far as to say it's not very likely. But I don't think develop a server and then put it in the world's most hostile environments for 20 years until we're certain it's safe is a particularily efficient development s…

>People should stop building stuff in C, it's that simple. I would attenuate this in one sense and amplify it in another: it's (almost always) irresponsible to write network-facing code in C.

Post by bostik » Wed, Jun 21, 2017, 7:25 PM UTC

dom0 wrote: post #36

simias wrote: 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…

> you have to quadruple check each function invocation with the docs to make sure you got it right. If the docs contain that information ¯\_(ツ)_/¯

Post by zx2c4 » Wed, Jun 21, 2017, 9:33 PM UTC

microcolonel wrote: post #80

pferde wrote: post #79

Earlier quoted context omitted.

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.