Bug 1498322

MD5 certificate verification support have been removed from OpenSSL by default.  You simply cannot trust _any_ VPN server or client using a MD5 certificate; it is far to easy to create a fake and valid certificate with correct MD5 fingerprints.

For more information: https://twitter.com/OpenVPN/status/899604597039407105

TL;DR:  In a 12(!) year old research paper, researchers was capable of generating a new certificate with a pre-defined MD5 hash in about 8 hours on a (at that time) standard notebook.  Now imagine how much it would cost to setup an AWS cluster which would do the same job in less than an hour.  MD5 IS INSECURE.

So if you still have VPNs depending on MD5 certificates, stop using it now.  And move towards SHA2 based certificates (SHA256 and better).  If you're paying for a VPN service using MD5 certificates, cancel the agreement and demand a refund - as that is truly an insecure VPN provider.  There are no sane arguments to keep MD5 certificates alive any longer.  Really.

In regards to compat-openssl-1.0 - since OpenVPN v2.4.3 the Fedora packages switched to openssl-1.1, as OpenVPN gained full OpenSSL 1.1 compatibility in that release.

We have considered MD5 support.  And we have considered VPN security to be far more important, as the P in VPN is about privacy.

I agree. My employer doesn't.

Until I can get my employer replaced, I can work around it by rebuilding openvpn from a spec with BuildRequires hacked to compat-openssl10-devel and compat-openssl10-pkcs11-helper-devel - and [Service] Environment="OPENSSL_ENABLE_MD5_VERIFY=1" in /usr/lib/systemd/system/NetworkManager.service .

Thanks.

@David Sommerseth @Mads Kiilerich 
My employer uses md5 signed openvpn Certs and I had to use this `NetworkManager.service` quirk since Fedora 22...   
Guys - could you explain it to me what would attacker had to do to gain access to our internal network?   
Do they only need to know the VPN server address at which point they can generate a certificate?

The issues related to colliding X.5.09 certificates are fairly well documented here:

https://eprint.iacr.org/2005/067.pdf

And an improved and more efficient approach building on the one above, can be found here:

https://eprint.iacr.org/2005/102.pdf

As comment #1 also says, these research papers are over 12(!) years old.


But to summarize it:  An attacker needs to generate a fake certificate which have a valid MD5 checksum for the certificate signature.  This is the first step where an unapproved certificate is used to connect to your VPN server successfully.  Once a valid connection is established, it is just to fine-tune the local client configuration to get a fully working access.

Of course, there might be some additional challenges, if --tls-auth or username/password authentication is enabled.  --tls-auth is the hardest one, unless the key is easy to get access to.  For the username/password, an attacker will only need to get in a MITM position between a user and the server.  The attacker can use a forged server certificate pretending to be correct server and extract username/password in plain text through a simple --auth-user-pass-verify script.  If OTP tokens is used in addition to the normal (static) password, that  makes this a bit more complicated.

Regardless, you cannot trust any client or server using MD5 certificate to really be whom they claim to be.

There is actually a workaround to connect to insecure VPNs via NetworkManager in Fedora 27.

As described in https://forums.openvpn.net/viewtopic.php?t=23979 openvpn supports weak ciphers via the option
 tls-cipher "DEFAULT:@SECLEVEL=0"

As described in https://mail.gnome.org/archives/commits-list/2016-May/msg04389.html NetworkManager supports this option, but it is not accessible from the UI.

I managed to get the connection up again by adding the line
tls-cipher=DEFAULT:@SECLEVEL=0
to the [vpn] section of the file /etc/NetworkManager/system-connections/<VPN-name>
I had to reboot my machine for NetworkManager to load the changed config and you must not use quotes ("") in the NetworkManager config file for this to work. But in the end I was able to connect to the insecure VPN by clicking the corresponding button in the NetworkManager GUI.