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.
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.
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.
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.
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.
The compile time macros enabling the initialisation and deinitialisation
in the alternative Elliptic Curve Point arithmetic implementation had
names that did not end with '_ALT' as required by check-names.sh.
This patch introduces some additional checks in the PK module for 64-bit
systems only. The problem is that the API functions in the PK
abstraction accept a size_t value for the hashlen, while the RSA module
accepts an unsigned int for the hashlen. Instead of silently casting
size_t to unsigned int, this change checks whether the hashlen overflows
an unsigned int and returns an error.
Fix a buffer overflow when writting a string representation of an MPI
number to a buffer in hexadecimal. The problem occurs because hex
digits are written in pairs and this is not accounted for in the
calculation of the required buffer size when the number of digits is
odd.
When using ssl_cookie with MBEDTLS_THREADING_C, fix a resource leak caused by
initiating a mutex in mbedtls_ssl_cookie_free instead of freeing it.
Raised and fix suggested by lan Gillingham in the mbed TLS forum
Tracked in #771
The function ecp_mod_koblitz computed the space for the result of a
multiplication optimally for that specific case, but unfortunately
the function mbedtls_mpi_mul_mpi performs a generic, suboptimal
calculation and needs one more limb for the result. Since the result's
buffer is on the stack, the best case scenario is that the program
stops.
This only happened on 64 bit platforms.
Fixes#569
A heap overread might happen when parsing malformed certificates.
Reported by Peng Li and Yueh-Hsun Lin.
Refactoring the parsing fixes the problem. This commit applies the
relevant part of the OpenVPN contribution applied to mbed TLS 1.3
in commit 17da9dd82931abdf054a01c466bce45e7d12b742.
Fixes a regression introduced by an earlier commit that modified
x509_crt_verify_top() to ensure that valid certificates that are after past or
future valid in the chain are processed. However the change introduced a change
in behaviour that caused the verification flags MBEDTLS_X509_BADCERT_EXPIRED and
MBEDTLS_BADCERT_FUTURE to always be set whenever there is a failure in the
verification regardless of the cause.
The fix maintains both behaviours:
* Ensure that valid certificates after future and past are verified
* Ensure that the correct verification flags are set.
Modifies the function mbedtls_x509_crl_parse() to ensure that a CRL in PEM
format with trailing characters after the footer does not result in the
execution of an infinite loop.
Fix potential integer overflows in the function mbedtls_base64_decode().
This overflow would mainly be exploitable in 32-bit systems and could
cause buffer bound checks to be bypassed.
Fix potential integer overflows in the following functions:
* mbedtls_md2_update() to be bypassed and cause
* mbedtls_cipher_update()
* mbedtls_ctr_drbg_reseed()
This overflows would mainly be exploitable in 32-bit systems and could
cause buffer bound checks to be bypassed.
Fix an incorrect condition in ssl_check_ctr_renegotiate() that compared
64 bits of record counter instead of 48 bits as described in RFC 6347
Section 4.3.1. This would cause the function's return value to be
occasionally incorrect and the renegotiation routines to be triggered
at unexpected times.
This PR fixes a number of unused variable/function compilation warnings
that arise when using a config.h that does not define the macro
MBEDTLS_PEM_PARSE_C.
Fixes many typos, and errors in comments.
* Clarifies many comments
* Grammar correction in config.pl help text
* Removed comment about MBEDTLS_X509_EXT_NS_CERT_TYPE.
* Comment typo fix (Dont => Don't)
* Comment typo fix (assure => ensure)
* Comment typo fix (byes => bytes)
* Added citation for quoted standard
* Comment typo fix (one complement => 1's complement)
The is some debate about whether to prefer "one's complement", "ones'
complement", or "1's complement". The more recent RFCs related to TLS
(RFC 6347, RFC 4347, etc) use " 1's complement", so I followed that
convention.
* Added missing ")" in comment
* Comment alignment
* Incorrect comment after #endif
This change fixes a regression introduced by an earlier commit that
modified x509_crt_verify_top() to ensure that valid certificates
that are after past or future valid in the chain are processed. However
the change introduced a change in behaviour that caused the
verification flags MBEDTLS_X509_BADCERT_EXPIRED and
MBEDTLS_BADCERT_FUTURE to always be set whenever there is a failure in
the verification regardless of the cause.
The fix maintains both behaviours:
* Ensure that valid certificates after future and past are verified
* Ensure that the correct verification flags are set.
To do so, a temporary pointer to the first future or past valid
certificate is maintained while traversing the chain. If a truly valid
certificate is found then that one is used, otherwise if no valid
certificate is found and the end of the chain is reached, the program
reverts back to using the future or past valid certificate.
This patch modifies the function mbedtls_x509_crl_parse() to ensure
that a CRL in PEM format with trailing characters after the footer does
not result in the execution of an infinite loop.
