Description of problem: I unfortunatately have to connect to a VPN that use MD5. It works fine in Fedora 25 with NetworkManager.service containing Environment="OPENSSL_ENABLE_MD5_VERIFY=1 NSS_HASH_ALG_SUPPORT=+MD5" I do however not see any way to make that work with Fedora 26. mbedtls doesn't have md5 support at all. That is unfortunately a severe regression for me. It might be hard to fix, but I suggest it at least deserve to be listed as a "known issue". Version-Release number of selected component (if applicable): NetworkManager-1.8.0-0.2.rc2.fc26.x86_64 openvpn-2.4.1-3.fc25.x86_64
First of all, any OpenVPN configuration still using MD5 based certificates in production SHOULD by updated ASAP. MD5 certificates have also been deprecated in most web browsers for many years, and now SHA1 is being deprecated as well. Ignoring that fact is actively ignoring the security of the VPN setup as well. With that said ... I have added a modified patch to a scratch build which _may_ work. I have not had any time testing it, but if you could do that and report back if it works or not. If this works I can at least consider to add an OPENSSL_ENABLE_MD5_VERIFY=1 quirk support until we switch back to OpenSSL (once the v1.1 support have landed). https://koji.fedoraproject.org/koji/taskinfo?taskID=19098907
I confirm that openvpn-2.4.1-3_scratch1.fc26.x86_64 works for me. Thanks for looking into this. I agree the VPN certificates just should be upgraded ... but fortunately/unfortunately I am just a user and can't do that.
Good. I have prepared another scratch build. This is what I expect the next update for F26+ to contain. Just a few details missing before the machinery can start rolling. https://koji.fedoraproject.org/koji/taskinfo?taskID=19107333 This enables support of OPENSSL_ENABLE_MD5_VERIFY=1 environment setting. This should ensure existing configurations will not need to be modified to work. MD5 support is only enabled if this environment variable is set to 1. And the OpenVPN will complain to the log when this happens. If you are not responsible for the certificates yourself ... make sure your certificate provider is being made clearly aware of issues related to MD5 certificates. And I consider this MD5 support temporarily. We cannot drag along with MD5 certificates forever due to lazy sys-admins.
No, https://kojipkgs.fedoraproject.org//work/tasks/7335/19107335/openvpn-2.4.1-4.fc26.x86_64.rpm doesn't work for me. I get Apr 21 12:09:27 localhost.localdomain nm-openvpn[12808]: TLS_ERROR: read tls_read_plaintext error: X509 - Certificate verification failed, e.g. CRL, CA or signature check failed Verified by going back and forth between the versions a couple of times.
Can you please provide logs of the failing attempts with openvpn-2.4.1-4.fc26 ? That will help me understand what happens and not.
Created attachment 1273322 [details] log What kind of log can you use? Does this say anything?
Yes, those nm-openvpn lines provides the needed information. I am missing two lines, which should be added when the OPENSSL_ENABLE_MD5_VERIFY=1 environment variable is set. If OpenVPN isn't capable of picking up that one, MD5 support is lacking. The log lines should look something like this: ----------------------------------------------------------- ** WARNING ** [Fedora modification] MD5 certificate hash re-enabled via OPENSSL_ENABLE_MD5_VERIFY environment variable. ** WARNING ** MD5 based certificates are INSECURE! Start updating your certificate ASAP. MD5 SUPPORT WILL BE COMPLETELY REMOVED IN A LATER RELEASE. ----------------------------------------------------------- These two lines shouldn't be too difficult to notice. To me it looks like this env. variable is missing. Unless I've done the extraction of this env variable in an incompatible way when NetworkManager is involved. Can you also try to run this from the command line? $ OPENSSL_ENABLE_MD5_VERIFY=1 /usr/sbin/openvpn ........ where ...... should be your OpenVPN configuration (or just --config $CONFIG_FILE)
Hmm. Right. It warns and works when running openvpn directly. The reason it didn't work for me is that environment variables apparently can't be set in systemd config the same wau as before? As if NetworkManager invokes openvpn in a different way now and we have to put the Environment variable in a different location instead? (My setting of environment variables worked when using the f25 openvpn package on f26, so I'm quite sure that something in that area changed with the f26 package.)
There are at least two ways how to retrieve environment variables in a program. I chose the most strict one in the attempt in comment #4. This approach used secure_getenv(). I have another scratch build ready, which uses getenv(). Could you try that build and see if that works better? https://koji.fedoraproject.org/koji/taskinfo?taskID=19185349
Thanks. I digged a bit more (slightly confused by having two builds with the same EVR) and found the culprit: Your patch checks for OPENSSL_ENABLE_MD5_VERIFY == "1". I guess the original openssl patch only checked for whether it was set to something? As mentioned above, I used Environment="OPENSSL_ENABLE_MD5_VERIFY=1 NSS_HASH_ALG_SUPPORT=+MD5" and that is wrong. It gives what corresponds to OPENSSL_ENABLE_MD5_VERIFY="1 NSS_HASH_ALG_SUPPORT=+MD5" (I would probably have spotted it earlier if you had shown me the patch you applied.) So: By editing /usr/lib/systemd/system/NetworkManager.service and adding to [Service] Environment="OPENSSL_ENABLE_MD5_VERIFY=1" and running systemctl daemon-reload systemctl restart NetworkManager.service it will make /usr/libexec/nm-openvpn-service launch /usr/sbin/openvpn with the proper environment variable and show the expected warning. (It will allow it for everything NetworkManager - not just for openvpn. Is there a more narrow way to do it?) The first build with secure_getenv then works fine - I suggest using that.
Ahh! Perfect, thanks a lot for great testing and feedback! I'll move back to the original patch again, using secure_getenv(). And sorry about the NVR miss ... forgot to save the .spec file for the scratch after the last update.
openvpn-2.4.2-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-89d98779ec
openvpn-2.4.2-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-89d98779ec
openvpn-2.4.2-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
I'm still seeing this problem with slightly newer versions of the software. My versions are: [thomas.litton@thomaslitton MINF_20170828]$ rpm -q openvpn openvpn-2.4.4-1.fc26.x86_64 [thomas.litton@thomaslitton MINF_20170828]$ rpm -q NetworkManager NetworkManager-1.8.2-1.fc26.x86_64 [thomas.litton@thomaslitton MINF_20170828]$ rpm -q NetworkManager-openvpn NetworkManager-openvpn-1.2.10-1.fc26.x86_64 Is this still supposed to be fixed in these versions?
Seen again in F27 - I filed Bug 1498322 .
First of all, as of v2.4.3, OpenVPN is built against OpenSSL 1.1 in F26 and newer. Secondly, as OpenSSL makes it harder and harder to re-enable MD5 certificate verification support - with good reasons! We (upstream OpenVPN) will not do anything additionally in OpenVPN to support MD5 any more. The MD5 verification support must be present in the SSL library for OpenVPN; then it will work as before. But we DO NOT support MD5 in OpenVPN any more. And OpenSSL (and other SSL libraries) do make it more and more harder to re-enable MD5 based certificate verification support. More information can be seen in https://bugzilla.redhat.com/show_bug.cgi?id=1498322#c1 TL;DR: Don't use MD5 based certificates. Period. If your VPN provider enforces you to do so; don't use that VPN. Really. MD5 is broken beyond repair and it has been like that for over 12 years(!). Time to move on. And - no, I will not change my mind. - yes, what we did here in this ticket was a big mistake.