A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_6_8_BASE 2020-09-24T18:12:00+00:00 2020-09-24T18:12:00+00:00 jsing 2020-09-24T18:12:00+00:00 urn:sha1:10841ee643f560678ff5ed0276c4da735ec37bdf ok beck@ inoguchi@ tb@ 2020-09-19T10:17:56+00:00 tb 2020-09-19T10:17:56+00:00 urn:sha1:3efe302d9cf5eaaed1c23c0b40d5bb43404367da This is a convenience reacharound to libcrypto that trivially wraps X509_VERIFY_PARAM_get0_peername(). It is used by unbound 1.11.0 for better logging. As it's part of the API that landed with OpenSSL's DANE, more recent postfix snapshots use it as well. ok beck inoguchi jsing 2020-09-19T10:12:06+00:00 tb 2020-09-19T10:12:06+00:00 urn:sha1:ca0243067b7fd199734d0175dd0fadafdce122fc We do not support this feature but need to provide OpenSSL's API since software assumes it's available whenever TLS1_3_VERSION is available. These are minimal stubs that should have a decent chance to interact reasonably with software expecting the tricky upstream semantics, but this will have to be sorted out with runtime testing, so will likely have to be refined and revisited. ok beck jsing 2020-09-19T10:05:00+00:00 tb 2020-09-19T10:05:00+00:00 urn:sha1:1e4262bd018904cc16b72e9d2f9d77fa1615d2e5 Similar to the SSL_SESSION versions, these are noops that are expected to be available by some configure tests. ok beck jsing 2020-09-18T16:18:56+00:00 schwarze 2020-09-18T16:18:56+00:00 urn:sha1:4e89e6316f0d83fc4353025be7399e53c4722ddf rather than silently leaving a NULL pointer in ssl->cert. Kurt Roeckx fixed the same bug similarly in OpenSSL in 2015. While here, (1) make the code easier to read and more robust by returning right away when ssl still uses the context it was created from and the ctx argument is NULL, rather than doing a lot of work that changes nothing unless data is already corrupt, and (2) use the shorter and more inituitive SSL_CTX_up_ref(3) rather than manually calling CRYPTO_add(3), which means no functional change and is also in the OpenSSL 1.1 branch. OK tb@ 2020-09-16T07:25:15+00:00 schwarze 2020-09-16T07:25:15+00:00 urn:sha1:0d5002a003b2ecd714e61bae648a18dcf624e8f5 for compatibility with OpenSSL and for consistency with neighbouring functions; suggested by jsing@ after i documented the crash; OK jsing@. 2020-09-15T11:47:49+00:00 jsing 2020-09-15T11:47:49+00:00 urn:sha1:c36b1536473dcd5e4c47ff8670f988f59b9a2e07 In particular, figure what the handshake_func should be early on, so we can just assign later. ok beck@ 2020-09-14T18:34:12+00:00 jsing 2020-09-14T18:34:12+00:00 urn:sha1:19d5c8d7425a9d4517537df292f7643d0ee9a618 If we use the default method (now TLSv1.3) and end up talking to a TLSv1.2 server that gives us a session ticket, then try to resume that session, we end up trying to talk TLS without doing a handshake. This is caused by the state (S3I(s)->hs.state) getting cleared, which results in SSL_do_handshake() and others thinking they do not need to do anything (as SSL_in_init() and SSL_in_before() are not true). The reason this occurs is due to SSL_set_ssl_method() calling ssl_free() and ssl_new() when switching methods. The end result is that the S3I(s) has been freed and reallocated, losing the state in the process. Since the state is part of the S3I(s) structure, move its initialisation into ssl3_clear() - this ensures it gets correctly reinitialised across a SSL_set_ssl_method() call. Issue noticed by sthen@ with nginx and unifi. ok beck@ tb@ 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@