A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=libressl-v3.3.1 2020-12-05T19:34:57+00:00 2020-12-05T19:34:57+00:00 tb 2020-12-05T19:34:57+00:00 urn:sha1:e15b4af220e429099aba832b31f097b2916d19e8 ok jsing kn 2020-12-05T19:33:38+00:00 tb 2020-12-05T19:33:38+00:00 urn:sha1:8c0f6308a96a26238a44856da0cb53a3cb54bbf2 ok jsing kn 2020-12-03T22:47:22+00:00 jmc 2020-12-03T22:47:22+00:00 urn:sha1:bf90c7348aa11c405e8d6a2e0bceeb937623d4b8 2020-12-01T07:46:02+00:00 tb 2020-12-01T07:46:02+00:00 urn:sha1:d8448fdca0c2c2d2c222f03a47902325615a5996 The method unification broke an API promise of SSL_is_server(). According to the documentation, calling SSL_is_server() on SSL objects constructed from generic and server methods would result in 1 even before any call to SSL_set_accept_state(). This means the information needs to be available when SSL_new() is called, so must come from the method itself. Prior to the method unification, s->server would be set to 0 or 1 in SSL_new() depending on whether the accept method was undefined or not. Instead, introduce a flag to the internal structs to distinguish client methods from server and generic methods and copy that flag to s->server in SSL_new(). This problem was reported to otto due to breakage of DoH in net/dnsdist. The reason for this is that www/h2o relies on SSL_is_server() to decide whether to call SSL_accept() or SSL_connect(). Thus, the h2o server would end up responding to a ClientHello with another ClientHello, which results in a handshake failure. The bandaid applied to www/h2o can be removed once this fix has made it into snaps. No other breakage is known. This commit brings back only about half of the duplication removed in the method unification, so is preferable to a full revert. ok jsing 2020-11-20T08:08:02+00:00 tb 2020-11-20T08:08:02+00:00 urn:sha1:0068cc3650e1a212d865b7843ac3d0f02acce643 2020-11-20T08:03:53+00:00 tb 2020-11-20T08:03:53+00:00 urn:sha1:57ee25f03699dffb7ef2796fd99109733617f757 2020-11-17T07:02:30+00:00 tb 2020-11-17T07:02:30+00:00 urn:sha1:774388b1d62441f5f00ea24f86e824a2a113c79a 2020-11-16T18:55:15+00:00 jsing 2020-11-16T18:55:15+00:00 urn:sha1:97a181ebd909bb90e14296e0f9b4e74645c26398 This implements the key material exporter for TLSv1.3, as defined in RFC8446 section 7.5. Issue reported by nmathewson on github. ok inoguchi@ tb@ 2020-11-11T18:20:10+00:00 jsing 2020-11-11T18:20:10+00:00 urn:sha1:5bc4eba7ef5295b28908fc64844ded7577e36d50 Apparently OpenLDAP relies on this craziness to provide intermediates, rather than specifying the chain directly like a normal TLS server would. Issue noted by sthen@ and Bernard Spil, who both also tested this diff. ok tb@ 2020-11-11T18:14:12+00:00 jsing 2020-11-11T18:14:12+00:00 urn:sha1:6872c16fec8622b4dc934604415b6d1b065724fb This allows us to remove a check and will make future changes simpler. Use suitable names for tls1_generate_key_block() arguments while here. ok inoguchi@ tb@