WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/lib/libssl/ssl_ciph.c?h=jd%2Fqueueboosts 2020-04-19T14:54:14Z 2020-04-19T14:54:14Z jsing jsing@openbsd.org 2020-04-19T14:54:14Z urn:sha1:37c0027064b5050f1d87dbca47f76dd5d193105b ok beck@ inoguchi@ tb@ 2020-04-18T14:41:05Z jsing jsing@openbsd.org 2020-04-18T14:41:05Z urn:sha1:a18ccef7adc8ac8c78f73e4dbb803f93c9a24bc2 2020-04-18T13:47:58Z jsing jsing@openbsd.org 2020-04-18T13:47:58Z urn:sha1:8dad4ecb25bf0e42b29ea4d0f0a8096bd6f8c3eb Use a boolean value rather than using a counter, as suggested by tb@ during the previous review. ok tb@ 2020-04-17T17:26:00Z jsing jsing@openbsd.org 2020-04-17T17:26:00Z urn:sha1:b081269e8dd6e93000d2b64d7af26e4809cfc8d2 Revise the previous so that we only include TLSv1.3 cipher suites if the cipher rule string resulted in at least one active cipher suite. This more closely matches OpenSSL behaviour. Noted and fix tested by schwarze@ ok beck@ tb@ 2020-04-09T17:54:38Z jsing jsing@openbsd.org 2020-04-09T17:54:38Z urn:sha1:99d0ff65c9d18b73e204419b876ce289277dae70 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@ 2020-04-09T17:24:11Z jsing jsing@openbsd.org 2020-04-09T17:24:11Z urn:sha1:b0082fd32695cedb4e14925f69e0e10f17214e9a 2020-04-09T17:22:52Z jsing jsing@openbsd.org 2020-04-09T17:22:52Z urn:sha1:4669ad9c70247d5bc2826634cb526808bd9b9e34 explicitly comparing against a value. 2020-01-26T12:39:16Z inoguchi inoguchi@openbsd.org 2020-01-26T12:39:16Z urn:sha1:783b23ad643c94c3b2cb100fdf1d6fcde2fd1abe ok jsing@ 2020-01-24T04:38:12Z jsing jsing@openbsd.org 2020-01-24T04:38:12Z urn:sha1:b1b5d3f0646e4456ecfa4aed50369baecda7c272 Mkaes `openssl ciphers -v` print au and kx values for TLSv1.3 cipher suites. ok beck@ tb@ 2019-04-04T16:44:24Z jsing jsing@openbsd.org 2019-04-04T16:44:24Z urn:sha1:e58f6cbccfc575d5a35c909de132911b190c623a The original implementation allows for libcrypto to be compiled without a given algorithm and libssl then detects that ciphers or digests are unavailable so that it can disable the associated cipher suites. This is unnecessary since we do not compile out algorithms. ok beck@, tb@ (a while back)