Add mbedtls_ssl_conf_enable_new_session_tickets() API
to be able to enable and disable the handling of TLS 1.3
NewSessionTicket messages.
The TLS 1.2 equivalent function is named
mbedtls_ssl_conf_session_tickets() thus the most
natural name would have been
mbedtls_ssl_conf_new_session_tickets() but it is
already used on server side thus rather
mbedtls_ssl_conf_enable_new_session_tickets().
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
This reduces the workflows where psa_crypto_init is called when not
necessary: it won't be called when a dual-version server receives a 1.2-only
ClientHello.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
For backward compatibility with Mbed TLS <=3.5.x, applications must be able
to make a TLS connection with a peer that supports both TLS 1.2 and TLS 1.3,
regardless of whether they call psa_crypto_init(). Since Mbed TLS 3.6.0,
we enable TLS 1.3 in the default configuration, so we must take care of
calling psa_crypto_init() if needed. This is a change from TLS 1.3 in
previous versions, where enabling MBEDTLS_SSL_PROTO_TLS1_3 was a user
choice and could have additional requirement.
This commit makes the library call psa_crypto_init() when it needs PSA
crypto in a situation where the application might not have called it,
namely, when starting a TLS 1.3 connection.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
For backward compatibility with Mbed TLS <=3.5.x, applications must be able
to make a TLS connection with a peer that supports both TLS 1.2 and TLS 1.3,
regardless of whether they call psa_crypto_init(). Since Mbed TLS 3.6.0,
we enable TLS 1.3 in the default configuration, so we must take care of
calling psa_crypto_init() if needed. This is a change from TLS 1.3 in
previous versions, where enabling MBEDTLS_SSL_PROTO_TLS1_3 was a user
choice and could have additional requirement.
This commit changes our test programs to validate that the library
does not have the compatibility-breaking requirement.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
For backward compatibility with Mbed TLS <=3.5.x, applications must be able
to make a TLS connection with a peer that supports both TLS 1.2 and TLS 1.3,
regardless of whether they call psa_crypto_init(). Since Mbed TLS 3.6.0,
we enable TLS 1.3 in the default configuration, so we must take care of
calling psa_crypto_init() if needed. This is a change from TLS 1.3 in
previous versions, where enabling MBEDTLS_SSL_PROTO_TLS1_3 was a user
choice and could have additional requirement.
This commit changes our unit tests to validate that the library
does not have the compatibility-breaking requirement.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
For backward compatibility with Mbed TLS <=3.5.x, applications must be able
to make a TLS connection with a peer that supports both TLS 1.2 and TLS 1.3,
regardless of whether they call psa_crypto_init(). Since Mbed TLS 3.6.0,
we enable TLS 1.3 in the default configuration, so we must take care of
calling psa_crypto_init() if needed. This is a change from TLS 1.3 in
previous versions, where enabling MBEDTLS_SSL_PROTO_TLS1_3 was a user
choice and could have additional requirement.
This commit removes the compatibility-breaking requirement from the
documentation.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
We are technically allowed to use all possible values of key slice index
that will fit into the bit width we have allocated, so allow all values.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
The persistent key cache slice is the last slice (not the first as
previously stated). Update the numbering-related comments accordingly.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Actually moved the function rather than trying to edit guards around it,
because the relevant guards are not nearby, the function was part of
larger blocks, so it seemed risky.
Also, that seems logically correct: the function is no longer part of
the "TLS 1.2 handshake functions common to server and client" section,
it's part of the "helper functions common to 1.2 and 1.3 server and
client" block. Ideally in the future perhaps the file structure should
reflect that (`ssl_generic.c` vs `ssl_tls12_generic.c`?) but that's out
of scope here.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Rename as there was a name collision with a static function in another
file: ssl_parse_certificate_verify in ssl_tls12_server.c is the function
that parses the CertificateVerify message, which seems appropriate. Here
it meant "the 'verify' step after parsing the Certificate message".
Use a name that focuses on what it does: verify, not parse.
Also, take ciphersuite_info as an argument: when TLS 1.3 calls this
function, it can pass NULL as the ciphersuite has no influence there.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
