summaryrefslogtreecommitdiffstats
path: root/lib/libssl/tls13_record_layer.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Split TLSv1.3 record protection from record layer.jsing2021-03-211-46/+72
| | | | | | | | This makes the TLSv1.2 and TLSv1.3 record layers more consistent and while it is not currently necessary from a functionality perspective, it makes for more readable and simpler code. ok inoguchi@ tb@
* Convert tls13_record_layer.c to tls13_secret_{init,cleanup}()tb2021-01-051-21/+11
| | | | ok jsing
* Keep the various free calls of tls13_record_layer_free() in thetb2021-01-041-4/+4
| | | | | | order of the struct members for reviewability. ok jsing
* Free {alert,phh}_data in tls13_record_layer_free()tb2021-01-021-1/+4
| | | | | | | | | | | | | | httpd(8)'s incorrect tls_close() after closing the underlying socket led to a leak: tls_close()'s attempt to send out the close_notify won't work very well over a closed pipe. This resulted in alert_data still hanging off the TLSv1.3 context's record layer struct. The tls_free() call should have cleaned this up but failed to do so. The record layer's phh_data potentially has the same issue, so free it as well. This diff makes -current httpd(8) run in constant memory over hundreds of thousands TLS connections with a static site. ok inoguchi jsing
* zap annoying stray spacestb2020-10-151-4/+4
|
* Rename tls13_record_layer_alert() to tls13_record_layer_enqueue_alert()jsing2020-10-031-3/+4
| | | | | | | This avoids naming confusion with an upcoming TLSv1.2 record layer change and is more descriptive of this function. Requested by tb@
* Some SSL_AD_* defines snuck into the TLSv1.3 code - replace them withjsing2020-09-111-7/+7
| | | | | | TLS13_ALERT_* defines. ok beck@ tb@
* Send an unexpected message alert if no valid content type is found.jsing2020-08-111-2/+5
| | | | | | | | | When record protection is engaged, the plaintext must be followed by a non-zero content type and optional zero padding. If the plaintext is zero length or only consists of zero bytes then it is not a valid message, since the content type is unspecified. ok tb@
* Avoid passing -1 to freezero.tb2020-08-101-9/+10
| | | | | | | | If a peer sends a bogus record consisting of all-zero plaintext, the content_len would be decremented to -1 and cause a crash in freezero. ok inoguchi jsing
* Cleanup aead_ctxinoguchi2020-08-041-1/+3
| | | | ok jsing@ tb@
* Split the handling of post handshake handshake messages into itstb2020-06-011-55/+44
| | | | | | | | own recv function. This simplifies tls13_recod_layer_read_internal() greatly and makes the phh handling easier to reason about since the code is no longer glued to the right hand edge of the terminal. ok jsing
* Add a mechanism to set an alert in those parts of the read half oftb2020-06-011-3/+21
| | | | | | | | | | the record layer that don't do I/O themselves. Use this mechanism to send a record overflow alert for messages that have overlong plaintext or inner plaintext. Fixes most of the remaining record-layer-limits failures of tlsfuzzer. ok jsing
* Handle the case where we receive a valid 0 byte application data record.jsing2020-05-291-1/+10
| | | | | | | | In this situation we cannot return zero bytes, as that signals EOF. Rather we need to return TLS13_IO_WANT_POLLIN so tell the caller to call us again, at which point we'll pull up the next record. ok tb@
* Add additional length checks for TLSv1.3 plaintext and inner plaintext.jsing2020-05-261-1/+6
| | | | Reminded by and ok beck@
* Provide the option to retry or return after post-handshake messages.jsing2020-05-231-3/+14
| | | | | | | | | | | In TLSv1.3 post-handshake handshake messages are used for key updates and session tickets. These are in-band and mean that when the upper layer goes to read application data, we can end up reading and having to process handshake messages - this option changes whether we retry and read the next TLS record, or if we return, signalling that we want more data to be available. ok beck@ inoguchi@ tb@
* Revert 1.43 - this fix for PHH in blocking mode breaks SSL_accept andbeck2020-05-201-2/+2
| | | | | | | | | | | SSL_connect in blocking mode. While this will probably need a rethink, until we land on a solution for PHH in blocking mode, the breakage this causes is visible in real things, and we've only managed to hit the PHH breakage in a test case. ok tb@
* Return TLS13_IO_WANT_POLLIN after processing post-handshake messages.jsing2020-05-161-2/+2
| | | | | | | | | | | | | After post-handshake handshake messages have been processed, we need to return TLS13_IO_WANT_POLLIN rather than TLS13_IO_WANT_RETRY. The latter will cause us to try to read another TLS record, when there may not be any data available - this will then block in the case of a blocking read. This reverts part of r1.25. Issue noticed by inoguchi@ ok beck@ tb@
* Remove a no longer relevant XXX comment.jsing2020-05-131-3/+1
|
* Propagate record overflows to the record layer and alert.jsing2020-05-111-2/+4
| | | | ok beck@ tb@
* Add record version checks.jsing2020-05-111-5/+12
| | | | | | | | When legacy version is below TLSv1.2 ensure that the record version is SSL3/TLS, however when the legacy version is set to TLSv1.2 require this specifically. ok beck@ tb@
* Provide an alert sent record layer callback.jsing2020-05-111-1/+3
| | | | | | | | Use this to push an error on to the SSL error stack so that we report the details of the alert that we sent, rather than failing with an unknown error. ok tb@
* Move the record layer callbacks into a struct.jsing2020-05-111-26/+12
| | | | | | | | This makes the code more readable, requires less code churn when adding a new callback and is likely to avoid bugs due to function argument ordering. ok beck@ inoguchi@ tb@
* Provide alert defines for TLSv1.3 and use in the TLSv1.3 code.jsing2020-05-101-25/+26
| | | | | | | | 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@
* Send dummy ChangeCipherSpec messages from the TLSv1.3 client.jsing2020-05-091-3/+30
| | | | | | | | 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@
* Correct return value check to handle TLS13_IO_EOF case.jsing2020-05-091-2/+2
|
* On receiving a handshake or alert record with empty inner plaintext,tb2020-05-071-1/+11
| | | | | | | | | terminate the connection with an unexpected_message alert. See RFC 8446 section 5.4. Found with tlsfuzzer hint/ok jsing
* Accept two ChangeCipherSpec messages during a TLSv1.3 handshake.jsing2020-05-031-3/+3
| | | | | | | | | | | | | | | | | | | | | In compatibility mode, a TLSv1.3 server MUST send a dummy CCS message immediately after its first handshake message. This is normally after the ServerHello message, but it can be after the HelloRetryRequest message. As such we accept one CCS message from the server during the handshake. However, it turns out that in the HelloRetryRequest case, Facebook's fizz TLSv1.3 stack sends CCS messages after both the HelloRetryRequest message and the ServerHello message. This is unexpected and as far as I'm aware, no other TLSv1.3 implementation does this. Unfortunately the RFC is rather ambiguous here, which probably means it is not strictly an RFC violation. Relax the CCS message handling to allow two dummy CCS messages during a TLSv1.3. This makes our TLSv1.3 client work with Facebook Fizz when HRR is triggered. Issue discovered by inoguchi@ and investigated by tb@. ok deraadt@ tb@
* Add const to TLS1.3 internal vectorsinoguchi2020-05-021-2/+2
| | | | ok tb@
* tls13_record_layer internal functions to static in libsslinoguchi2020-04-291-4/+4
| | | | | | | We might remove static again for further regress around record layer in the future. ok jsing@ tb@
* The RFC is clear (section 5.3) that sequence number should never wrap.tb2020-03-161-5/+12
| | | | | | | | | We currently throw an error on overflow, but still wrap. Check up front if we would need to wrap and only increment if that case is excluded. This simplifies the increment loop and makes the returns in this function less magic. ok jsing
* Correct TLSv1.3 sequence number increment and wrapping check.jsing2020-03-131-3/+3
| | | | Fix proposed by tb@
* drop unused include <openssl/curve25519.h>tb2020-02-181-3/+1
| | | | ok inoguchi jsing
* Fix basement bug where record layer would not correctly deal withbeck2020-01-261-1/+4
| | | | | | traffic retries when not yet encrypting. ok jsing@
* It is possible to receive a pre-TLSv1.3 alert in response to a TLSv1.3jsing2020-01-251-2/+15
| | | | | | | | | | | | client hello. Allow pre-TLSv1.3 alerts (including warnings) to be received before the server hello message. Disallow pre-TLSv1.3 alerts as soon as we know that we are using TLSv1.3. Noticed by ajacoutot@ while connecting to www.openprinting.org. ok tb@
* Fix breakage in SSL_connect, SSL_accept, etc. by not propagatingbeck2020-01-241-10/+34
| | | | | | | | | new retry conditions from the record layer all the way up to the callers. Instead we catch them at the top of the record layer and retry the operations, unless we actually got a retry indicated from actual IO operations. ok jsing@ tb@
* Implement pending for TLSv1.3.jsing2020-01-231-1/+19
| | | | | | Makes `openssl s_client -peekaboo` work with TLSv1.3. ok beck@ tb@
* Add a TLS13_IO_ALERT return value so that we can explicitly signal whenjsing2020-01-231-4/+7
| | | | | | | | | | we sent or received a fatal alert. Pull the fatal_alert check up into tls13_legacy_error(). Also, if sending an alert resulted in EOF, do not propagate this back since we do not want to signal EOF to the caller (rather we want to indicate failure). ok beck@ tb@
* Implement support for SSL_peek() in the TLSv1.3 record layer.jsing2020-01-221-5/+31
| | | | ok beck@ tb@
* After the ClientHello has been sent or received and before the peer'stb2020-01-221-5/+11
| | | | | | | | Finished message has been received, a change cipher spec may be received and must be ignored. Add a flag to the record layer struct and set it at the appropriate moments during the handshake so that we will ignore it. ok jsing
* The legacy_record_version must be set to TLS1_2_VERSION excepttb2020-01-221-6/+12
| | | | | | | | | in the ClientHello where it may be set to TLS1_VERSION. Use the minimal supported version to decide whether we choose to do so or not. Use a sent hook to set it back TLS1_2_VERSION right after the ClientHello message is on the wire. ok beck jsing
* Implement close-notify and SSL_shutdown() handling for the TLSv1.3 client.jsing2020-01-221-7/+19
| | | | ok beck@ inoguchi@ tb@
* Correct legacy fallback for TLSv1.3 client.jsing2020-01-211-1/+7
| | | | | | | | | When falling back to the legacy TLS client, in the case where a server has sent a TLS record that contains more than one handshake message, we also need to stash the unprocessed record data for later processing. Otherwise we end up with missing handshake data. ok beck@ tb@
* Add alerts to the tls 1.3 record layer and handshake layerbeck2020-01-201-44/+26
| | | | ok jsing@, inoguchi@, tb@
* Add support for TLS 1.3 post handshake messages and key updating.beck2019-11-261-12/+56
| | | | | | tested against openssl 1.1's server. ok jsing@ tb@
* Provide a clean interface for sending TLSv1.3 alerts.jsing2019-11-181-2/+14
| | | | ok beck@
* Change tls13_record_layer_phh() to take a CBS as this avoids ownershipjsing2019-11-171-5/+4
| | | | | | issues and makes call sites cleaner. ok beck@
* Add a reference for the non-standard post-handshake handshake (PHH).tb2019-11-171-2/+2
| | | | ok beck, jsing
* Ensure that we are never operating in plaintext mode once the handshakejsing2019-11-171-1/+7
| | | | | | is complete, which should never occur. ok beck@
* Provide framework for sending alerts and post-handshake handshake messages.jsing2019-11-171-14/+169
| | | | | | Discussed at length with beck@ ok beck@ tb@
* Separate the callbacks for recieved and completed post handshake messagesbeck2019-11-171-5/+15
| | | | | | from the record layer ok jsing@
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.