Document the preconditions on the input and output buffers for
the PKCS1 decryption functions
- mbedtls_rsa_pkcs1_decrypt,
- mbedtls_rsa_rsaes_pkcs1_v15_decrypt
- mbedtls_rsa_rsaes_oaep_decrypt
The check `if( *p + n > end )` in `ssl_parse_client_psk_identity` is
unsafe because `*p + n` might overflow, thus bypassing the check. As
`n` is a user-specified value up to 65K, this is relevant if the
library happens to be located in the last 65K of virtual memory.
This commit replaces the check by a safe version.
The previous version of `mbedtls_ssl_safer_memcmp` did not qualify the
pointers to the arrays to be compared as volatile, theoretically
opening the possibility for the compiler to notice that the loop
operation `diff |= A[i] ^ B[i]` is pointless if `diff = -1`. This
commit changes this. It also declares the stack variable `diff` as
volatile, to force read and write in every loop; omitting that, the
compiler would still be allowed to get away with reading `A[i]` and
`B[i]` but not doing the XOR and not updating `diff`.
* restricted/iotssl-1398_backport-2.1:
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.
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.
There are situations in which it is not clear what message to expect
next. For example, the message following the ServerHello might be
either a Certificate, a ServerKeyExchange or a CertificateRequest. We
deal with this situation in the following way: Initially, the message
processing function for one of the allowed message types is called,
which fetches and decodes a new message. If that message is not the
expected one, the function returns successfully (instead of throwing
an error as usual for unexpected messages), and the handshake
continues to the processing function for the next possible message. To
not have this function fetch a new message, a flag in the SSL context
structure is used to indicate that the last message was retained for
further processing, and if that's set, the following processing
function will not fetch a new record.
This commit simplifies the usage of this message-retaining parameter
by doing the check within the record-fetching routine instead of the
specific message-processing routines. The code gets cleaner this way
and allows retaining messages to be used in other situations as well
without much effort. This will be used in the next commits.
* hanno/iotssl-1341-optional-certificate-verification-needs-ca-chain-backport-2.1:
Add tests for missing CA chains and bad curves.
Fix implementation of VERIFY_OPTIONAL verification mode
In the ecdsa.c sample application we don't use hashing, we use ecdsa
directly on a buffer containing plain text. Although the text explains
that it should be the message hash it still can be confusing.
Any misunderstandings here are potentially very dangerous, because ECDSA
truncates the message hash if necessary and this can lead to trivial
signature forgeries if the API is misused and the message is passed
directly to the function without hashing.
This commit adds a hash computation step to the ecdsa.c sample
application and clarification to the doxygen documentation of the
ECDSA functions involved.
This commit adds four tests to tests/ssl-opt.sh:
(1) & (2): Check behaviour of optional/required verification when the
trusted CA chain is empty.
(3) & (4): Check behaviour of optional/required verification when the
client receives a server certificate with an unsupported curve.
This commit changes the behaviour of mbedtls_ssl_parse_certificate
to make the two authentication modes MBEDTLS_SSL_VERIFY_REQUIRED and
MBEDTLS_SSL_VERIFY_OPTIONAL be in the following relationship:
Mode == MBEDTLS_SSL_VERIFY_REQUIRED
<=> Mode == MBEDTLS_SSL_VERIFY_OPTIONAL + check verify result
Also, it changes the behaviour to perform the certificate chain
verification even if the trusted CA chain is empty. Previously, the
function failed in this case, even when using optional verification,
which was brought up in #864.
* sha1-2.1:
Cleaned up negative test predicate for test case
all.sh: test with SHA-1 enabled
SHA-1 deprecation: allow it in key exchange
Allow SHA-1 in server tests, when the signature_algorithm extension is not used
Document test data makefile
X.509 tests: obey compile-time SHA-1 support option
Allow SHA-1 in test scripts
Test that SHA-1 defaults off
Allow SHA-1 in SSL renegotiation tests
Test that X.509 verification rejects SHA-256 by default
Allow SHA-1 in X.509 and TLS tests
X.509 self-tests: replaced SHA-1 certificates by SHA-256
Added SHA256 test certificates
Remove SHA-1 in TLS by default
By default, keep allowing SHA-1 in key exchange signatures. Disabling
it causes compatibility issues, especially with clients that use
TLS1.2 but don't send the signature_algorithms extension.
SHA-1 is forbidden in certificates by default, since it's vulnerable
to offline collision-based attacks.
