Split `mbedtls_test_ssl_endpoint_init()` into two separate stages:
constructing the SSL configuration, and setting up an SSL session context
with that configuration.
No behavior change.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This will allow splitting the configuration and setup stages of
`mbedtls_test_ssl_endpoint_init()`, while still checking that the value is
carried over from the configuration to the session context.
No behavior change.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In `mbedtls_test_ssl_endpoint_init()`, don't change the SSL configuration
object (`mbedtls_ssl_config`) after setting up an SSL context by calling
`mbedtls_ssl_setup()`. This works in practice, but is officially forbidden.
No intended behavior change. The test code calls the library slightly
differently, but this shouldn't make any difference in practice. If it does
make a difference, it fixes a bug in the test code.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
There was a discrepancy between how `mbedtls_test_ssl_endpoint_init()` and
`mbedtls_test_ssl_perform_handshake()` handled client authentication:
`mbedtls_test_ssl_endpoint_init()` defaulted to
`MBEDTLS_SSL_VERIFY_REQUIRED` on both sides, whereas
`mbedtls_test_ssl_perform_handshake()` obeyed `options->srv_auth_mode` which
defaulted to no verification of the client certificate.
Make this more uniform. Now `mbedtls_test_ssl_endpoint_init()` obeys
`options->srv_auth_mode` on servers (still forcing verification on clients,
which is the library default anyway). Also, `options->srv_auth_mode` is now
enabled by default. Thus:
* Tests that call `mbedtls_test_ssl_perform_handshake()` now perform client
certificate verification, unless they disable it explicitly.
* Tests that call `mbedtls_test_ssl_endpoint_init()` on a server are
unchanged. (They would change if they were setting
`options->srv_auth_mode` explicitly, which previously was ignored, but
no test function did this.)
This means that a few test functions now perform client certificate
verification whereas they previously don't. This is harmless except in
`handshake_ciphersuite_select`, where one test case
`Handshake, select ECDH-RSA-WITH-AES-256-CBC-SHA384, opaque` fails with
client authentication because the test code doesn't deal with the weirdness
of static ECDH correctly with respect to client authentication. So keep
the previous behavior in `handshake_ciphersuite_select`, by explicitly
turning off client authentication.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Applying SSL configuration settings recorded in the
`mbedtls_test_handshake_test_options` structure to an
`mbedtls_test_ssl_endpoint` object was split between
`mbedtls_test_ssl_endpoint_init()` and `mbedtls_test_ssl_perform_handshake()`.
This was surprising, and made it harder to use
`mbedtls_test_ssl_endpoint_init()` for custom behavior. It also meant some
code duplication in `mbedtls_test_ssl_perform_handshake()`.
Move most configuration setup from `mbedtls_test_ssl_perform_handshake()` to
`mbedtls_test_ssl_endpoint_init()`. This changes the behavior in two ways:
* `mbedtls_test_ssl_endpoint_init()` now takes some options into account
that it previously ignored. This is ok because we don't set these options
in any of the existing tests.
* When calling `mbedtls_test_ssl_perform_handshake()`, some SSL configuration
settings are now set (calls to `mbedtls_ssl_conf_xxx()`) before the call
to `mbedtls_ssl_setup()` instead of after. This should be ok since it is
forbidden to change the configuration after `mbedtls_ssl_setup()`,
although the previous test code was getting away with it. This commit does
not move all configuration before `mbedtls_ssl_setup()`, that would be out
of scope of the current series of patches.
Thus there are some internal behavior changes, but they should not affect
any relevant aspect of the tests' behavior.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Split mbedtls_test_ssl_perform_connection() out of
mbedtls_test_ssl_perform_handshake().
No behavior change.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Stop calling mbedtls_test_set_step() in
mbedtls_test_ssl_perform_handshake(). This leaves the caller free to use the
test step as they wish.
No behavior change.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This will facilitate future refactoring that breaks out code into auxiliary
functions.
No behavior change.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The DTLS context and the queues now conveyed inside the endpoint object.
Remove the unused parameters.
No behavior change.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This allows mbedtls_test_ssl_endpoint_init() to no longer interact with the
other endpoint.
No behavior change.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Create an auxiliary function to perform some endpoint setup that involves
both the client and the server. This is only needed for DTLS.
The code that will eventually be in this function is currently mostly in
mbedtls_test_ssl_endpoint_init(). This commit adds the new function to the
control flow; a subsequent commit will move the relevant code.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This is a step towards making mbedtls_test_ssl_endpoint_init() and
mbedtls_test_ssl_endpoint_free() more self-contained.
No behavior change.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Link the ciphersuite list that's passed to mbedtls_ssl_conf_ciphersuites(),
and needs to survive in memory as long as the configuration object is live,
in the endpoint structure. This way it doesn't have to be a local variable
in mbedtls_test_ssl_do_handshake_with_endpoints().
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Import component_test_platform_get_entropy_alt() from its counterpart
in TF-PSA-Crypto repo.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Use the proper Clang C++ compiler to build C++ code otherwise the C
compiler will fail because std::cout() is unknown in
"cpp_dummy_build.cpp".
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Use alternative implementation of mbedtls_platform_get_entropy() since
the default one lives in "platform.c" and that one is excluded in
this test component.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
By default C++ code would be compiled with GNU while C with Clang and
this can create problems at link time. In order to prevent this we
use Clang for both.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
This is necessary to let entropy being able to gather entropy data from
the native platform source.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
We were not making enough room. We want to move everything from the
place where we are going to insert the new record.
This was not causing failures because the code does not look at the
content after the inserted record, because it correctly returns an error
when seeing the inserted record. But as a matter on principle, the test
code should be doing what it says: just insert a new record but leave
a valid fragment after it.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This one is overly tight: TLS 1.3 actually only depends on
ChachaPoly || (AES && (GCM || CCM))
Furthermore, this should really be reflected in check_config.h.
Individual test cases should be able to just request PROTO_TLS1_3 and
know that there is ciphersuite that works.
However, resolving that seems out of scope for this PR. (It would also
involve updating depends.py for example.)
So, use a dependency that's stricted than necessary. IMO it's still good
enough as most configs we test will have ChachaPoly. However it would be
good to revisit this when a cleaner solution is implemented.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The function depends on MBEDTLS_SSL_HANDSHAKE_WITH_CERT_ENABLED which is
basically
MBEDTLS_SSL_TLS1_3_KEY_EXCHANGE_MODE_EPHEMERAL_ENABLED ||
MBEDTLS_KEY_EXCHANGE_WITH_CERT_ENABLED
The individual test cases depend on the specific TLS version.
This is not precise enough. In a build with both TLS versions enabled,
we could have cert-based key exchange in one version but not in the
other. So, we need the 1.3 tests to depend on the 1.3 cert-based key
exchange and similarly for 1.2.
For 1.2, cert-based key exchange means ECDHE-{RSA,ECDSA} or
ECDH-{RSA,ECDSA}. Since the test function sets an ECC cert for the
server, we want one of the ECDSA ones. So, the minimal dependency would
be ECDH_ECDSA || ECDHE_ECDSA. Since dependencies with || are
inconvenient to express, and anyway ECDH_ECDSA (static ECDH) is
something we'd like to remove in 4.0 if we can find the time, I chose to
just depend on ECDHE_ECDSA.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
These are not optimal. For example, the tests should in principle be
able to run in builds without ECDSA, by using RSA certs instead. Ideally
PSK should work too.
However, getting optimal dependencies would be a lot of work that's
largely orthogonal to the purpose of this PR, so we'll settle for good
enough.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
