RFC 8446 (TLS 1.3 specification), Section 5.1, states:
Handshake messages MAY be coalesced into a single TLSPlaintext record
or fragmented across several records, provided that:
...
-Handshake messages MUST NOT span key changes. Implementations
MUST verify that all messages immediately preceding a key change
align with a record boundary; if not, then they MUST terminate the
connection with an "unexpected_message" alert. Because the
ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate
messages can immediately precede a key change, implementations
MUST send these messages in alignment with a record boundary.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Add a test entry point for a handshake with a specially crafted context.
This can be used for defense in depths for scenarios that we think can't
happen, but might actually happen due to a bug, or due to a new feature that
is insufficiently tested. This can also be a proxy for testing aspects of
renegotiation or session resumption in circumstances that are hard to
arrange.
In this commit, use it to test a DTLS handshake with `ssl->badmac_seen`
:(actually `ssl->badmac_seen_or_in_hsfraglen` in the 3.6 branch) set to a
nonzero value. This can't happen, as far as I know (`badmac_seen` can only
be nonzero during renegotiation, not during a nominal handshake or in
session resumption). But it could happen, for example, if
`mbedtls_ssl_session_reset()` failed to reset `badmac_seen`, as was the case
in Mbed TLS 4.0.0 to 4.1.0.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Non-regression test for a bug introduced with TLS handshake defragmentation
support in Mbed TLS 3.6.3, whereby the confusion between the `badmac_seen`
meaning and the `in_hsfraglen` meaning of `ssl->badmac_seen_or_in_hsfraglen`
causes renegotiation to be processed incorrectly after receiving a message
with a bad MAC.
The bug doesn't affect Mbed TLS 4.0.0 and above, but it's still good to have
more testing.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
DEBUG_C supposed to have been removed from the test dependencies, still
being there is an oversight. Removing it was the sole purpose of
3e58109fbd.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Add a test case with a successful handshake for each test case that
causes the desired handshake failure, with minimal differences between
the two.
The reason is to have more assurance that the handshake is failing for
the desired reason (as opposed to not having done something correctly in
the test code).
Signed-off-by: Janos Follath <janos.follath@arm.com>
There are other issues that can fail with the same error code. Make sure
that the handshake fails exactly the way we want it to fail by analysing
the client logs.
Signed-off-by: Janos Follath <janos.follath@arm.com>
