For each received ClientHello fragment, check
that its epoch is zero and update the
record-level sequence number.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
The check was wrongly removed by the commit
"ssl_tls12_server.c: Move ClientHello message_seq adjustment".
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
In ssl_tls12_server.c:ssl_parse_client_hello(), remove
the code that directly reads the received data to read
the record expected to contain the ClientHello message.
The function already supported handling a ClientHello
read via mbedtls_ssl_read_record() in the following
cases:
- when the ClientHello was read as a post-handshake
message (renegotiation).
- when the ClientHello was read by
ssl_tls13_process_client_hello() during TLS 1.3 or
TLS 1.2 version negotiation.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
A handshake record may contain multiple handshake messages, or multiple
fragments (there can be the final fragment of a pending message, then zero
or more whole messages, and an initial fragment of an incomplete message).
This was previously untested, but supported, so don't break it.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Reassemble handshake fragments incrementally instead of all at the end. That
is, every time we receive a non-initial handshake fragment, append it to the
initial fragment. Since we only have to deal with at most two handshake
fragments at the same time, this simplifies the code (no re-parsing of a
record) and is a little more memory-efficient (no need to store one record
header per record).
This commit also fixes a bug. The previous code did not calculate offsets
correctly when records use an explicit IV, which is the case in TLS 1.2 with
CBC (encrypt-then-MAC or not), GCM and CCM encryption (i.e. all but null and
ChachaPoly). This led to the wrong data when an encrypted handshake message
was fragmented (Finished or renegotiation). The new code handles this
correctly.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Minor refactoring of the initial checks and preparation when receiving the
first fragment. Use `ssl->in_hsfraglen` to determine whether there is a
pending handshake fragment, for consistency, and possibly for more
robustness in case handshake fragments are mixed with non-handshake
records (although this is not currently supported anyway).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In preparation for reworking mbedtls_ssl_prepare_handshake_record(),
tweak the "handshake fragment:" log message.
This changes what information is displayed when a record contains data
beyond the expected end of the handshake message. This case is currently
untested and its handling will change in a subsequent commit.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In preparation for reworking mbedtls_ssl_prepare_handshake_record(), tweak
the "waiting for more handshake fragments" log message in
ssl_consume_current_message(), and add a similar one in
mbedtls_ssl_prepare_handshake_record(). Assert both.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In the `mbedtls_ssl_context` structure, merge the field `in_hsfraglen` into
`badmac_seen_or_in_hsfraglen`. This restores the ABI of `libmbedtls` as it
was in Mbed TLS 3.6.0 through 3.6.2.
The field `badmac_seen_or_in_hsfraglen` (formerly `badmac_seen`) was only
used for DTLS (despite being present in non-DTLS builds), and the field
`in_hsfraglen` was only used in non-DTLS TLS. Therefore the two values can
be stored in the same field.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In the `mbedtls_ssl_context` structure, change the type of `in_hsfraglen`
from `size_t` to `unsigned`. This is in preparation for merging
`in_hsfraglen` into `badmac_seen_or_in_hsfraglen`, which has the type
`unsigned` and cannot change since we do not want to change the ABI.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Prepare to unify two fields of the `mbedtls_ssl_context` structure:
`badmac_seen` (always present but only used in DTLS) and
`in_hsfraglen` (always present but only used in non-DTLS TLS).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The first fragment of a fragmented handshake message always starts at the beginning of the buffer so there's no need to store it.
Signed-off-by: Deomid rojer Ryabkov <rojer@rojer.me>
The compile-time option MBEDTLS_SSL_TLS1_3_COMPATIBILITY_MODE gates both
support for interoperability with a peer that uses middlebox compatibility
mode, and support for activating that mode ourselves. Change code that is
only needed for interoperability to be guarded by
MBEDTLS_SSL_TLS1_3_ACCEPT_COMPATIBILITY_MODE.
As of this commit, MBEDTLS_SSL_TLS1_3_ACCEPT_COMPATIBILITY_MODE is always
enabled: there is no way to disable it, and there are no tests with it
disabled.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
