If application uses tls_session_secret_cb for session resumption
set the CCS_OK flag.

Only accept change cipher spec when it is expected instead of at any
time. This prevents premature setting of session keys before the master
secret is determined which an attacker could use as a MITM attack.

Thanks to KIKUCHI Masashi (Lepidum Co. Ltd.) for reporting this issue
and providing the initial fix this patch is based on.
(cherry picked from commit bc8923b1ec9c467755cd86f7848c50ee8812e441)

Check session_cert is not NULL before dereferencing it.
(cherry picked from commit 8011cd56e39a433b1837465259a9bd24a38727fb)

Security callback: selects which parameters are permitted including
sensible defaults based on bits of security.

The "parameters" which can be selected include: ciphersuites,
curves, key sizes, certificate signature algorithms, supported
signature algorithms, DH parameters, SSL/TLS version, session tickets
and compression.

In some cases prohibiting the use of a parameters will mean they are
not advertised to the peer: for example cipher suites and ECC curves.
In other cases it will abort the handshake: e.g DH parameters or the
peer key size.

Documentation to follow...

New function ssl_cipher_disabled.

Check for disabled client ciphers using ssl_cipher_disabled.

New function to return only supported ciphers.

New option to ciphers utility to print only supported ciphers.

(cherry picked from commit b709f8ef54b1c9ad513878ba0213aa651a9acef8)

Whitespace fixes

If multiple TLS extensions are expected but not received, the TLS extension and supplemental data 'generate' callbacks are the only chance for the receive-side to trigger a specific TLS alert during the handshake.

Removed logic which no-op'd TLS extension generate callbacks (as the generate callbacks need to always be called in order to trigger alerts), and updated the serverinfo-specific custom TLS extension callbacks to track which custom TLS extensions were received by the client, where no-ops for 'generate' callbacks are appropriate.

DHE is the standard term used by the RFCs and by other TLS
implementations.  It's useful to have the internal variables use the
standard terminology.

This patch leaves a synonym SSL_kEDH in place, though, so that older
code can still be built against it, since that has been the
traditional API.  SSL_kEDH should probably be deprecated at some
point, though.

ECDHE is the standard term used by the RFCs and by other TLS
implementations.  It's useful to have the internal variables use the
standard terminology.

This patch leaves a synonym SSL_kEECDH in place, though, so that older
code can still be built against it, since that has been the
traditional API.  SSL_kEECDH should probably be deprecated at some
point, though.

Instead, send random bytes, unless SSL_SEND_{CLIENT,SERVER}RANDOM_MODE
is set.

This is a forward-port of commits:
  4af79303
  f4c93b46
  3da721da
  25832701

While the gmt_unix_time record was added in an ostensible attempt to
mitigate the dangers of a bad RNG, its presence leaks the host's view
of the current time in the clear.  This minor leak can help
fingerprint TLS instances across networks and protocols... and what's
worse, it's doubtful thet the gmt_unix_time record does any good at
all for its intended purpose, since:

    * It's quite possible to open two TLS connections in one second.

    * If the PRNG output is prone to repeat itself, ephemeral
      handshakes (and who knows what else besides) are broken.

Make DTLS behave like TLS when negotiating version: record layer has
DTLS 1.0, message version is 1.2.

Tolerate different version numbers if version hasn't been negotiated
yet.

Add callbacks supporting generation and retrieval of supplemental data entries, facilitating RFC 5878 (TLS auth extensions)
Removed prior audit proof logic - audit proof support was implemented using the generic TLS extension API
Tests exercising the new supplemental data registration and callback api can be found in ssltest.c.
Implemented changes to s_server and s_client to exercise supplemental data callbacks via the -auth argument, as well as additional flags to exercise supplemental data being sent only during renegotiation.

Check for Suite B support using method flags instead of version numbers:
anything supporting TLS 1.2 cipher suites will also support Suite B.

Return an error if an attempt to use DTLS 1.0 is made in Suite B mode.

Add new methods DTLS_*_method() which support both DTLS 1.0 and DTLS 1.2 and
pick the highest version the peer supports during negotiation.

As with SSL/TLS options can change this behaviour specifically
SSL_OP_NO_DTLSv1 and SSL_OP_NO_DTLSv1_2.

The relaxed signing requirements for fixed DH certificates apply to DTLS 1.2
too.

Add correct flags for DTLS 1.2, update s_server and s_client to handle
DTLS 1.2 methods.

Currently no support for version negotiation: i.e. if client/server selects
DTLS 1.2 it is that or nothing.

Use the enc_flags field to determine whether we should use explicit IV,
signature algorithms or SHA256 default PRF instead of hard coding which
versions support each requirement.

Revise DTLS code. There was a *lot* of code duplication in the
DTLS code that generates records. This makes it harder to maintain and
sometimes a TLS update is omitted by accident from the DTLS code.

Specifically almost all of the record generation functions have code like
this:

some_pointer = buffer + HANDSHAKE_HEADER_LENGTH;
... Record creation stuff ...
set_handshake_header(ssl, SSL_MT_SOMETHING, message_len);

...

write_handshake_message(ssl);

Where the "Record creation stuff" is identical between SSL/TLS and DTLS or
in some cases has very minor differences.

By adding a few fields to SSL3_ENC to include the header length, some flags
and function pointers for handshake header setting and handshake writing the
code can cope with both cases.

Note: although this passes "make test" and some simple DTLS tests there may
be some minor differences in the DTLS code that have to be accounted for.

perform sanity checks on server certificate type as soon as it is received instead of waiting until server key exchange

by a certificate chain. Add additional tests to handle client
certificates: checks for matching certificate type and issuer name
comparison.

Print out results of checks for each candidate chain tested in
s_server/s_client.

that are disabled for this session (as opposed to always disabled by
configuration).

details in s_client.

Also add ctrl to set client certificate types. If not used sensible values
will be included based on supported signature algorithms: for example if
we don't include any DSA signing algorithms the DSA certificate type is
omitted.

Fix restriction in old code where certificate types would be truncated
if it exceeded TLS_CT_NUMBER.

is required by client or server. An application can decide which
certificate chain to present based on arbitrary criteria: for example
supported signature algorithms. Add very simple example to s_server.
This fixes many of the problems and restrictions of the existing client
certificate callback: for example you can now clear existing certificates
and specify the whole chain.

Reviewed by: steve
Improved localisation of TLS extension handling and code tidy.