It allows weak hash algorithms to be used in PKCS7. It's only added in the
LTS branch for backward compatibility, but it's disabled by default because
that's the safest choice.
This commit also updates test data in order to test the new build symbol.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
Newly added tests for RIPEMD160 and MD5 still require SHA-256 for the
certificate being used. SHA-1 is instead useless in this case.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
Some newly added tests had duplicate numbers with what was already there.
This commit fixes the duplication problem.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
Add a check on mbedtls_pkcs7_data_or_hash_verify() so that the verification
fails if the MD alg specified in PKCS7 structure or the signature
algorithm specified in the X.509 certificate are not in the list of
secure algorithms (i.e. mbedtls_x509_crt_profile_default).
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
Following functions
- x509_profile_check_md_alg
- x509_profile_check_pk_alg
are made non-static and moved to x509_internal.h so that other library
files can used them.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
ssl_preset_default_hashes was removed in
f0cda410a4bca0f45f66bdbf0714cd0eb2ea4718 but the comment in 'x509_crt.c'
wasn't updated.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
Co-authored-by: Ronald Cron <ronald.cron@arm.com>
Signed-off-by: Ben Taylor <32939606+bjwtaylor@users.noreply.github.com>
(cherry picked from commit 377aa4eff16cd0aa5e7440a41de59847e3a789a0)
Signed-off-by: Ben Taylor <ben.taylor@linaro.org>
(cherry picked from commit 10afc1ed5c8e9c47caf1ad8ee6241fd99e43f945)
Backport note: resolved the redundant-test removal conflict by deleting the temporary reset test while keeping the 3.6 pkcs7_verify dependency expression.
Co-authored-by: Gilles Peskine <gilles.peskine@arm.com>
Signed-off-by: Ben Taylor <32939606+bjwtaylor@users.noreply.github.com>
(cherry picked from commit a798b5804ef8571bcfd6609019758014325162c4)
Signed-off-by: Ben Taylor <ben.taylor@linaro.org>
(cherry picked from commit 84966c1bda07dd01e38786b2caa9b7453a5adb95)
Backport note: resolved PKCS7 test conflicts by retaining the 3.6 dependency names (MBEDTLS_MD_CAN_SHA256:MBEDTLS_RSA_C) for the added regression cases.
Signed-off-by: Ben Taylor <ben.taylor@linaro.org>
(cherry picked from commit 67e696b430716f95ed714f2c1404681697251438)
Backport note: resolved the PKCS7 test-suite conflict by keeping the 3.6 pkcs7_verify dependency expression while adding the reuse regression test.
Let the caller handle returning on error. This is less surprising, and it's
more flexible in case the caller needs to perform some cleanup (which is
currently not the case).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
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>
