Open gilles-peskine-arm opened 2 years ago
I'm still not very clear with the implementation on this task. My initial plan is to design one function with different test data as following (name will be improved):
void handshake_exchange_data_with_cipher( int dtls, int expected_negotiated_version, char* cipher, int ciphersuite)
{
mbedtls_test_handshake_test_options options;
mbedtls_test_init_handshake_options( &options );
options.dtls = dtls;
options.expected_negotiated_version = expected_negotiated_version;
options.cipher = cipher;
options.expected_ciphersuite = ciphersuite;
mbedtls_test_ssl_perform_handshake( &options );
/* The goto below is used to avoid an "unused label" warning.*/
goto exit;
exit:
mbedtls_test_free_handshake_options( &options );
}
This function should take the following arguments: protocol (DTLS or TLS), version (1.2 or 1.3, also older versions in 2.28), ciphersuite, (Maybe also whether to do client authentication?)
However, I'm still confused with the coverage in version and ciphersuite.
development
branch, we support TLS1.2, TLS1.3, DTLS plus TLS1.0 and TLS1.1 in 2.28
branch. I think this covers all the versions described in the issue requirements. If it's' not correct, please fix. include/mbedtls/ssl_ciphersuites.h
. I don't think all of the ciphersuites will be considered. But I have no idea which one I should consider to test at least. Any suggestions?
- Regarding ciphersuite, there are too many types of available ciphersuite defined in
include/mbedtls/ssl_ciphersuites.h
. I don't think all of the ciphersuites will be considered. But I have no idea which one I should consider to test at least. Any suggestions?
Looking at the ciphersuites which are used by compat.sh -p mbedTLS
, those should be the ciphersuites covered by unit test test_suite_ssl_connection
.
@gilles-peskine-arm How does this differ from tests using a local buffer in test_suite_ssl
? Maybe we should just take what's written there and move it to a new test suite?
Edit: oh, OK, I can now see in the PR that that's exactly what's happening - It's great that we're improving this area!
A note as of Mbed TLS 3.6: we've made great progress, test_suite_ssl
is actually testing things now. It's still far from being as complete as I would expect, however. For example, in https://github.com/Mbed-TLS/mbedtls/commit/5fae4a333c32bfe51189bdf675e69875e61be8e0 (from gilles-peskine-arm:tls13-psa-init-auto-3.6-1, an earlier iteration of https://github.com/Mbed-TLS/mbedtls/pull/9501), only ssl-opt.sh
is failing, not unit tests, despite a bug with wide impact in TLS 1.3 servers (ClientHello processing fails all crypto calls).
Create a unit test function that runs both a TLS client and a TLS server, performs a handshake, and exchanges some data (one
write
and oneread
from each side).This function should take the following arguments: protocol (DTLS or TLS), version (1.2 or 1.3, also older versions in 2.28), ciphersuite, (Maybe also whether to do client authentication?)
Put this in a new unit test suite
test_suite_ssl_connection
(the name can be improved), becausetest_suite_ssl
is already too big.Prerequisite: https://github.com/Mbed-TLS/mbedtls/issues/6173
This is intended as a step towards (mostly) replacing
compat.sh -p mbedTLS
(see https://github.com/Mbed-TLS/mbedtls/issues/5346). Follow-ups: