OpenVPN 2.6 Development version

[ummeegge (Erik Kapfer)]

Hello @bonnietwin,
try to make the answer as detailed and short as possible…

@bonnietwin

Hi @ummeegge

Version 2.6.0 seems to be coming to the breakage point for IPFire unless I am have misunderstood some of the changelog.

ncp-disable, which is currently used in the IPFire client connection configuration is completely removed in 2.6.0 also Openssl-3.x is configured making many old ciphers no longer supported. That would stop OpenVPN with any 64 bit ciphers that people still might be using.

According to ‘–ncp-disable’ you are right this directive has been removed and need to be replaced wit ‘–data-ciphers’ on IPFire´s server.conf.
OpenVPN is OpenSSL-3.x ready but OpenVPN itself does NOT exclude 64 bit block ciphers, OpenSSL does it with the default configuration. If you use the legacy mode you will be able to use them also with OpenVPN-2.6.x on IPFire.

@bonnietwin

That would break their OpenVPN connections, which is not a good idea, even if we think they shouldn’t run with such weak and insecure ciphers. Not sure how many people would still be using them. Not easy to find out.

The fix for that would be to add a legacy option into the client .ovpn file, however that is not something that could be done automatically as part of a Core Update. This would mean that at a Core Update anyone using the now blocked ciphers would have to go and modify all their client connections before they do a CU

Some tests from my side:

OpenVPN on IPFire runs:

OpenVPN 2.6.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] [DCO]
library versions: OpenSSL 1.1.1s  1 Nov 2022, LZO 2.10

Client Fedora 37 (Workstation Edition) with:

OpenVPN 2.5.8 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Nov  1 2022
library versions: OpenSSL 3.0.5 5 Jul 2022, LZO 2.10

If a client uses ‘–cipher BF-CBC’ but IPFire OpenVPN server uses ‘–data-ciphers ChaCha20-Poly1305:AES-256-GCM’

you get a warning on server side with

Jan 31 15:16:01 ipfire-prime openvpnserver[7424]: WARNING: --topology net30 support for server configs with IPv4 pools will be removed in a future release. Please migrate to --topology subnet as soon as possible.
Jan 31 15:16:01 ipfire-prime openvpnserver[7424]: DEPRECATED OPTION: --cipher set to 'BF-CBC' but missing in --data-ciphers (ChaCha20-Poly1305:AES-256-GCM). OpenVPN ignores --cipher for cipher negotiations.

and on client side:

2023-01-31 15:19:33 us=228946 DEPRECATED OPTION: --cipher set to 'BF-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'BF-CBC' to --data-ciphers or change --cipher 'BF-CBC' to --data-ciphers-fallback 'BF-CBC' to silence this warning.

but the connection comes up and AES-GCM will be used →

Jan 31 15:19:40 ipfire-prime openvpnserver[7425]: testNewone/192.168.1.5:40723 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jan 31 15:19:40 ipfire-prime openvpnserver[7425]: testNewone/192.168.1.5:40723 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

You can silence the warning on server side with ‘–data-ciphers-fallback BF-CBC’ and as before ‘’–data-ciphers ChaCha20-Poly1305:AES-256-GCM’

but on client side if no changes has been made it appears again →

2023-01-31 15:19:33 us=228946 DEPRECATED OPTION: --cipher set to 'BF-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'BF-CBC' to --data-ciphers or change --cipher 'BF-CBC' to --data-ciphers-fallback 'BF-CBC' to silence this warning.

i think AEAD is since OpenSSL-1.0.1 available and most of the clients out there should uses >= !!! In my humble opinion, this problem should be semantics in the configuration file not a technical one if NCP is in usage?!

So a WUI solution like this →

comes for me to mind.

@bonnietwin

I know that this has been a big discussion point in the past about not breaking peoples existing connection configurations with a CU but it seems to me that openvpn-2.6.0 will cause that to happen if we move to it. I can’t see a way around it, unless you have figured something out.

It might be good to check NCP since the cipher negotiation will ignore old deprecated ciphers like DES* or Blowfish, … if the data-ciphers has been set. Nevertheless, under specific circumstances you will find warnings like

WARNING: INSECURE cipher (BF-CBC) with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Support for these insecure ciphers will be removed in OpenVPN 2.7.

so the clock runs but the clock also runs on other topics since ‘–topology net30’ is also deprecated and should be replaced with ‘–topology subnet’ which seems to be a bigger task for a little more far future and the usage of OpenVPN-2.7.x .

@bonnietwin

I have added the topic of openvpn-2.6.0 to the agenda of the next developers conf call.

Great

According to the backwards compatibility of the old ‘–cipher’ directive on client configuration files, haven´t checked the new ‘–compat-mode version’ → openvpn which can be used on server side, may there is a way to make it more easy also with OpenVPN-2.7 ?

I leave the discussion about DCO for the first out of here.

Hope this helps for the first.

Best,

Erik

P.S.: openvpnctrl seems not to close the socket after a reboot

Jan 31 15:54:38 ipfire-prime openvpnserver[3720]: TCP/UDP: Socket bind failed on local address [AF_INET][undef]:1194: Address already in use (errno=98)
Jan 31 15:54:38 ipfire-prime openvpnserver[3720]: Exiting due to fatal error
Jan 31 15:54:38 ipfire-prime openvpnserver[3720]: Closing TUN/TAP interface
Jan 31 15:54:38 ipfire-prime openvpnserver[3720]: net_addr_ptp_v4_del: 10.73.104.1 dev tun1

?