2.6 client cannot connect to old 2.2 and 2.1 server

[kosli]

Describe the bug
I have upgraded a windows client to the latest 2.6.4 OpenVPN version (and also tried with 2.6.3 and 2.6.0) and tried to connect to some legacy OpenVPN servers running version 2.2.1.

To Reproduce
The OpenVPN 2.2.1 server.conf has the following basic configuration:

proto udp
dev   tap0
 
ca       ca.crt
cert     server.crt
key      server.key
dh       dh1024.pem
tls-auth ta.key 0
 
#cipher  AES-256-CBC
#cipher  BF-CBC
 
server-bridge nogw

The OpenVPN 2.6.4 client.conf has the following basic configuration:

client
dev tap
proto udp

remote server.example.com 1180 udp4

resolv-retry infinite
nobind
persist-key
persist-tun

auth-nocache

ca   ca.crt
cert client.crt
key  client.key

remote-cert-tls server
tls-auth ta.key 1
comp-lzo no

verb 3

providers legacy default
tls-version-min 1.0

cipher BF-CBC
data-ciphers BF-CBC
data-ciphers-fallback BF-CBC

Client log:

2023-05-30 14:57:39 us=500000 OpenVPN 2.6.0 [git:v2.6.0/b999466418dddb89] Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] [DCO] built on Feb 15 2023
2023-05-30 14:57:39 us=500000 Windows version 10.0 (Windows 10 or greater), amd64 executable
2023-05-30 14:57:39 us=500000 library versions: OpenSSL 3.0.8 7 Feb 2023, LZO 2.10
2023-05-30 14:57:39 us=500000 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25344
2023-05-30 14:57:39 us=500000 Need hold release from management interface, waiting...
2023-05-30 14:57:39 us=984000 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:55428
2023-05-30 14:57:40 us=93000 MANAGEMENT: CMD 'state on'
2023-05-30 14:57:40 us=93000 MANAGEMENT: CMD 'log on all'
2023-05-30 14:57:40 us=234000 MANAGEMENT: CMD 'echo on all'
2023-05-30 14:57:40 us=234000 MANAGEMENT: CMD 'bytecount 5'
2023-05-30 14:57:40 us=234000 MANAGEMENT: CMD 'state'
2023-05-30 14:57:40 us=234000 MANAGEMENT: CMD 'hold off'
2023-05-30 14:57:40 us=234000 MANAGEMENT: CMD 'hold release'
2023-05-30 14:57:40 us=250000 MANAGEMENT: CMD 'password [...]'
2023-05-30 14:57:40 us=250000 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.
2023-05-30 14:57:40 us=250000 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2023-05-30 14:57:40 us=250000 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2023-05-30 14:57:40 us=250000 Control Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1250 tun_max_mtu:0 headroom:126 payload:1600 tailroom:126 ET:0 ]
2023-05-30 14:57:40 us=250000 MANAGEMENT: >STATE:1685451460,RESOLVE,,,,,,
2023-05-30 14:57:40 us=296000 Data Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1800 tailroom:568 ET:32 ]
2023-05-30 14:57:40 us=296000 TCP/UDP: Preserving recently used remote address: [AF_INET]10.9.0.166:1180
2023-05-30 14:57:40 us=296000 Socket Buffers: R=[65536->65536] S=[65536->65536]
2023-05-30 14:57:40 us=296000 UDPv4 link local: (not bound)
2023-05-30 14:57:40 us=296000 UDPv4 link remote: [AF_INET]10.9.0.166:1180
2023-05-30 14:57:40 us=296000 MANAGEMENT: >STATE:1685451460,WAIT,,,,,,
WR2023-05-30 14:57:40 us=359000 MANAGEMENT: >STATE:1685451460,AUTH,,,,,,
2023-05-30 14:57:40 us=359000 TLS: Initial packet from [AF_INET]10.9.0.166:1180, sid=21143748 4864cfb4
WRRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWR2023-05-30 14:57:40 us=796000 VERIFY OK: depth=1, C=CH, O=xxx, CN=xxx CA, emailAddress=certmaster@xxx.xxx
2023-05-30 14:57:40 us=796000 VERIFY KU OK
2023-05-30 14:57:40 us=796000 Validating certificate extended key usage
2023-05-30 14:57:40 us=796000 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2023-05-30 14:57:40 us=796000 VERIFY EKU OK
2023-05-30 14:57:40 us=796000 VERIFY OK: depth=0, CN=alix-158
WRWRWRWRWR2023-05-30 14:57:40 us=875000 OpenSSL: error:0A00014D:SSL routines::legacy sigalg disallowed or unsupported
2023-05-30 14:57:40 us=875000 TLS_ERROR: BIO read tls_read_plaintext error
2023-05-30 14:57:40 us=875000 TLS Error: TLS object -> incoming plaintext read error
2023-05-30 14:57:40 us=875000 TLS Error: TLS handshake failed
2023-05-30 14:57:40 us=875000 TCP/UDP: Closing socket
2023-05-30 14:57:40 us=875000 SIGUSR1[soft,tls-error] received, process restarting
2023-05-30 14:57:40 us=875000 MANAGEMENT: >STATE:1685451460,RECONNECTING,tls-error,,,,,
2023-05-30 14:57:40 us=875000 Restart pause, 1 second(s)
2023-05-30 14:57:41 us=890000 MANAGEMENT: Client disconnected
2023-05-30 14:57:41 us=890000 All connections have been connect-retry-max (1) times unsuccessful, exiting
2023-05-30 14:57:41 us=890000 Exiting due to fatal error

