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 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
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-1.3:
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 SSL_VERIFY_REQUIRED and
SSL_VERIFY_OPTIONAL be in the following relationship:
Mode == SSL_VERIFY_REQUIRED
<=> Mode == 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.
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 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 different measurements.
This commits handles the case when the Chinese Remainder Theorem is NOT
used to accelerate computations.
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.
The first three test cases from test_suites_pkparse.data failed because
the key file they read requires DES to be read. However, POLARSSL_DES_C
was missing from the dependency list.
Adds interim directories to the Visual Studio project files to avoid warning
MSB8028 in Visual Studio 2015, where shared directories of intermediate files
between project files generate the warning.
The first three test cases from test_suites_pkparse.data failed because
the key file they read requires DES to be read. However, POLARSSL_DES_C
was missing from the dependency list.
Adds interim directories to the Visual Studio project files to avoid warning
MSB8028 in Visual Studio 2015, where shared directories of intermediate files
between project files generate the warning.
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
This curve has special arithmetic on 64 bit platforms and an untested
path lead to trying to free a buffer on the stack.
For the sake of completeness, a test case for a point with non-affine
coordinates has been added as well.
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.
