A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_6_8_BASE 2020-07-30T16:23:17+00:00 2020-07-30T16:23:17+00:00 tb 2020-07-30T16:23:17+00:00 urn:sha1:d72120f6c7c798dbddfd43101f7adba6a8f598e0 As abieber@ found the hard way, some python frameworks (twisted, synapse) thought it a great idea to use the info callback mechanism (designed to get state information about SSL objects) to modify state information such as setting and verifying the SNI. The switch of TLS_method() to default to TLSv1.3 broke these contraptions. Further bits of the info callback mechanism will likely metastasize throughout the TLSv1.3 stack if we need them, so we only do what's really necessary now. Lots of debugging, crucial hint and testing by abieber input & ok jsing 2020-06-02T13:57:09+00:00 tb 2020-06-02T13:57:09+00:00 urn:sha1:df60c1f682ef3f1684f75488097b5b56038506de which make no sense as pointed out by gcc on sparc64. ok jsing 2020-05-10T17:13:30+00:00 tb 2020-05-10T17:13:30+00:00 urn:sha1:42977f0c5dfb5d699fb459f527b85ca475cd30aa If the client has requested middle box compatibility mode by sending a non-empty legacy_session_id, the server must send a dummy CCS right after its first handshake message. This means right after ServerHello or HelloRetryRequest. Two important improvements over the backed-out diffr: make sure that First: client and server can send their dummy CCS at the correct moment (right before the next flight or right after the current flight). Second: as jsing noted, we also need to deal with the corner case that tls13_send_dummy_ccs() can return TLS13_IO_WANT_POLLOUT. with/ok jsing 2020-05-10T16:56:11+00:00 jsing 2020-05-10T16:56:11+00:00 urn:sha1:b31d318d829815c32911ba41253883a36be79792 Rather than using a mess of SSL_AL_*, SSL_AD_*, SSL3_AD_* and TLS1_AD_* defines, provide our own TLS13_ALERT_* defines and use those. This also provides the alerts that are new to TLSv1.3. ok beck@ 2020-05-10T14:22:51+00:00 jsing 2020-05-10T14:22:51+00:00 urn:sha1:7307f1dd5e30b646fc44384ead7b0ded4fb8f217 This makes it easier to debug TLSv1.3 handshake failures. "Yes please!" tb@, ok beck@ 2020-05-09T20:38:19+00:00 tb 2020-05-09T20:38:19+00:00 urn:sha1:33729ac96dd7f69c129d65cf90c030d7022373c9 with TLSv1.2 servers, since it makes clients send their dummy CCS too early... There's an obvious but dirty bandaid which I can't bring myself to applying - this business is already disgusting enough. Issue found the hard way by sthen 2020-05-09T16:43:05+00:00 tb 2020-05-09T16:43:05+00:00 urn:sha1:a69862d24afd7ba98c527672f2e886cdb17723dc If the client has requested middle box compatibility mode by sending a non-empty legacy_session_id, the server must send a dummy CCS right after its first handshake message. This means right after ServerHello or HelloRetryRequest. ok jsing 2020-05-09T15:47:11+00:00 jsing 2020-05-09T15:47:11+00:00 urn:sha1:84ddbcb8c28d02b2e49dfa7ece879c8d7c496eae When operating in middlebox compatibility mode, the TLSv1.3 client needs to send a dummy ChangeCipherSpec message immediately before its second flight of handshake messages (when early data is not offered). ok tb@ 2020-05-09T08:39:44+00:00 jsing 2020-05-09T08:39:44+00:00 urn:sha1:8dd6c173e5508218fa9d285e2eed53d2c6342d03 This fixes the case where a send function signals that an alert should be sent, then returns failure. Previously the failure would be propagated up, without the alert being sent. Issued noted by tb@ ok tb@ 2020-05-02T00:31:54+00:00 inoguchi 2020-05-02T00:31:54+00:00 urn:sha1:2e6d47dd230cf0a1dc61aea57faf78019cf22858 ok tb@