Fix an incorrect condition in ssl_check_ctr_renegotiate() that compared
64 bits of record counter instead of 48 bits as described in RFC 6347
Section 4.3.1. This would cause the function's return value to be
occasionally incorrect and the renegotiation routines to be triggered
at unexpected times.
This PR fixes a number of unused variable/function compilation warnings
that arise when using a config.h that does not define the macro
MBEDTLS_PEM_PARSE_C.
This PR fixes a number of unused variable/function compilation warnings
that arise when using a config.h that does not define the macro
MBEDTLS_PEM_PARSE_C.
Changes use of mklink in Windows test builds, to create junctions instead of
directory symbolic links. This removes the need for an elevated command prompt
when running cmake to create the Visual Studio project files.
Fixes many typos, and errors in comments.
* Clarifies many comments
* Grammar correction in config.pl help text
* Removed comment about MBEDTLS_X509_EXT_NS_CERT_TYPE.
* Comment typo fix (Dont => Don't)
* Comment typo fix (assure => ensure)
* Comment typo fix (byes => bytes)
* Added citation for quoted standard
* Comment typo fix (one complement => 1's complement)
The is some debate about whether to prefer "one's complement", "ones'
complement", or "1's complement". The more recent RFCs related to TLS
(RFC 6347, RFC 4347, etc) use " 1's complement", so I followed that
convention.
* Added missing ")" in comment
* Comment alignment
* Incorrect comment after #endif
For a start, they don't even compile with Visual Studio due to strcasecmp
being missing. Secondly, on Windows Perl scripts aren't executable and have
to be run using the Perl interpreter directly; thankfully CMake is able to
find cygwin Perl straight away without problems.
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.
