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

[Viktor Dukhovni]

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

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?

-- 
	Viktor.