There is now one test case to validate that SHA-1 is rejected in
certificates by default, and one test case to validate that SHA-1 is
supported if MBEDTLS_TLS_DEFAULT_ALLOW_SHA1 is #defined.
In the TLS test client, allow SHA-1 as a signature hash algorithm.
Without this, the renegotation tests failed.
A previous commit had allowed SHA-1 via the certificate profile but
that only applied before the initial negotiation which includes the
signature_algorithms extension.
SHA-1 is now disabled by default in the X.509 layer. Explicitly enable
it in our tests for now. Updating all the test data to SHA-256 should
be done over time.
With SHA-1 deprecation, we need a few certificates using algorithms in
the default support list. Most tests still use SHA-1 though.
The generation process for the new certificates is recorded in the makefile.
Default to forbidding the use of SHA-1 in TLS where it is unsafe: for
certificate signing, and as the signature hash algorithm for the TLS
1.2 handshake signature. SHA-1 remains allowed in HMAC-SHA-1 in the
XXX_SHA ciphersuites and in the PRF for TLS <= 1.1.
For easy backward compatibility for use in controlled environments,
turn on the MBEDTLS_TLS_DEFAULT_ALLOW_SHA1 compiled-time option.
* hanno/sig_hash_compatibility:
Improve documentation
Split long lines
Remember suitable hash function for any signature algorithm.
Introduce macros and functions to characterize certain ciphersuites.
The ECJPAKE test suite uses a size zero array for the empty password
used in the tests, which is not valid C. This commit fixes this.
This originally showed up as a compilation failure on Visual Studio
2015, documented in IOTSSL-1242, but can also be observed with GCC
when using the -Wpedantic compilation option.
This patch modifies the following 2 functions in the AES module to
change the return type from void to int:
* mbedtls_aes_encrypt() -> mbedtls_internal_aes_encrypt()
* mbedtls_aes_decrypt() -> mbedtls_internal_aes_decrypt()
This change is necessary to allow users of MBEDTLS_AES_ALT,
MBEDTLS_AES_DECRYPT_ALT and MBEDTLS_AES_ENCRYPT_ALT to return an error
code when replacing the default with their own implementation, e.g.
a hardware crypto accelerator.
The RSA private key functions rsa_rsaes_pkcs1_v15_decrypt and
rsa_rsaes_oaep_decrypt put sensitive data (decryption results) on the
stack. Wipe it before returning.
Thanks to Laurent Simon for reporting this issue.
The sliding window exponentiation algorithm is vulnerable to
side-channel attacks. As a countermeasure we add exponent blinding in
order to prevent combining the results of different measurements.
This commit handles the case when the Chinese Remainder Theorem is used
to accelerate the computation.
The sliding window exponentiation algorithm is vulnerable to
side-channel attacks. As a countermeasure we add exponent blinding in
order to prevent combining the results of fifferent measurements.
This commits handles the case when the Chinese Remainder Theorem is NOT
used to accelerate computations.
Adding the CA suppression list option to the 'ssl_server2' sample
program is a prerequisite for adding tests for this feature to the
integration test suite (ssl-opt.sh).
According to RFC5246 the server can indicate the known Certificate
Authorities or can constrain the aurhorisation space by sending a
certificate list. This part of the message is optional and if omitted,
the client may send any certificate in the response.
The previous behaviour of mbed TLS was to always send the name of all the
CAs that are configured as root CAs. In certain cases this might cause
usability and privacy issues for example:
- If the list of the CA names is longer than the peers input buffer then
the handshake will fail
- If the configured CAs belong to third parties, this message gives away
information on the relations to these third parties
Therefore we introduce an option to suppress the CA list in the
Certificate Request message.
Providing this feature as a runtime option comes with a little cost in
code size and advantages in maintenance and flexibility.
This commit changes `ssl_parse_signature_algorithms_ext` to remember
one suitable ( := supported by client and by our config ) hash
algorithm per signature algorithm.
It also modifies the ciphersuite checking function
`ssl_ciphersuite_match` to refuse a suite if there
is no suitable hash algorithm.
Finally, it adds the corresponding entry to the ChangeLog.
The routine `mbedtls_ssl_write_server_key_exchange` heavily depends on
what kind of cipher suite is active: some don't need a
ServerKeyExchange at all, some need (EC)DH parameters but no server
signature, some require both. Each time we want to restrict a certain
piece of code to some class of ciphersuites, it is guarded by a
lengthy concatentation of configuration checks determining whether at
least one of the relevant cipher suites is enabled in the config; on
the code level, it is guarded by the check whether one of these
cipher suites is the active one.
To ease readability of the code, this commit introduces several helper
macros and helper functions that can be used to determine whether a
certain class of ciphersuites (a) is active in the config, and
(b) contains the currently present ciphersuite.
Modify tests/scripts/check-doxy-blocks.pl to ensure that:
* It can only be run from the mbed TLS root directory.
* An error code is returned to the environment when a potential error
in the source code is found.
With this commit the Elliptic Curve Point interface is rewised. Two
compile time options has been removed to simplify the interface and
the function names got a new prefix that indicates that these functions
are for internal use and not part of the public interface.
The intended use of the abstraction layer for Elliptic Curve Point
arithmetic is to enable using hardware cryptographic accelerators.
These devices are a shared resource and the driver code rarely provides
thread safety.
This commit adds mutexes to the abstraction layer to protect the device
in a multi-threaded environment.
The primary use case behind providing an abstraction layer to enable
alternative Elliptic Curve Point arithmetic implementation, is making
use of cryptographic acceleration hardware if it is present.
To provide thread safety for the hardware accelerator we need a mutex
to guard it.
