Remove the "srv" variant of "DTLS proxy: server: get invalid AD record then
accept renego", where the server initiates the renegotiation process by
sending a HelloRequest. The HelloRequest message is not relevant to this
test. The first message of the actual renegotiation is the ClientHello
message from the client, and the interesting part of the test happens when
the client receives the server's response.
Remove "DTLS proxy: server: get invalid AD record then accept early
renego (cli)" and the corresponding "reject" control. This test case doesn't
really do what it is advertised to do, and in particular does not lead to a
call to `ssl_consume_current_message()` in the server. What happens is that
the client sends a ClientHello message to start the renegotiation, then it
blocks until the server has replied. So there is nothing to delay that
ClientHello after:(unlike what happens in the corresponding client-side
test, where the first flight of the renegotiation protocol contains multiple
messages, so we can delay the first of these messages after the second one).
What happens in practice is that the client times out, then resends its
ClientHello, and the proxy sends the delayed ClientHello immediately after
the resent one, which does not cause any interesting behavior in the server.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Only set `badmac_limit` on the side that actually receives a message with a
bad MAC/tag (injected by the proxy).
Signed-off-by: Gilles Peskine <Gilles.Peskine@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>
In `ssl_client2`, the existing option `renegotiate=1` causes the client to
initiate renegotiation immediately after the initial handshake. Add a
variant `renegotiate=2` that initiates renegotiation after one data exchange.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
After a message with a bad MAC (invalid application data record), try to
renegotiate:
* Test cases where renegotiation (nominal or delayed) is rejected.
Nothing bad happens.
* A test where renegotiation is misparsed and rejected.
The subsequent parsing fails.
* A test where the renegotiation request is delayed.
This causes a heap buffer overflow in `ssl_buffer_message()`.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This can be used to simulate data messages received in the wrong epoch, or
to cause a handshake message to be buffered.
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>
Let test code customize the kitchen sink function
`mbedtls_test_ssl_perform_handshake()` at a few points.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Since Mbed TLS 4.0, this is just the low-level error code. But keep the
combination for uniformity with the rest of the file, and to reduce the
differences with the 3.6 branch.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Announce the security fix together with the overflow fix, since the two bugs
are pretty much indistinguishable from a black-box perspective, despite
being due to independent problems in the code.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In an X.509 certificate, a basicConstraints extension where the cA
field (BOOLEAN) is omitted but the pathLenConstraint field (INTEGER )is
present is syntactically valid, but RFC 5280 states that CAs MUST NOT emit
such a certificate.
Historically, since XySSL 0.9 in 2008, if a basicConstraints extension
started with an INTEGER field, we interpreted that field as a cA value. This
was a deliberate change:
> Fixed x509_get_ext() to accept some rare certificates (like
> www.openssl.org:443) which have an INTEGER instead of a BOOLEAN for
> Extension::BasicConstraints::cA.
However, 18 years later, this does not seem to be relevant, and the details
seem to have been lost. Furthermore, major implementations follow RFC 5280
and interpret `SEQUENCE { INTEGER n }` with cA being set to its default
value (FALSE) and pathLenConstraint set to `n`. This means that such a
certificate with n != 0 would be interpreted as a CA certificate in Mbed TLS
but as a leaf certificate elsewhere, which is dangerous.
Since CAs are not supposed to emit such certificates, stop accepting them
altogether.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In test cases for pathLenConstraint parsing in a basicConstraints extension
of an X.509 certificate, use the standard type for the leading cA field,
namely BOOLEAN. The test data was encoding that field as INTEGER, which was
accepted as a deviation from the standard since XySSL 0.9.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
