Update master secret calculation to support extended master secret.
TLS 1.2 client authentication adds a complication because we need to
cache the handshake messages. This is simpllified however because
the point at which the handshake hashes are calculated for extended
master secret is identical to that required for TLS 1.2 client
authentication (immediately after client key exchange which is also
immediately before certificate verify).
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

Add and retrieve extended master secret extension, setting the flag
SSL_SESS_FLAG_EXTMS appropriately.

Note: this just sets the flag and doesn't include the changes to
master secret generation.
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

An expired IETF Internet-Draft (seven years old) that nobody
implements, and probably just as good as NSA DRBG work.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NTim Hudson <tjh@openssl.org>

Sometimes it fails to format them very well, and sometimes it corrupts them!
This commit moves some particularly problematic ones.
Reviewed-by: NTim Hudson <tjh@openssl.org>

Reviewed-by: NTim Hudson <tjh@openssl.org>

Signed-off-by: NKurt Roeckx <kurt@roeckx.be>
Reviewed-by: NGeoff Thorpe <geoff@openssl.org>

Reviewed-by: NStephen Henson <steve@openssl.org>

Reviewed-by: NDr. Stephen Henson <steve@openssl.org>

While RFC6367 focuses on Camellia-GCM cipher suites, it also adds a few
cipher suites that use SHA-2 based HMAC that can be very easily
added.

Tested against gnutls 3.3.5

PR#3443
Reviewed-by: NTim Hudson <tjh@openssl.org>

Remove RFC5878 code. It is no longer needed for CT and has numerous bugs

PR#2800

Encrypt then MAC now has an official extension value, see:

http://www.ietf.org/id/draft-ietf-tls-encrypt-then-mac-02.txt

Enable TLS padding extension using official value from:

http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml

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...

change documentation and comments to indicate that we prefer the
standard "DHE" naming scheme everywhere over the older "EDH"

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.

This change adds support for ALPN[1] in OpenSSL. ALPN is the IETF
blessed version of NPN and we'll be supporting both ALPN and NPN for
some time yet.

[1] https://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-00

Conflicts:
	ssl/ssl3.h
	ssl/t1_lib.c

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.

Only store encoded versions of peer and configured signature algorithms.
Determine shared signature algorithms and cache the result along with NID
equivalents of each algorithm.

TLS v1.2. These are sent as an extension for clients and during a certificate
request for servers.

TODO: add support for shared signature algorithms, respect shared algorithms
when deciding which ciphersuites and certificates to permit.

Add more extension names in s_cb.c extension printing code.

extensions to s_client and s_server to print out retrieved valued.

Extend CERT structure to cache supported signature algorithm data.

Submitted by: Robin Seggelmann <seggelmann@fh-muenster.de>
Reviewed by: steve

Support for TLS/DTLS heartbeats.

Submitted by: Peter Sylvester <peter.sylvester@edelweb.fr>
Reviewed by: steve

Make SRP conformant to rfc 5054.

Changes are:

- removal of the addition state after client hello
- removal of all pre-rfc srp alert ids
- sending a fatal alert when there is no srp extension but when the
server wants SRP
- removal of unnecessary code in the client.

invocation field.

Add complete support for AES GCM ciphersuites including all those in
RFC5288 and RFC5289.

prohibit use of these ciphersuites for TLS < 1.2

signature algorithms extension and correct signature format for
server key exchange.

All ciphersuites should now work on the server but no client support and
no client certificate support yet.

checking added, SHA256 PRF support added.

At present only RSA key exchange ciphersuites work with TLS v1.2 as the
new signature format is not yet implemented.