The intent on these lines was to get 'psa_key_type_t' for which
'mbedtls_pk_get_key_type' should clearly be used, not
'mbedtls_pk_get_type'.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
MBEDTLS_ECP_DP_MAX is defined in 'ecp.h' which is a tf-psa-crypto private
header. Instead of relying on that value define a new function named
'mbedtls_ssl_get_supported_tls_id_count' which returns the number of
entries in 'tls_id_match_table'.
Rationale: it does not have too much sense to allocate an array for TLS
IDs which is larger than the list of supported TLS IDs in the current
build.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Its main functionality was to get a TLS ID from 'mbedtls_ecp_group_id' and
then call 'mbedtls_ssl_check_curve_tls_id'. The same can be achieved
with public PK functions and 'mbedtls_ssl_get_tls_id_from_curve_info',
then calling into 'mbedtls_ssl_check_curve_tls_id' as before.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Instead of retrieving the TLS ID using 'mbedtls_ecp_group_id', which
creates a dependency on the (now tf-psa-crypto private) 'ecp.h' header,
use PSA info to get the same result. Therefore rename the function as
'mbedtls_ssl_get_tls_id_from_curve_info'.
This new function has basically the opposite behavior than
'mbedtls_ssl_get_psa_curve_info_from_tls_id'.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
All the usages of 'mbedtls_ssl_get_ecp_group_id_from_tls_id' basically
reduce to checking if a specific TLS ID is supported or not. Therefore
the function is replaced with 'mbedtls_ssl_is_tls_id_supported'.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Following fields were not properly reset when mbedtls_ssl_session_reset
was called:
- badmac_seen
- dtls_srtp_info
- alert_reason
- alert_type
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
Follow the same pattern that was used in the past to remove dependency
on MBEDTLS_RSA_C and use PSA_WANT instead.
Relying on MBEDTLS_RSA_C is fine only when builtin drivers are compiled
since all PSA_WANT are converted to legacy build symbols. However when
builtin drivers are not built (ex: in case of TF-M), then part of the code
in TLS/X509 won't be compiled because MBEDTLS_RSA_C is not set. OTOH
it's not possible to declare that symbol in a configuration file because
it's a legacy one and it will be rejected by buildtime checks.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
When we are doing PSK, we'd like to set verify_result to
MBEDTLS_X509_BADCERT_SKIP_VERIFY. Previously this was done in
mbedtls_ssl_set_hs_psk() but this is inadequate since this function may
be called for early data (where certificate verification happens later
in the handshake.
Instead, set this value after writing / processing the encrypted
extensions on the server / client respectively, so that we know whether
we are doing certificate verification or not for sure. This change is
effective only for TLS 1.3 as TLS 1.2 sets verify_result for PSK in
ssl_parse_certificate_coordinate().
Signed-off-by: David Horstmann <david.horstmann@arm.com>
In the TLS-Exporter for TLS 1.3 we mistakenly call PSA_HASH_LENGTH() on
an mbedtls_md_type_t when it should be called on a psa_algorithm_t.
Fortunately, these two types have almost the same values, since we have
previously aligned them to make conversion more efficient. As a result,
PSA_HASH_LENGTH() produces exactly the same value when called on an
mbedtls_md_type_t as with the equivalent psa_algorithm_t.
Thanks to this happy coincidence, fix a largely cosmetic issue (rather
than a major functional bug).
Signed-off-by: David Horstmann <david.horstmann@arm.com>
When we are using PSK or when authmode == MBEDTLS_SSL_VERIFY_NONE, we
intentionally do not verify the certificate. In these cases, do not keep
verify_result at -1u but set it to MBEDTLS_X509_BADCERT_SKIP_VERIFY to
indicate that no certificate verification took place.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
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>
At initialization, set the verify_result field of the ssl session to
MBEDTLS_X509_VERIFY_NOT_STARTED, rather than 0 as it is by default
currently. This prevents mbedtls_ssl_get_verify_result() from indicating
that certificate verification has passed if it is called prior to the
handshake happening.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
This is only done when MBEDTLS_DEBUG_C is declared in order not to inflate
the library size.
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>
Being a macro allow the table to be instatiated only when/if necessary
by the consuming code.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
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>
Those in SSL modules were redundant because it's already included from
ssl_misc.h.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
