Initialize the verify_result field in mbedtls_ssl_session_free().
Previously we were just zeroising the entire session object, which would
yield a default 'success' value if the same object were reused.
Test that this initialisation is actually happening by setting
verify_result manually to zero and calling mbedtls_ssl_session_free() on
the session before checking its value.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Since we explicitly document the value 0xFFFFFFFF or -1u as representing
'result not available', we can use it as a sensible default value
without creating an API change. Use this value instead of introducing a
new verification result value.
Signed-off-by: David Horstmann <david.horstmann@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>
Add new field that tells if the corresponding group is supported or not
in the current build.
Test function "test_mbedtls_ssl_get_supported_group_list" is extended
to verify this new feature.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
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>
Check provided group_name also against the value returned from
mbedtls_ssl_get_curve_name_from_tls_id().
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
- let the macro be an initializer for the array of known TLS IDs, not
a variable declarator;
- last item's group name is NULL, not an empty string
- change then name of the macro from MBEDTLS_TLS_ID_GROUP_NAME_TABLE to
MBEDTLS_SSL_IANA_TLS_GROUPS_INFO
- define a new public structure "mbedtls_ssl_iana_tls_group_info_t" to
hold each element of the table and that can be used the go over the
list from user code.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
- adjust function name to mbedtls_ssl_get_fatal_alert
- fix missing property name changes for mbedtls_ssl_context
Signed-off-by: Nico Geyso <ng@gsmk.de>
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>
Previously 3 different groups were allowed, but since the removal of
secp192r1 and secp224r1 only secp256r1 was left. This commit adds
other 2 options.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
In some cases, we were calling `mbedtls_test_ssl_endpoint_free()` on an
uninitialized `mbedtls_test_ssl_endpoint` object if the test case failed
early, e.g. due to `psa_crypto_init()` failing. This was largely harmless,
but could have caused weird test results in case of failure, and was flagged
by Coverity.
Use a more systematic style for initializing the stack object as soon as
it's declared.
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>
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>
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>
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>
Simulate the server closing the connection after a partial handshake
message.
These test cases don't send a close_notify alert. The test cases
"insert alert record" exercise what happens if the server sends an alert.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Create tests that coalesce the handshake messages in the first flight from
the server. This lets us test the behavior of the library when a handshake
record contains multiple handshake messages.
Only non-protected (non-encrypted, non-authenticated) handshake messages are
supported.
The test code works for all protocol versions, but it is only effective in
TLS 1.2. In TLS 1.3, there is only a single non-encrypted handshake record,
so we can't test records containing more than one handshake message without
a lot more work.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
