[BPO] openvpn/2.6.12 from Noble to Jammy

[Jorge Merlino]

[Impact]

Currently openvpn in Jammy is broken when FIPS is enabled. The TL;DR reason is that openvpn 2.5 does not support openssl 3 very well. There were a number of fixes in openvpn 2.6 to fix this.
Explaining a bit more the basic issue is that openssl 3 does not allow the use of the MD5 algorithm for random number generation in FIPS mode and openvpn 2.5 is still using it (LP bug #2091575). There are also other issues, for example that openvpn sees no available ciphers when FIPS is enabled which can be easily tested as running

openvpn --show-ciphers

returns nothing (LP bug #2077769).
I have a patch for openvpn 2.5 to fix this which I tried to SRU in bug #2077769 but failed to get sponsored as it is a significant change. The sponsor suggested backporting instead as the issue does not affect non-FIPS systems and so they can keep using the current package.

[Scope]

From Noble (2.6.12-0ubuntu0.24.04.1) to Jammy (currently 2.5.11-0ubuntu0.22.04.1)

[Other Info]

My original SRU patch also fixed bug #2086809. This is not a code patch as only affects package testing. This should be SRUd by itself.

[Jorge Merlino (jorge-merlino)]

Debdiff against Noble version of openvpn

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "lp2097688.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

[Simon Quigley (tsimonq2)]

Hey Jorge, thanks for the patch!

Could you please separate out the histories for 24.04 and 22.04? Meaning, changelog entries with a 24.04 suffix should not go into 22.04. This may make the diff quite large; in this case, it would be helpful to provide a diff against https://launchpad.net/ubuntu/+source/openvpn/2.6.12-1ubuntu1 as well, to gauge any changes specific to the stable release.

Thanks for your efforts here! Please resubscribe ~ubuntu-sponsors to the bug once you've attached those diffs.

[Mattia Rizzolo (mapreri)]

@tsimonq2: acqully no, in backports we follow the security team recommendation about versioning, and we also explicitly document on https://wiki.ubuntu.com/UbuntuBackports#Preparing_the_Backported_Package an example which has two ubuntu releases in the version string.

I agree it is a bit jarring to see, but it's there just as a safe case for upgrade paths. :)
Think about a case of this package being versioned 2.6.12-0ubuntu0~bpo22.04.1; this would let you update to a potential 2.6.12-0ubuntu0.24.04.0, which could in theory represent a downgraded! All very theoretical, I know, but...

(btw, I'm not clear what you mean with "may make the diff quite large"? diff against what would get you something large?)

@jorge-merlino: rather, the changelog should document what changes you have done (and why) to the version you have based the backport on; in this case, you haven't documented the dependency change.

[Jorge Merlino (jorge-merlino)]

New patch version. Added documentation for changes and also added Breaks rule for network-manager-openvpn as the package has patches for openvpn 2.6 in noble.

[Vladimir Petko (vpa1977)]

Hi,

Thank you for the patch!

Minor nits:
 - trailing whitespaces in changelog after LP: #2091575
 - typo in dependencies
- added " - Add Breaks: network-manager-openvpn (<< 1.10.2-1)." line in the changelog.

I will run build/autopkgtests in https://launchpad.net/~vpa1977/+archive/ubuntu/plusone2
Update: build/test passes.

Would it be possible to write the test scenario for the FIPS system?

Best Regards,
 Vladimir.

[Jorge Merlino (jorge-merlino)]

Hi Vladimir, thank you for your help.
I think the test plan from LP: #2077769 should cover both cases (FIPS and non-FIPS). Do you want me to copy it over here?

Regards

[Dave Jones (waveform)]

Based on Vladimir's tests passing, and the major points being addressed, this seems ready for sponsorship to jammy. I'll upload making the trivial tweaks to d/changelog that Vladimir pointed out. On the subject of copying the test-plan it would *appear*, looking at the BPO process [1] that the template for backports doesn't include a test-plan. Still, I would concur it would be nice to see one here (specifically the one suggested) to give the team some guidance on what has actually been tested.

[1]: https://wiki.ubuntu.com/UbuntuBackports#Preparing_the_Backported_Package

[Jorge Merlino (jorge-merlino)]

[Test Plan]
The bug can be reproduced by just running:

openvpn --show-ciphers

The non-patched version returns no algorithms and the patched version should include a list of cipher algorithms like this:

AES-128-CBC (128 bit key, 128 bit block)
AES-128-CFB (128 bit key, 128 bit block, TLS client/server mode only)
AES-128-CFB1 (128 bit key, 128 bit block, TLS client/server mode only)
AES-128-CFB8 (128 bit key, 128 bit block, TLS client/server mode only)
AES-128-GCM (128 bit key, 128 bit block, TLS client/server mode only)
AES-128-OFB (128 bit key, 128 bit block, TLS client/server mode only)
...

To make sure no regressions are introduced we can create two VMs and test a VPN connection between them both with and without FIPS enabled. For the non-FIPS case we will use a legacy cipher that is not supported in FIPS. The path to enable this legacy algorithms is the one that breaks FIPS in the first place.

Non-fips case:

Install server VM:

sudo apt install -y openvpn easy-rsa
sudo make-cadir /etc/openvpn/easy-rsa
sudo -i
cd /etc/openvpn/easy-rsa
./easyrsa init-pki
./easyrsa build-ca nopass
# accept default value for parameter
./easyrsa gen-req myserver nopass
# accept default value for parameter
./easyrsa gen-dh
./easyrsa sign-req server myserver
# type yes
cp pki/dh.pem pki/ca.crt pki/issued/myserver.crt pki/private/myserver.key /etc/openvpn
./easyrsa gen-req myclient nopass
# accept default value for parameter
./easyrsa sign-req client myclient
# type yes
scp pki/ca.crt pki/issued/myclient.crt pki/private/myclient.key <user>@<client_address>
cd /etc/openvpn
openvpn --genkey secret ta.key
scp ta.key <user>@<client_address>
cat > server.conf <<EOL
port 1194
proto udp
dev tun
ca ca.crt
cert myserver.crt
key myserver.key
dh dh.pem
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist /var/log/openvpn/ipp.txt
keepalive 10 120
tls-auth ta.key 0
cipher DES-CBC # old deprecated algorithm
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
explicit-exit-notify 1
EOL
systemctl start openvpn@server

Install client VM:

sudo apt install -y openvpn
sudo cp myclient.crt ca.crt ta.key myclient.key /etc/openvpn
# these files where copied from the server
sudo -i
# replace <server_ip> for the server IP in the following command
cat > /etc/openvpn/client.conf <<EOL
client
dev tun
proto udp
remote <server_ip> 1194
nobind
persist-key
persist-tun
ca ca.crt
cert myclient.crt
key myclient.key
remote-cert-tls server
tls-auth ta.key 1
cipher DES-CBC # old deprecated algorithm
EOL
systemctl start openvpn@client

After installing and starting openvpn both client and server should have a tun0 interface. It should be possible to ping the server interface from the client:

ping 10.8.0.1

And from the server ping the client interface:

ping 10.8.0.2

Fips case:

For the fips case I removed the tls-auth option as the unpatched openvpn cannot even generate the ta.key file on fips enabled systems. The patched version can generate the key and works with tls-auth enabled.

Install server VM:

sudo pro attach <token>
sudo pro enable fips-updates
sudo reboot
sudo apt install -y openvpn easy-rsa
sudo make-cadir /etc/openvpn/easy-rsa
sudo -i
cd /etc/openv...

[Lukas Märdian (slyon)]

Jorge, thanks for providing a test-plan! I see this is already sponsored and pending review by the backports team in the unapproved queue: https://launchpad.net/ubuntu/jammy/+queue?queue_state=1&queue_text=openvpn

I'm therefore unsubscribing the ~ubuntu-sponsors team. Feel free to re-subscribe, should anything else need additional sponsoring.

[Mattia Rizzolo (mapreri)]

It's in the wrong queue, it has "Distribution: jammy" instead of "Distribution jammy-backports".

Now it will need somebody from the SRU team to reject it, a rebuild and re-upload.

I'm not sure how that happened, it used to be the case when somebody used sbuild with `-d DIST` instead of `-c DIST` (`-d` by definition changes the content of the Distribution field, so..., despite that it was the go-to flag to use to build stable updates).

[Thomas Ward (teward)]

@mapreri: target Distribution is based on changelog entry I believe when uploaded, even with `-d DIST` in `sbuild`. So that's something to always check in changelog that it targets the correct pocket (jammy-backports instead of jammy).

[Mattia Rizzolo (mapreri)]

nope, sbuild -d is a clear override of what's in the changelog: "Explicitly set the distribution for the package build. This will be selecting the correct chroot to use and also sets the value of the Distribution field in the created .changes file"

Indeed I checked the .changes file that was in the queue, and the "Changes:" field of the file did contain "jammy-backports" as it should have, opposed to the Distribution field.