This is a manual backport, not a direct cherry-pick, because the target test header differs. The regression case is placed in the 4.1 suite without unrelated development tests.
Signed-off-by: Ben Taylor <ben.taylor@linaro.org>
(cherry picked from commit 95e95268a4c26608612f34f2bb76ff1dfa9ded0a)
Cover the serialized out_cid length with the same construction as the
in_cid one, and rename the existing case to IN_CID accordingly. Give
the client and server sentinel CIDs different lengths so the two
fields can be told apart in the serialized data. Skip the CID cases
under configurations of MBEDTLS_SSL_CID_IN_LEN_MAX and
MBEDTLS_SSL_CID_OUT_LEN_MAX that the test does not support.
Signed-off-by: Naveed <naveed@bugqore.com>
Fold ssl_context_load_rejects_oob_cid_length and
ssl_context_load_rejects_oob_alpn_length into a single parameterized
test function, since they shared most of their code.
Signed-off-by: Naveed <naveed@bugqore.com>
The serialized ALPN length was passed to memcmp() against each configured protocol without checking it against the remaining serialized data, so a malformed context could read past the end of the buffer. Bound it before the comparison, like the adjacent CID fields.
Signed-off-by: Naveed <naveed@bugqore.com>
- Mbed TLS only implements TLS 1.2 and DTLS 1.2 (not 1.0/1.1) and there
RSA signatures are limited to PKCS#1 v1.5, so replace
PSA_HAVE_ALG_SOME_RSA_SIGN with PSA_HAVE_ALG_RSA_PKCS1V15_SIGN.
- move_handshake_to_state() sets options.pk_alg = MBEDTLS_PK_RSA, so some
minimal support for RSA keys is always needed: at least an RSA public
key. Stricter requirements only apply depending on the protocol version
(TLS 1.2 vs 1.3) and on the handshake state reached by the test (ex:
initial phase vs ending phase), so they are set per test case.
- Test cases already requiring MBEDTLS_X509_RSASSA_PSS_SUPPORT don't need
PSA_WANT_ALG_RSA_PSS too, since the former depends on the latter.
- Add a comment to the handshake_psk_cipher test cases to explain why a
test which is ideally about PSK has requirements on RSA and EC keys.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
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>
Reject malformed TLS 1.3 serialized sessions instead of accepting
unterminated strings or extra trailing data, and reject serialized SSL
contexts whose DTLS Connection ID length exceeds the maximum supported
size instead of overflowing the internal buffer.
Backport of #10715 (development).
Signed-off-by: Nadav0077 <18245584+Nadav0077@users.noreply.github.com>
The unit test framework always loads the client key as well, which
requires a different curve and a hash than the server key.
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>
Write a testcase to get verify_result before we have performed a
handshake and make sure that it is initialised to a failure value.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
This is already indirectly checked in 'test_mbedtls_tls_id_group_name_table'
because it's the last item of the list.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Even though the TLS RFCs do not mandate libraries to expose *Error
Alerts* (as defined in RFC8446 6.2 for TLS 1.3 and in RFC5246 7.2.2 for
TLS 1.2) to the user, there are use cases when it is handy to get the
actual last received fatal error instead of a generic one. For instance
this enables the user to differ between received fatal errors in case
`mbedtls_ssl_handshake()`, `mbedtls_ssl_handshake_step()` or
`mbedtls_ssl_read()` returned `MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE`.
This changesets stores the last incoming fatal alert in
`mbedtls_ssl_context` and provides `mbedtls_ssl_get_alert()` as a getter
for retrieving it. Another option would be to provide a callback
mechanisms for all kinds of alerts (not only fatals) but for simplicity
I discarded this option.
Signed-off-by: Nico Geyso <ng@gsmk.de>
