[Openvpn-users] * UPDATE * OpenVPN v2.4.3 and v2.3.17 releases

[David Sommerseth]

Hi,

We are in an unfortunate situation that our Cloudflare front is
providing various results, depending on a lot of factors (region,
browser, computer, etc, etc). And it causes a massive noise on people
trying to download and verify that these downloads are correct.

As most of this noise have been related to the source code downloads, I
have setup an emergency wiki page where an alternative download URL is
provided ... In addition the proper SHA256 checksums and proper
signature files are available too.

This will hopefully help people to get the right download.

<http://community.openvpn.net/openvpn/wiki/release-packages-2.4.3-2.3.17>


We will go more carefully through our release process and figure out how
to avoid this mess with the next release. The discussion have already
been initiated [1], and we will dig into this for the next release.

[1]
<https://www.mail-archive.com/openvpn-***@lists.sourceforge.net/msg14937.html>


On behalf of the OpenVPN core community team, I am truly sorry for this
mess. This is not how we want our releases to appear.

[Jason Haar]

This post might be inappropriate. Click to display it.

[Gert Doering]

Hi,

Post by Jason Haar
Does using tls-auth protect against these latest security issues? ie if you
are running older versions but require tls-auth, then would that block
attacks from hackers who don't have your tls-auth file?

There's a big bag of vulnerabilities in there. Most of them are relevant
in special cases only, so "if you do not use a proxy with NLMv2 auth",
you're not vulnerable to that one (but if you do, tls-auth will not help
as it's failing on connection setup).

Actually, I just went through the logs, and tls-auth will not(!) protect
you in any of the cases.

CVEs 2017-7520, 2017-7521 and 2017-7522 are somewhat niche cases - you
need to use an NTLMv2 authenticating proxy, '--x509-username-field' or
'--x509-track' (on the server) to be vulnerable.

CVE 2017-7508 affects anyone who is using IPv6 *inside* the tunnel, has
--mssfix enabled, and is not using a firewall on the outside that will
sanitize broken IPv6 packets (like BSD's pf(4) would do). In that case,
someone from out there in the wild could send a malformed IPv6 packet
that makes the server ASSERT().

So: if you use tunneled IPv6 in your VPN, and bored kids can find
out which networks you use internally in the VPN and can send packets
there, upgrade.

gert