A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_6_8_BASE 2020-09-13T16:49:05+00:00 2020-09-13T16:49:05+00:00 jsing 2020-09-13T16:49:05+00:00 urn:sha1:413d6dece592534652ab298d8c9f26aca9ce2063 OpenSSL added a separate API for configuring TLSv1.3 ciphersuites. Provide this API, while retaining the current behaviour of being able to configure TLSv1.3 via the existing interface. Note that this is not currently exposed in the headers/exported symbols. ok beck@ inoguchi@ tb@ 2020-09-11T17:36:27+00:00 jsing 2020-09-11T17:36:27+00:00 urn:sha1:cb4349853bf54ac34c4b6615aa3102e8d10f685f When parsing a cipher string, a cipher list is created, before being duplicated and sorted - the second copy being stored as cipher_list_by_id. This is done only so that a client can ensure that the cipher selected by a server is in the cipher list. This is pretty pointless given that most clients are short-lived and that we already had to iterate over the cipher list in order to build the client hello. Additionally, any update to the cipher list requires that cipher_list_by_id also be updated and kept in sync. Remove all of this and replace it with a simple linear scan - the overhead of duplicating and sorting the cipher list likely exceeds that of a simple linear scan over the cipher list (64 maximum, more typically ~9 or so). ok beck@ tb@ 2020-04-19T14:54:14+00:00 jsing 2020-04-19T14:54:14+00:00 urn:sha1:9718effc62246fbcc4eadcd78c209f7cdb9cbb1c ok beck@ inoguchi@ tb@ 2020-04-18T14:41:05+00:00 jsing 2020-04-18T14:41:05+00:00 urn:sha1:9feefdb00593cc485073f55a52a596d2bd59d474 2020-04-18T13:47:58+00:00 jsing 2020-04-18T13:47:58+00:00 urn:sha1:58acb3318f8752445a05ed0786831fd86b09f29e Use a boolean value rather than using a counter, as suggested by tb@ during the previous review. ok tb@ 2020-04-17T17:26:00+00:00 jsing 2020-04-17T17:26:00+00:00 urn:sha1:918f1b46ad0c7e24d97486f423774b74e83512e3 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:38+00:00 jsing 2020-04-09T17:54:38+00:00 urn:sha1:40d2bd7c8fdb0d23f0152726baf1b34ced73e378 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:11+00:00 jsing 2020-04-09T17:24:11+00:00 urn:sha1:38d3c6539eba71a1443d5d303bbea0db86370657 2020-04-09T17:22:52+00:00 jsing 2020-04-09T17:22:52+00:00 urn:sha1:5027693980c0b4343fc638094643368216599d10 explicitly comparing against a value. 2020-01-26T12:39:16+00:00 inoguchi 2020-01-26T12:39:16+00:00 urn:sha1:8c224d682504265008ea457cb981f4d12bc2f9f6 ok jsing@