* mbedtls-2.1:
Fix typo in asn1.h
Improve leap year test names in x509parse.data
Correctly handle leap year in x509_date_is_valid()
Renegotiation: Add tests for SigAlg ext parsing
Parse Signature Algorithm ext when renegotiating
Fix changelog for ssl_server2.c usage fix
Fix ssl_server2 sample application prompt
Update ChangeLog for fix to #836
Enhance documentation of ssl_write_hostname_ext, adapt ChangeLog.
Enhance documentation of mbedtls_ssl_set_hostname
Add test case calling ssl_set_hostname twice
Make mbedtls_ssl_set_hostname safe to be called multiple times
Fix typo in configs/README.txt file
Remove a check introduced in the previous buffer overflow fix with keys of
size 8N+1 which the subsequent fix for buffer start calculations made
redundant.
Added a changelog entry for the buffer start calculation fix.
For a key of size 8N+1, check that the first byte after applying the
public key operation is 0 (it could have been 1 instead). The code was
incorrectly doing a no-op check instead, which led to invalid
signatures being accepted. Not a security flaw, since you would need the
private key to craft such an invalid signature, but a bug nonetheless.
The check introduced by the previous security fix was off by one. It
fixed the buffer overflow but was not compliant with the definition of
PSS which technically led to accepting some invalid signatures (but
not signatures made without the private key).
Fix buffer overflow in RSA-PSS signature verification when the hash is
too large for the key size. Found by Seth Terashima, Qualcomm.
Added a non-regression test and a positive test with the smallest
permitted key size for a SHA-512 hash.
Signature algorithm extension was skipped when renegotiation was in
progress, causing the signature algorithm not to be known when
renegotiating, and failing the handshake. Fix removes the renegotiation
step check before parsing the extension.
As noted in #557, several functions use 'index' resp. 'time'
as parameter names in their declaration and/or definition, causing name
conflicts with the functions in the C standard library of the same
name some compilers warn about.
This commit renames the arguments accordingly.
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.
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.
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.
* 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.
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.
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.
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.
* restricted/mbedtls-2.1:
Remove obsolete macros from compat-1.3.h
Add fix for #667 to ChangeLog
Fix bug in threading sample implementation #667
Fix check-doxy-blocks.pl to run from root dir
RSA: wipe more stack buffers
RSA: wipe stack buffers
* hanno/iotssl-1241-backport-2.1:
Improve documentation
Split long lines.
Remember suitable hash function for any signature algorithm.
Introduce macros and functions to characterize certain ciphersuites.
* iotssl-1272-fix-RSA-cache-attack-2.1-restricted:
Add Changelog entry for RSA exponent blinding
Add exponent blinding to RSA with CRT
Add exponent blinding to RSA without CRT
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.
