Bug 1498322 - No MD5 support available
Summary: No MD5 support available
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: openvpn
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: David Sommerseth
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-10-04 01:30 UTC by Mads Kiilerich
Modified: 2018-01-31 06:36 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-10-04 09:32:27 UTC


Attachments (Terms of Use)

Description Mads Kiilerich 2017-10-04 01:30:17 UTC
After upgrading to Fedora 27, I see the same as in Bug 1443749.

/usr/share/doc/compat-openssl10/README mentions OPENSSL_ENABLE_MD5_VERIFY but /usr/share/doc/openssl/README doesn't and /usr/sbin/openvpn links to /lib64/libssl.so.1.1 .

Thus,

$ OPENSSL_ENABLE_MD5_VERIFY=1 /usr/sbin/openvpn --config my.conf 
Wed Oct  4 03:21:58 2017 OpenVPN 2.4.4 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep 26 2017
Wed Oct  4 03:21:58 2017 library versions: OpenSSL 1.1.0f-fips  25 May 2017, LZO 2.08
Wed Oct  4 03:21:58 2017 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Wed Oct  4 03:21:58 2017 OpenSSL: error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak
Wed Oct  4 03:21:58 2017 Cannot load certificate file my.crt
Wed Oct  4 03:21:58 2017 Exiting due to fatal error

Please consider re-introducing some kind of backwards compatibility hack.

Comment 1 David Sommerseth 2017-10-04 09:32:27 UTC
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.

Comment 2 Mads Kiilerich 2017-10-04 23:41:38 UTC
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.

Comment 3 Steve 2017-10-18 15:10:16 UTC
@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?

Comment 4 David Sommerseth 2017-10-18 23:39:07 UTC
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.

Comment 5 Daniel 2018-01-31 06:36:52 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.