checking for enable-weak-ssl-ciphers at runtime?

[Daniel Lenski]

> 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?

It was suggested that I should try EVP_get_ciphername().

I tested both EVP_get_cipherbyname("DES-EDE3-CBC") == NULL, and
EVP_des_ede3_cbc() == NULL, but unfortunately both of those APIs
appear insensitive to whether or not 3DES is actually supported by the
library.

Is there another approach to check for 3DES support before actually
creating an SSL_CTX?

On Sat, May 23, 2020 at 1:08 PM Daniel Lenski <dlenski at gmail.com> wrote:
>
> 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