ARMmbed/mbedtls
1
0
Fork 0
mirror of https://github.com/ARMmbed/mbedtls.git synced 2025-05-17 20:31:45 +08:00
Code Issues Releases Wiki Activity

Document the limitations of TLS handshake message defragmentation

Browse Source 
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This commit is contained in:
Gilles Peskine 2025-03-05 17:41:59 +01:00
parent 6811978045
commit 36edd48c61
1 changed files with 18 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
include/mbedtls/ssl.h
View File

@ -4360,6 +4360,24 @@ void mbedtls_ssl_conf_cert_req_ca_list(mbedtls_ssl_config *conf,
* with \c mbedtls_ssl_read()), not handshake messages. * with \c mbedtls_ssl_read()), not handshake messages.
* With DTLS, this affects both ApplicationData and handshake. * With DTLS, this affects both ApplicationData and handshake.
* *
* \note Defragmentation of incoming handshake messages in TLS
* (excluding DTLS) is supported with some limitations:
* - On an Mbed TLS server that only accepts TLS 1.2,
* the initial ClientHello message must not be fragmented.
* A TLS 1.2 ClientHello may be fragmented if the server
* also accepts TLS 1.3 connections (meaning
* that #MBEDTLS_SSL_PROTO_TLS1_3 enabled, and the
* accepted versions have not been restricted with
* mbedtls_ssl_conf_max_tls_version() or the like).
* - A ClientHello message that initiates a renegotiation
* must not be fragmented.
* - The first fragment of a handshake message must be
* at least 4 bytes long.
* - Non-handshake records must not be interleaved between
* the fragments of a handshake message. (This is permitted
* in TLS 1.2 but not in TLS 1.3, but Mbed TLS rejects it
* even in TLS 1.2.)
*
* \note This sets the maximum length for a record's payload, * \note This sets the maximum length for a record's payload,
* excluding record overhead that will be added to it, see * excluding record overhead that will be added to it, see
* \c mbedtls_ssl_get_record_expansion(). * \c mbedtls_ssl_get_record_expansion().