summaryrefslogtreecommitdiff
path: root/src/lib/libssl/tls13_record_layer.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Add and use tls13_record_layer_alert_sent()tb2024-09-091-2/+9
| | | | | | | | | This is a small refactoring that wraps a direct call to the record layer's alert_sent() callback into a handler for upcoming reuse in the QUIC code. No functional change. ok jsing
* Add message callbacks for alerts in the TLSv1.3 stack.jsing2024-01-271-3/+3
| | | | | | | | This will make it easier to regress test shutdown behaviour in the TLSv1.3 stack. Additionally, `openssl -msg` now shows alerts for TLSv1.3 connections. ok tb@
* Convert the legacy TLS stack to tls_content.jsing2022-11-111-1/+2
| | | | | | | | | | This converts the legacy TLS stack to tls_content - records are now opened into a tls_content structure, rather than being written back into the same buffer that the sealed record was read into. This will allow for further clean up of the legacy record layer. ok tb@
* Ensure there is no trailing data for a CCS received by the TLSv1.3 stack.jsing2022-09-111-1/+3
| | | | ok tb@
* Provide record layer callbacks for QUIC.jsing2022-07-241-3/+28
| | | | | | | | | | | | QUIC uses TLS to complete the handshake, however unlike normal TLS it does not use the TLS record layer, rather it provides its own transport. This means that we need to intercept all communication between the TLS handshake and the record layer. This allows TLS handshake message writes to be directed to QUIC, likewise for TLS handshake message reads. Alerts also need to be sent via QUIC, plus it needs to be provided with the traffic keys that are derived by TLS. ok tb@
* Provide QUIC encryption levels.jsing2022-07-241-3/+3
| | | | | | | | | | | | QUIC wants to know what "encryption level" handshake messages should be sent at. Provide an ssl_encryption_level_t enum (via BoringSSL) that defines these (of course quictls decided to make this an OSSL_ENCRYPTION_LEVEL typedef, so provide that as well). Wire these through to tls13_record_layer_set_{read,write}_traffic_key() so that they can be used in upcoming commits. ok tb@
* Remove tls_buffer_set_data() and remove/revise callers.jsing2022-07-201-2/+2
| | | | | | | | | | | | | There is no way that tls_buffer_set_data() can currently work in conjunction with tls_buffer_expand(). This fact is currently hidden by the way that PHH works, which reads the same data from the record layer (which it needs to do anyway, since we may not have all of the handshake message in a single record). Since this is broken, mop it up and change the PHH callback to not provide the record data. ok beck@ tb@
* Convert the new record layers to opaque EVP_AEAD_CTXtb2022-01-141-6/+3
| | | | ok jsing
* Allocate and free the EVP_AEAD_CTX struct in tls13_record_protection.jsing2022-01-061-7/+13
| | | | | | | This brings the code more in line with the tls12_record_layer and reduces the effort needed to make EVP_AEAD_CTX opaque. Prompted by and ok tb@
* Use CBS_get_last_u8() to find the content type in TLSv1.3 records.jsing2021-12-151-11/+12
| | | | ok tb@
* Implement flushing for TLSv1.3 handshakes.jsing2021-09-161-1/+7
| | | | | | | | | | | | | | | When we finish sending a flight of records, flush the record layer output. This effectively means calling BIO_flush() on the wbio. Some things (such as apache2) have custom BIOs that perform buffering and do not actually send on BIO_write(). Without BIO_flush() the server thinks it has sent data and starts receiving records, however the client never sends records since it never received those that the server should have sent. Joint work with tb@ ok tb@
* Factor out the TLSv1.3 code that handles content from TLS records.jsing2021-09-041-74/+34
| | | | | | | | | | | | Currently, the plaintext content from opened TLS records is handled via the rbuf code in the TLSv1.3 record layer. Factor this out and provide a separate struct tls_content, which knows how to track and manipulate the content. This makes the TLSv1.3 code cleaner, however it will also soon also be used to untangle parts of the legacy record layer. ok beck@ tb@
* Ignore the record version for early alertstb2021-06-081-4/+10
| | | | | | | | | | | | | On receiving the first flight from the peer, we do not yet know if we are using TLSv1.3. In particular, we might get an alert record with record version 0x0300 from a pre-TLSv1.2 peer in response to our client hello. Ignore the record version instead of sending a protocol version alert in that situtation. This may also be hit when talking to a LibreSSL 3.3 server with an illegal SNI. Part of an issue reported by danj. ok jsing
* Avoid pulling ssl_locl.h into self-contained code.jsing2021-05-161-2/+1
|
* Make local header inclusion consistent.jsing2021-05-161-2/+1
| | | | | Consistently include local headers in the same location, using the same grouping/sorting across all files.
* 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@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-20 01:42:28 +0000