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 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.
Due to inconsistent freeing strategy in pkparse.c the sample mutex
implementation in threading.c could lead to undefined behaviour by
destroying the same mutex several times.
This fix prevents mutexes from being destroyed several times in the
sample threading implementation.
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.
The server code parses the client hello extensions even when the
protocol is SSLv3 and this behaviour is non compliant with rfc6101.
Also the server sends extensions in the server hello and omitting
them may prevent interoperability problems.
armar doesn't understand the syntax without dash. OTOH, the syntax with dash
is the only one specified by POSIX, and it's accepted by GNU ar, BSD ar (as
bundled with OS X) and armar, so it looks like the most portable syntax.
fixes#386
See for example page 8 of
http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf
The previous constant probably came from a typo as it was 2^26 - 2^5 instead
of 2^36 - 2^5. Clearly the intention was to allow for a constant bigger than
2^32 as the ull suffix and cast to uint64_t show.
fixes#362
