Hi all,

What I'm trying to figure out: what's the best way to check whether
3DES/RC4 support are available in the OpenSSL build we're using, so
that we can give users a clearer explanation of why a connection to an
ancient server fails?

Background:

I'm one of the developers of OpenConnect and recently I've been
working on some tests and CI to ensure that we don't mysteriously
break the ability to connect to old VPN servers with new TLS library
versions (either OpenSSL or GnuTLS):
https://gitlab.com/openconnect/openconnect/-/merge_requests/114

Obviously this isn't news to the OpenSSL developers, but 3DES is old,
bad, insecure, and disabled by default as of OpenSSL 1.1.0
(https://www.openssl.org/blog/blog/2016/08/24/sweet32/).

Unfortunately, there are still a good number of unpatched corporate
VPN servers out there which can't do any better than TLS 1.0 with 3DES
or RC4. They shouldn't be considered secure in any way, but many users
still need to be able to connect to them and often can't get their IT
departments to update them.

When OpenConnect is explicitly requested to connect to an ancient
server, what I am currently trying to do is
SSL_CTX_set_cipher_list(ctx, "DEFAULT:+3DES:+RC4"). However, this
fails silently on subsequent connection if 3DES/RC4 support isn't
available.

Other than looping through all of the ciphers with SSL_get_ciphers()
right after this… is there a better way to check for 3DES/RC4 support
right at startup, so we can give immediate feedback that connecting to
such a server cannot succeed?

Thanks,
Dan Lenski

Reply via email to