CVSROOT: /cvs
Module name: src
Changes by: js...@cvs.openbsd.org 2020/04/09 11:54:38
Modified files:
lib/libssl : ssl_ciph.c
Log message:
Include TLSv1.3 cipher suites unless cipher string references TLSv1.3.
OpenSSL has always taken the approach of enabling almost everything by
default. As a result, if you wanted to run a secure TLS client/server
you had to specify your own "secure" cipher string, rather than being
able to trust the defaults as being sensible and secure. The problem
is that with the introduction of TLSv1.3, most of these "secure" cipher
strings result in the new TLSv1.3 cipher suites being excluded.
The "work around" for this issue in OpenSSL was to add a new TLSv1.3
API (SSL_CTX_set_ciphersuites(), SSL_set_ciphersuites()) and have separate
knobs for the pre-TLSv1.3 and TLSv1.3 cipher suites. This of course means
that every application now needs to call two APIs, but it does mean that
applications that only call SSL_CTX_set_cipher_list()/SSL_set_cipher_list()
cannot remove TLSv1.3 cipher suites and prevent TLSv1.3 from working.
We've taken a different approach and have allowed TLSv1.3 cipher suites
to be manipulated via the existing SSL_set_cipher_list() API. However,
in order to avoid problems with hardcoded cipher strings, change this
behaviour so that we always include TLSv1.3 cipher suites unless the
cipher string has a specific reference to the TLSv1.3 protocol or a
TLSv1.3 cipher suite.
This means that:
$ openssl ciphers -v TLSv1.2:!TLSv1.3
still gives TLSv1.2 only cipher suites and:
$ openssl ciphers -v AEAD-CHACHA20-POLY1305-SHA256
only lists a single TLSv1.3 cipher, however:
$ openssl ciphers -v ECDHE-RSA-AES256-GCM-SHA384
now includes both TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 and all TLSv1.3
cipher suites (which also matches OpenSSL's openssl(1) behaviour).
Issue encountered by kn@ with mumble.
ok tb@
