Connecting through OpenVPN with deprecated ciphers, using Docker

Caution! This is a developer horror story 👻, Halloween 2022 comes with a nightmare for those who use a VPN. OpenSSL released the version 3.0.7 as the latest stable, if you compare that we're talking about a jump from 1.1.1 to 3.0.7 we can think that any already deprecated protocol was removed to guarantee the security of our systems! And, it happened.
Arch Linux, with its philosophy of using the latest stable release of everything, applied the OpenSSL v3 on Saturday morning November 5.

Note: Treating option '--ncp-ciphers' as '--data-ciphers' (renamed in OpenVPN 2.5).
WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
--cipher is not set. Previous OpenVPN version defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
Unsupported cipher in --data-ciphers: BF-CBC
Options error: NCP cipher list contains unsupported ciphers or is too long.
Use --help for more information.

Surprise! You can't use the BF-CBC cipher on OpenVPN anymore, because it was removed from OpenSSL itself; OpenVPN plans to remove it on 2.7 but we're currently in 2.5.8 at the moment.

Downgrading the openssl package is a possible solution but not the best. Should I move my development environment to a virtual machine? 🙀 Change to an old Ubuntu version? Not for me. Here is when the hero 🦸 of this story appears to save us, and its name is Docker 🐳.

💡 You can receive an alternative error message in Ubuntu or other Linux distributions:

OpenVPN 2.5.5 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 14 2022
library versions: OpenSSL 3.0.2 15 Mar 2022, LZO 2.10
WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead.
OpenSSL: error:0A00018E:SSL routines::ca md too weak
Cannot load inline certificate file
Exiting due to fatal error

The solution

The containers can use the same network of the host, this avoids the container being network isolated, and the VPN tunnel is shared with our host system.

Creating the image

For this example I'll use a simple ovpn file, but with a few tweaks I'm sure this will work for you too.

FROM ubuntu:focal

RUN apt update && \
  apt install -y openvpn && \
  rm -rf /var/lib/apt/lists/*

COPY profile.ovpn /etc/openvpn/client/

CMD ["openvpn", "/etc/openvpn/client/profile.ovpn"]

We based our image on Ubuntu 20.04 LTS (Focal Fossa), just install the openvpn package and copy your OpenVPN configuration file inside. Maybe you need a .p12, .key, or .crt files just to copy them too.

🧠 We can't use Ubuntu 22.04 LTS (Jammy Jellyfish) because it received the update to OpenSSL 3.0.2.

Build the image with the following command:

docker build -t openvpn .

Starting the container

Now, we can run the container!

docker run --name=vpn \
  --cap-add=NET_ADMIN \
  --network=host \
  --device /dev/net/tun \
  -it openvpn

The container needs the Linux kernel capability of network administration to create a VPN tunnel with the --cap-add=NET_ADMIN argument. Also --device /dev/net/tun gives access to the tunnel device of the host.

⚠️ Don't give kernel capabilities or access to devices if you don't trust the publisher.

Once started, the container could ask for your credentials (username and password) to establish the VPN connection and it's done! 🎉

Conclusion

Some changes can't be applied in enterprise environments without analyzing all possible scenarios, and the change of this cipher could take some time. That's where Docker could help us to continue using old software in a controlled way for specific tasks without compromising the security of our system.

I hope you don't get scared with this story, but Super-Docker saves the day, one more time. Tell me in the comments if this helped you, or if you found another solution.