The previous commit bd5ceee484f201b90a384636ba12de86bd330cba removed
the definition of the global constants
- mbedtls_test_ca_crt_rsa_len,
- mbedtls_test_cli_crt_rsa_len,
- mbedtls_test_ca_crt_rsa, and
- mbedtls_test_cli_crt_rsa.
This commit restores these to maintain ABI compatibility.
Further, it was noticed that without SHA256_C being enabled the
previous code failed to compile because because the SHA1 resp. SHA256
certificates were only defined when the respective SHAXXX_C options
were set, but the emission of the global variable mbedtls_test_ca_crt
was unconditionally defined through the SHA256
certificate. Previously, the RSA SHA1 certificate was unconditionally
defined and used for that.
As a remedy, this commit makes sure some RSA certificate is defined
and exported through the following rule:
1. If SHA256_C is active, define an RSA SHA256 certificate and export
it as mbedtls_test_ca_crt. Also, define SHA1 certificates only if
SHA1_C is set.
2. If SHA256_C is not set, always define SHA1 certificate and export
it as mbedtls_test_ca_crt.
The previous commit b3e6872c9381ed4ce020d631dda1e0126c42b64f changed
to public functions from ssl_ciphersuite.h to static inline. This
commit reverts this change.
Fix a resource leak on windows platform, in mbedtls_x509_crt_parse_path,
in case a failure. when an error occurs, goto cleanup, and free the
resource, instead of returning error code immediately.
Protecting the ECP hardware acceleratior with mutexes is inconsistent with the
philosophy of the library. Pre-existing hardware accelerator interfaces
leave concurrency support to the underlying platform.
Fixes#863
If we didn't walk the whole chain, then there may be any kind of errors in the
part of the chain we didn't check, so setting all flags looks like the safe
thing to do.
This change moves the calls to mbedtls_sha256_starts() and
mbedtls_sha512_starts() out of the mbedtls_entropy_init() function as
these now have return codes which need to be checked.
This patch modifies the entropy.c module to ensure that the sha256 and
sha512 contexts are correctly initialised and freed instead of skipping
these calls or simply zeroizing with memset() or mbedtls_zeroize().
This is important as the sha contexts might otherwise leak memory or
other resources, and even more so in the context of hardware
accelerators where the configuration of the device might be done in the
init and free calls.
This patch modifies the internal md context structure in md_wrap.c to
add return values to the function pointers. This enables us to use the
new API in the corresponding MD modules so that failures can be
found at any point in an MD computation.
The following function calls are being deprecated to introduce int
return values.
* mbedtls_sha512()
* mbedtls_sha512_starts()
* mbedtls_sha512_update()
* mbedtls_sha512_finish()
* mbedtls_sha512_process()
The return codes can be used to return error values. This is important
when using hardware accelerators.
The following function calls are being deprecated to introduce int
return values.
* mbedtls_sha256()
* mbedtls_sha256_starts()
* mbedtls_sha256_update()
* mbedtls_sha256_finish()
* mbedtls_sha256_process()
The return codes can be used to return error values. This is important
when using hardware accelerators.
The following function calls are being deprecated to introduce int
return values.
* mbedtls_ripemd160()
* mbedtls_ripemd160_starts()
* mbedtls_ripemd160_update()
* mbedtls_ripemd160_finish()
* mbedtls_ripemd160_process()
The return codes can be used to return error values. This is important
when using hardware accelerators.
The following function calls are being deprecated to introduce int
return values.
* mbedtls_md5()
* mbedtls_md5_starts()
* mbedtls_md5_update()
* mbedtls_md5_finish()
* mbedtls_md5_process()
The return codes can be used to return error values. This is important
when using hardware accelerators.
The following function calls are being deprecated to introduce int
return values.
* mbedtls_md4()
* mbedtls_md4_starts()
* mbedtls_md4_update()
* mbedtls_md4_finish()
* mbedtls_md4_process()
The return codes can be used to return error values. This is important
when using hardware accelerators.
The following function calls are being deprecated to introduce int
return values.
* mbedtls_md2()
* mbedtls_md2_starts()
* mbedtls_md2_update()
* mbedtls_md2_finish()
* mbedtls_md2_process()
The return codes can be used to return error values. This is important
when using hardware accelerators.
The following function calls are being deprecated to introduce int
return values.
* mbedtls_sha1()
* mbedtls_sha1_starts()
* mbedtls_sha1_update()
* mbedtls_sha1_finish()
* mbedtls_sha1_process()
The return codes can be used to return error values. This is important
when using hardware accelerators.
This patch modifies the function mbedtls_gcm_self_test() function to
ensure that AES-GCM-192 tests are only run if the key size is supported
by the available implementation. This is useful when using
MBEDTLS_AES_ALT as some hardware crypto accelerators might not support
AES-192.
This patch modifies the function mbedtls_aes_selftest() function to
ensure that AES-192 tests are only run if the key size is supported by
the available implementation. This is useful when using MBEDTLS_AES_ALT
as some hardware crypto accelerators might not support AES-192.
* restricted/iotssl-1398:
Add ChangeLog entry
Ensure application data records are not kept when fully processed
Add hard assertion to mbedtls_ssl_read_record_layer
Fix mbedtls_ssl_read
Simplify retaining of messages for future processing
This commit fixes the following case: If a client is both expecting a
SERVER_HELLO and has an application data record that's partially
processed in flight (that's the situation the client gets into after
receiving a ServerHelloRequest followed by ApplicationData), a
subsequent call to mbedtls_ssl_read will set keep_current_message = 1
when seeing the unexpected application data, but not reset it to 0
after the application data has been processed. This commit fixes this.
It also documents and suggests how the problem might be solved in a
more structural way on the long run.
This commit adds a hard assertion to mbedtls_ssl_read_record_layer
triggering if both ssl->in_hslen and ssl->in_offt are not 0. This
should never happen, and if it does, there's no sensible way of
telling whether the previous message was a handshake or an application
data message.
