OpenSSL 3.0 support in OpenVPN 2.5
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
openvpn (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Jammy |
Fix Released
|
High
|
Sergio Durigan Junior | ||
Kinetic |
Fix Released
|
High
|
Unassigned |
Bug Description
[Impact]
Users running Ubuntu Jammy have been having a poor experience because of the not fully support of OpenSSL 3. One of the upstream maintainers gladly provided a set of commits that should be backported to Jammy in order to improve this situation (they are listed in the "Original Message" section).
[Test Plan]
** Testcase for the SHA1 certificate support
One of the main problems this SRU addresses is the current inability to handle certificates that use legacy cryptographic algorithms (like SHA1). So let's reproduce this problem.
We will be using two VMs, one acting as the server and the other as the client. The server will be running Focal, and the client will be running Jammy.
== Server setup ==
$ lxc launch ubuntu:focal ovpn-server --vm
$ lxc shell ovpn-server
# apt update
# apt install -y openvpn easy-rsa
# cd /etc/openvpn
# make-cadir easy-rsa
# cd easy-rsa
# sed -i 's/^#set_var EASYRSA_
# ./easyrsa init-pki
# ./easyrsa build-ca
... when asked for the Common Name, provide "ovpn-server" ...
# ./easyrsa build-server-full ovpn-server nopass
# ./easyrsa build-client-full ovpn-client nopass
# ./easyrsa gen-dh
# cp pki/ca.crt pki/issued/
# cd /etc/openvpn
# openvpn --genkey --secret ta.key
# cp /usr/share/
# gunzip server.conf.gz
# mv server.conf ovpn-server.conf
# sed -i -e 's/^cert .*/cert ovpn-server.crt/' -e 's/^key .*/key ovpn-server.key/' -e 's/^dh .*/dh dh.pem/' ovpn-server.conf
# systemctl start openvpn@ovpn-server
Make sure that the service has successfully started by checking the output of "systemctl status openvpn@
The server setup is done. As you can see above, we've instructed easy-rsa to generate SHA1 digests for our certificates. This is what will trigger the issue on the client side.
Make sure you get the server's IP address (not the VPN one!); you will need it below.
== Client setup ==
$ lxc launch ubuntu:jammy ovpn-client --vm
$ lxc shell ovpn-client
# apt update
# apt install -y openvpn
Now you have to transfer the following files from the server to the client:
- /etc/openvpn/ca.crt -> /etc/openvpn/ca.crt
- /etc/openvpn/
- /etc/openvpn/
- /etc/openvpn/ta.key -> /etc/openvpn/ta.key
# cd /etc/openvpn
# cp /usr/share/
# mv client.conf ovpn-client.conf
# sed -i -e 's/^cert .*/cert ovpn-client.crt/' -e 's/^key .*/key ovpn-client.key/' ovpn-client.conf
Assuming you have the server's IP address, you can:
# sed -i 's/^remote .*/remote SERVER_IP_ADDRESS 1194/' ovpn-client.conf
Now, we will try to start the client. This should fail:
# systemctl start openvpn@ovpn-client
# systemctl status openvpn@ovpn-client
...
Status: "Pre-connection initialization successful"
CPU: 19ms
Oct 04 02:11:29 ovpn-client systemd[1]: <email address hidden>: Main process exited, code=exited, status=1/FAILURE
Oct 04 02:11:29 ovpn-client systemd[1]: <email address hidden>: Failed with result 'exit-code'.
...
If you inspect journalctl, you will see the following failure:
# journalctl -xeu openvpn@ovpn-client
...
Oct 04 02:12:32 ovpn-client ovpn-ovpn-
Oct 04 02:12:32 ovpn-client ovpn-ovpn-
Oct 04 02:12:32 ovpn-client ovpn-ovpn-
...
** Testcase for the new "tls-cert-profile insecure" option
Aside from regenerating the certificates (which is something that not everyone can do), upstream has implemented a new parameter that can be specified to enable the use of legacy crypto algorithms: "tls-cert-profile insecure". If we add this option to the configuration file and try to start the service again, we will then see the following error on journalctl:
...
Oct 04 02:16:46 ovpn-client ovpn-ovpn-
Oct 04 02:16:46 ovpn-client ovpn-ovpn-
Oct 04 02:16:46 ovpn-client systemd[1]: <email address hidden>: Main process exited, code=exited, status=1/FAILURE
...
** Testcase for the new "providers" option
The Jammy OpenVPN package already carries a patch that loads the "legacy" OpenSSL 3 providers by default. Arguably, the new "providers" option that's being added with in this SRU simply gives the user a choice to decide whether to enable the legacy providers or not. However, since we've already shipped a version of OpenVPN with these providers enabled, it's now unlikely that we will revert this change and potentially break scripts out there.
An easy (but superficial) way to test this new option is to include the following line in the configuration file:
"providers legacy default"
Upon restarting the OpenVPN service with the current version in Jammy, an error will be triggered because the option is not recognized.
[Where problems could occur]
The new options being added ("tls-cert-profile legacy" and "providers legacy") don't introduce a possibility to causing regressions, but they still could cause breakage if they're used. However, the fact that the OpenVPN package on Jammy already loads legacy OpenSSL providers by default makes these options no-ops in terms of functionality change. The risk for regression is minimal; if it exists, it will likely be associated with the code responsible for parsing the new parameters.
Arguably, the "new" feature this patchset adds is the ability to use the legacy SHA1 crypto algorithm for certificates, which is something that has been broken ever since we backported the OpenSSL 3 support to the package. The code this "new" feature exercises, however, has been part of OpenVPN for quite a while; we're merely re-enabling it. Therefore, it is very unlikely that it will cause any regressions.
Finally, there are cosmetic changes that are being backported, like new error messages, improvements to cipher listings or simple code refactoring. The regression potential with these changes is minimal.
[Other Info]
- All the patches applied in this SRU were provided by one of the upstream maintainers. This is not a random selection of things.
- We have pre-discussed with the SRU team that in this case we can not verify each patch/change individually. We have worked on trying to get some covered as we have been able to come up with a setup, but would ask for it to not be blocked on "but it needs a test for each line changed" kind of thinking. Instead we'd like to ask to accept it as discussed and in addition maybe let it be in -proposed for a bit longer than usual.
--- ---
[Original Message]
Upstream developer of OpenVPN here. We basically got caught off guard by distributions like Ubuntu already bundling OpenVPN with OpenSSL 3.0 and had hoped to release OpenVPN 2.6 which has proper OpenSSL 3.0 earlier. So far OpenVPN 2.5.x has a number of shortcoming/bugs when used with OpenSSL 3.0. We backported/fixed most of them for 2.5.7.
As much as we as upstream would prefer using 2.5.7, I think Ubuntu policy is not to update to new upstream version. But some of the bugs might be considered bugs worthy still fixing in Ubuntu 22. So I am listing here the bug/fixes that you might consider:
The individual fixes/bugs are (all from the release/2.5 branch):
- sending "new" OpenSSL digest names and causing auth mismatch warnings:
https:/
- Add message when decoding PKCS12 file fails.
https:/
Several old OpenSSL version default to RC2-40-CBC when encoding pkcs12 which OpenSSL 3.0 does not
like anymore and this at least gives a better error in these cases
- Fix allowing/showing unsupported ciphers and digests
https:/
Without this patch OpenVPN will error out much much later when choosing a cipher like BF-CBC that
is only provided by the legacy provider.
- Allow loading of non default providers
https:/
Even though insecure a lot of people still run OpenVPN config with the bf-cbc cipher. This commit
allows using it again when using --providers legacy default.
(Needs https:/
- Add insecure tls-cert-profile options
https:/
This one is already picked up.
Related branches
- Ubuntu Server Developers: Pending requested
- Canonical Server: Pending requested
- Canonical Server Reporter: Pending requested
-
Diff: 985 lines (+927/-0)9 files modifieddebian/changelog (+7/-0)
debian/patches/openssl-3/0001-Add-insecure-tls-cert-profile-options.patch (+83/-0)
debian/patches/openssl-3/0002-Refactor-early-initialisation-and-uninitialisation-into-methods.patch (+71/-0)
debian/patches/openssl-3/0003-Allow-loading-of-non-default-providers.patch (+293/-0)
debian/patches/openssl-3/0004-Fix-allowing-showing-unsupported-ciphers-digests.patch (+136/-0)
debian/patches/openssl-3/0005-Add-message-when-decoding-PKCS12-file-fails.patch (+44/-0)
debian/patches/openssl-3/0006-Translate-OpenSSL-3.0-digest-names-to-OpenSSL-1.1-digest-names.patch (+91/-0)
debian/patches/openssl-3/0007-Allow-running-a-default-configuration-with-TLS-libraries-without-BF-CBC.patch (+194/-0)
debian/patches/series (+8/-0)
- Bryce Harrington (community): Approve
- git-ubuntu bot: Approve
- Canonical Server Reporter: Pending requested
- Canonical Server: Pending requested
-
Diff: 202 lines (+119/-6)7 files modifieddebian/changelog (+21/-0)
debian/control (+2/-1)
debian/patches/openssl-3-support.patch (+89/-0)
debian/patches/series (+1/-0)
debian/tests/control (+2/-2)
debian/tests/server-setup-with-ca (+1/-1)
debian/tests/server-setup-with-static-key (+3/-2)
tags: | added: server-todo |
Changed in openvpn (Ubuntu Jammy): | |
assignee: | nobody → Lucas Kanashiro (lucaskanashiro) |
Changed in openvpn (Ubuntu Kinetic): | |
assignee: | nobody → Lucas Kanashiro (lucaskanashiro) |
tags: | added: transition-openssl3-jj |
tags: | added: patch |
description: | updated |
description: | updated |
Changed in openvpn (Ubuntu Jammy): | |
assignee: | Lucas Kanashiro (lucaskanashiro) → nobody |
Changed in openvpn (Ubuntu Jammy): | |
status: | New → Confirmed |
Changed in openvpn (Ubuntu Jammy): | |
importance: | Undecided → High |
Changed in openvpn (Ubuntu Kinetic): | |
assignee: | Lucas Kanashiro (lucaskanashiro) → nobody |
Changed in openvpn (Ubuntu Jammy): | |
assignee: | nobody → Sergio Durigan Junior (sergiodj) |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
Status changed to 'Confirmed' because the bug affects multiple users.