The supported signature algorithms extension needs to be processed before
the certificate to use is decided and before a cipher is selected (as the
set of shared signature algorithms supported may impact the choice).
Reviewed-by: NMatt Caswell <matt@openssl.org>

(cherry picked from commit 56e8dc542bd693b2dccea8828b3d8e5fc6932d0c)

Conflicts:
	ssl/ssl.h
	ssl/ssl_err.c

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

Support separate parse and add callback arguments.
Add new callback so an application can free extension data.
Change return value for send functions so < 0 is an error 0
omits extension and > 0 includes it. This is more consistent
with the behaviour of other functions in OpenSSL.

Modify parse_cb handling so <= 0 is an error.

Make SSL_CTX_set_custom_cli_ext and SSL_CTX_set_custom_cli_ext argument
order consistent.

NOTE: these changes WILL break existing code.

Remove (now inaccurate) in line documentation.
Reviewed-by: NEmilia Käsper <emilia@openssl.org>

Use "parse" and "add" for function and callback names instead of
"first" and "second".

Change arguments to callback so the extension type is unsigned int
and the buffer length is size_t. Note: this *will* break existing code.
Reviewed-by: NEmilia Käsper <emilia@openssl.org>

Reject attempts to use extensions handled internally.

Add flags to each extension structure to indicate if an extension
has been sent or received. Enforce RFC5246 compliance by rejecting
duplicate extensions and unsolicited extensions and only send a
server extension if we have sent the corresponding client extension.
Reviewed-by: NEmilia Käsper <emilia@openssl.org>

Use the same structure for client and server custom extensions.

Add utility functions in new file t1_ext.c.
Use new utility functions to handle custom server and client extensions
and remove a lot of code duplication.
Reviewed-by: NEmilia Käsper <emilia@openssl.org>

Move custom extension structures from SSL_CTX to CERT structure.

This change means the form can be revised in future without binary
compatibility issues. Also since CERT is part of SSL structures
so per-SSL custom extensions could be supported in future as well as
per SSL_CTX.
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NEmilia Käsper <emilia@openssl.org>

Check SRP parameters when they are received so we can send back an
appropriate alert.
Reviewed-by: NKurt Roeckx <kurt@openssl.org>

Don't call internal functions directly call them through
SSL_test_functions(). This also makes unit testing work on
Windows and platforms that don't export internal functions
from shared libraries.

By default unit testing is not enabled: it requires the compile
time option "enable-unit-test".
Reviewed-by: NGeoff Thorpe <geoff@openssl.org>

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

(cherry picked from commit 2db3ea29298bdc347f15fbfab6d5746022f05101)

Conflicts:
	ssl/t1_lib.c

SRP ciphersuites do not have no authentication. They have authentication
based on SRP. Add new SRP authentication flag and cipher string.

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.

Add auto DH parameter support. This is roughly equivalent to the
ECDH auto curve selection but for DH. An application can just call

SSL_CTX_set_auto_dh(ctx, 1);

and appropriate DH parameters will be used based on the size of the
server key.

Unlike ECDH there is no way a peer can indicate the range of DH parameters
it supports. Some peers cannot handle DH keys larger that 1024 bits for
example. In this case if you call:

SSL_CTX_set_auto_dh(ctx, 2);

Only 1024 bit DH parameters will be used.

If the server key is 7680 bits or more in size then 8192 bit DH parameters
will be used: these will be *very* slow.

The old export ciphersuites aren't supported but those are very
insecure anyway.

(cherry picked from commit 3678161d717d0f46c5b5b052a6d6a33438b1df00)

Add the RFC6962 OIDs to the objects table.

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.

New ctrl sets current certificate based on certain criteria. Currently
two options: set the first valid certificate as current and set the
next valid certificate as current. Using these an application can
iterate over all certificates in an SSL_CTX or SSL structure.

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.

PR#3169

This patch, which currently applies successfully against master and
1_0_2, adds the following functions:

SSL_[CTX_]select_current_cert() - set the current certificate without
disturbing the existing structure.

SSL_[CTX_]get0_chain_certs() - get the current certificate's chain.

SSL_[CTX_]clear_chain_certs() - clear the current certificate's chain.

The patch also adds these functions to, and fixes some existing errors
in, SSL_CTX_add1_chain_cert.pod.

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

This is a forward-port of commits:
  4af793036f6ef4f0a1078e5d7155426a98d50e37
  f4c93b46edb51da71f09eda99e83eaf193a33c08
  3da721dac9382c48812c8eba455528fd59af2eef
  2583270191a8b27eed303c03ece1da97b9b69fd3

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.

Experimental support for encrypt then mac from
draft-gutmann-tls-encrypt-then-mac-02.txt

To enable it set the appropriate extension number (0x10 for the test server)
using e.g. -DTLSEXT_TYPE_encrypt_then_mac=0x10

For non-compliant peers (i.e. just about everything) this should have no
effect.

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.

Contributed by Trevor Perrin.

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.

Since s->method does not reflect the final client version when a client
hello is sent for SSLv23_client_method it can't be relied on to indicate
if TLS 1.2 ciphers should be used. So use the client version instead.

Port TLS 1.2 GCM code to DTLS. Enable use of TLS 1.2 only ciphers when in
DTLS 1.2 mode 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.

Extend DTLS method creation macros to support version numbers and encryption
methods. Update existing code.

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.

Add DTLS record header parsing, different client hello format and add
HelloVerifyRequest message type.

Add code to d1_pkt.c to send message headers to the message callback.

Revert is appropriate because binary compatibility is not an issue
in 1.1.

Kludge alert. This is arranged by passing padding length in unused
bits of SSL3_RECORD->type, so that orig_len can be reconstructed.
(cherry picked from commit 8bfd4c659f180a6ce34f21c0e62956b362067fba)

We have to use EVP in FIPS mode so we can only partially mitigate
timing differences.

Make an extra call to EVP_DigestSignUpdate to hash additonal blocks
to cover any timing differences caused by removal of padding.
(cherry picked from commit b908e88ec15aa0a74805e3f2236fc4f83f2789c2)