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.
Inspired by test code provided by Nicholas Wilson in PR #351.
The test will fail if someone sets MAX_INTERMEDIATE_CA to a value larger than
18 (default is 8), which is hopefully unlikely and can easily be fixed by
running long.sh again with a larger value if it ever happens.
Current behaviour is suboptimal as flags are not set, but currently the goal
is only to document/test existing behaviour.
Modify the function mbedtls_x509_csr_parse_der() so that it checks the
parsed CSR version integer before it increments the value. This prevents
a potential signed integer overflow, as these have undefined behaviour
in the C standard.
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.
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
* 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.
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.
