The tests load certificate chains from files. The CA chains contain a
past or future certificate and an invalid certificate. The test then
checks that the flags set are BADCERT_EXPIRED or BADCERT_FUTURE.
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 BADCERT_EXPIRED and 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.
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.
This PR fixes a number of unused variable/function compilation warnings
that arise when using a config.h that does not define the macro
POLARSSL_PEM_PARSE_C.
Various fixes to the all.sh script.
* support for two different versions of OpenSSL and GNUTLS, to allow testing of
legacy features, deprecated but not yet removed in the library.
* additional test builds for server only and client only builds
* removed error redirection on armcc to allow build errors to be output
* added tools checking, to ensure the absence of a tool will cause a failure, rather
than silently failing to execute a test
* added test for out of tree cmake builds
In a USENIX WOOT '16 paper the authors warn about a security risk
of random Initialisation Vectors (IV) repeating values.
The MBEDTLS_SSL_AEAD_RANDOM_IV feature is affected by this risk and
it isn't compliant with RFC5116. Furthermore, strictly speaking it
is a different cipher suite from the TLS (RFC5246) point of view.
Removing the MBEDTLS_SSL_AEAD_RANDOM_IV feature to resolve the above
problems.
Hanno Böck, Aaron Zauner, Sean Devlin, Juraj Somorovsky and Philipp
Jovanovic, "Nonce-Disrespecting Adversaries: Practical Forgery Attacks
on GCM in TLS", USENIX WOOT '16
The sample applications programs/pkey/cert_req.c and
programs/pkey/cert_write.c use the library functions mbedtls_pk_write_csr_pem()
and mbedtls_pk_write_crt_pem() respectively and programs/pkey/gen_key.c uses
the library function mbedtls_pk_write_key_pem().
These are dependent on the configuration option POLARSSL_PEM_WRITE_C. If the
option isn't defined the build breaks.
This change adds the compilation condition POLARSSL_PEM_WRITE_C to these
sample applications.
* Fix crypt_and_hash to support decrypting GCM encrypted files
* Fix documentation in crypt_and_hash for the generic case
* Remove unused lastn from crypt_and_hash
lastn is not used with the cipher layer as it already provides padding
and understanding of length of the original data.
Backport of fix by Paul Bakker.
Fix an issue that caused valid certificates being rejected whenever an
expired or not yet valid version of the trusted certificate was before the
valid version in the trusted certificate list.
Fix an issue that caused valid certificates being rejected whenever an
expired or not yet valid version of the trusted certificate was before the
valid version in the trusted certificate list.
In a USENIX WOOT '16 paper the authors warn about a security risk
of random Initialisation Vectors (IV) repeating values.
The MBEDTLS_SSL_AEAD_RANDOM_IV feature is affected by this risk and
it isn't compliant with RFC5116. Furthermore, strictly speaking it
is a different cipher suite from the TLS (RFC5246) point of view.
Removing the MBEDTLS_SSL_AEAD_RANDOM_IV feature to resolve the above
problems.
Hanno Böck, Aaron Zauner, Sean Devlin, Juraj Somorovsky and Philipp
Jovanovic, "Nonce-Disrespecting Adversaries: Practical Forgery Attacks
on GCM in TLS", USENIX WOOT '16
In a USENIX WOOT '16 paper the authors exploit implementation
mistakes that cause Initialisation Vectors (IV) to repeat. This
did not happen in mbed TLS, and this test makes sure that this
won't happen in the future either.
A new test option is introduced to ssl-opt.sh that checks the server
and client logs for a pattern and fails in case there are any
duplicates in the lines following the matching ones. (This is
necessary because of the structure of the logging)
Added a test case as well to utilise the new option. This test forces
the TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 ciphersuite to make the
client and the server use an AEAD cipher.
Hanno Böck, Aaron Zauner, Sean Devlin, Juraj Somorovsky and Philipp
Jovanovic, "Nonce-Disrespecting Adversaries: Practical Forgery Attacks
on GCM in TLS", USENIX WOOT '16
The PKCS#1 standard says nothing about the relation between P and Q
but many libraries guarantee P>Q and mbed TLS did so too in earlier
versions.
This commit restores this behaviour.
Fix implementation and documentation missmatch for the function
arguments to mbedtls_gcm_finish(). Also, removed redundant if condition
that always evaluates to true.
The sample applications programs/pkey/cert_req.c and
programs/pkey/cert_write.c use the library functions mbedtls_pk_write_csr_pem()
and mbedtls_pk_write_crt_pem() respectively and programs/pkey/gen_key.c uses
the library function mbedtls_pk_write_key_pem().
These are dependent on the configuration option POLARSSL_PEM_WRITE_C. If the
option isn't defined the build breaks.
This change adds the compilation condition POLARSSL_PEM_WRITE_C to these
sample applications.