Expected behavior
I would expect the client to connect with the server, the same way as a OpenVPN 2.5.9 client can connect to the above server.

What looks weird to me is the following line in the log SSL routines::legacy sigalg disallowed or unsupported. Especially the typo in sigalg.
I had tried changing the cipher to AES-128-CBC on both sides but that doesn't make a difference. Even setting cipher none didn't help.

It looks more like an OpenSSL problem somewhere, but I don't know where to look at.

Until version 2.5.9 it was enough to have the line data-ciphers AES-256-GCM:AES-128-GCM:BF-CBC in the configuration to connect to the old servers using the BF-CBC by default

[cron2]

Hi.

First of all, 2.1 and 2.2 are really really ancient, and the available crypto in these old versions (TLS 1.0, BF-CBC, MD5 auth, ...) are not considered secure by modern standards. Also, there is much nice stuff in 2.6 for the server side, so you really really should update.

This said, the problem here is that the OpenSSL 3.x library refuses to load one of the required algorithms - OpenSSL has become much more strict in what is considered acceptable. Please try one of the following options, or possibly both, to tell OpenSSL/OpenVPN "yes I know but I can't fix it today":

tls-cert-profile insecure
providers legacy default

it might be possible to arm-twist OpenVPN into compatibility by setting

compat-mode 2.3.0

which will take care of all the BF-CBC related configs, but I'm not sure it will auto-load the "legacy" OpenSSL provider which might be needed (MD5, SHA1)

[kosli]

Thanks @cron2
I know about the problems of the ancient versions. The newer systems are running on the latest OpenVPN versions but we have some legacy systems that cannot be upgraded easily.

I had to use all three options together to get it working:

tls-cert-profile insecure
providers legacy default
compat-mode 2.3.0

Thanks for the hint with the tls-cert-profile insecure as I haven't found that.

I assume this could be added to https://community.openvpn.net/openvpn/wiki/CipherNegotiation or some other "compatibility" page?

Btw, I wanted to see the options manually instead of using compat-mode 2.3.0 but I haven't seen a list of which options are being set by which compat-mode?

[schwabe]

@kosli this is not related to Cipher negotiation as that only describes data channel ciphers. Your issue is with TLS. That has a lot more to do with old OpenSSL version and TLS versions. Any other old OpenSSL and newer OpenSSL version will have the same problems.

The manpage section documents the option quite well and also points out the options that it sets.

[kosli]

Thanks @schwabe , you are right.
I didn't realized the problem was the OpenSSL version, wheras at least I had tried the tls-version-min option ;-)