[openssl-users] was the change in when disabled ciphers are skipped intentional?

[Sam Roberts]

On Fri, Nov 23, 2018 at 11:41 AM Viktor Dukhovni
<openssl-users at dukhovni.org> wrote:
> > On Nov 23, 2018, at 2:25 PM, Sam Roberts <vieuxtech at gmail.com> wrote:
> >
> > In 1.1.0j, if SSL_CTX_set_cipher_list() is called with "not-a-cipher"
> > or "rc4", then SSL_R_NO_CIPHER_MATCH will occur.
> >
> > In 1.1.1a, set_cipher_list() suceeds, seems to return the complete
> > cipher list (should it do this?) but later ssl_cipher_list_to_bytes()
> > will find that ssl_cipher_disabled() is true for all the ciphers, and
> > SSL_R_NO_CIPHERS_AVAILABLE will occur.

So what is happening is happening is that while there  are two APIs,
SSL_CTX_set_ciphersuites()(TLSv1.3) and
SSL_CTX_set_cipher_list()(<=TLSv1.2), they both put cipher suites into
SSL_CTX.cipher_list.

This basically makes the cipher_list error check:

    if (sk_SSL_CIPHER_num(sk) == 0) {
        SSLerr(SSL_F_SSL_CTX_SET_CIPHER_LIST, SSL_R_NO_CIPHER_MATCH);
        return 0;
     }

bogus, because even when there were, in fact zero TLSv1.2 cipher
suites configured, the check for cipher suite number will find the
number greater than zero if there are TLSv1.3 cipher suites in the
list. Which there will be, by default. The actual behaviour of  this
check depends on the order in which set_ciphersuites() and
set_cipher_list() are called, a fact I can exploit to make the API
backwards compatible for Node.js.

I will call SSL_CTX_set_ciphersuites(ctx,"") just before calling
set_cipher_list(). This will clear out the TLSv1.3 suites (we don't
support 1.3 yet). Since the 1.3 suites are gone, the check for a
length of zero causing NO_CIPHER_MATCH will now behave as it would be
expected.

This won't work in the future.

I think what really should be done is that the check for _num(sk) == 0
needs to be rewritten, to iterate the list, and find the number of
TLSv1.2 and below ciphers, and return NO_CIPHER_MATCH if that number
is zero.

Cheers,
Sam


> When I try it with ciphers(1), I get (as expected) just the TLSv1.3
> ciphers, which are configured separately from the TLSv1.2 (and below)
> ciphers:
>
>   $ /opt/openssl/1.1.1/bin/openssl ciphers -v not-a-cipher
>   TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
>   TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
>   TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD
>
> > Also, I don't understand why "not-a-cipher" matches any ciphers in
> > 1.1.1, I'd expect the cipher list to be empty.
>
> It should have the effect of disabling all SSLv3 and TLSv1.[012] ciphers,
> leaving just the TLSv1.3 ciphers enabled.
>
> Any change of behaviour you're seeing surely results from the introduction
> of a separate TLSv1.3 cipherlist, but what remains to be explained is what
> you mean by "seems to return the complete cipher list", is that a bug, a
> documentation defect or user error?