Force no SSL2 when custom extensions in use.
Don't clear extension state when cert is set.
Clear on renegotiate.

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

serverinfo rejects non-empty extensions.

Omit extension if no relevant serverinfo data.

Improve error-handling in serverinfo callback.

Cosmetic cleanups.

s_client documentation.

s_server documentation.

SSL_CTX_serverinfo documentation.

Cleaup -1 and NULL callback handling for custom extensions, add tests.

Cleanup ssl_rsa.c serverinfo code.

Whitespace cleanup.

Improve comments in ssl.h for serverinfo.

Whitespace.

Cosmetic cleanup.

Reject non-zero-len serverinfo extensions.

Whitespace.

Make it build.

Contributed by Trevor Perrin.

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.

Some TLS extensions were disabled for DTLS. Possibly because they caused
problems with the old duplicated code. Enable them again.

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.

This change adds CRYPTO_memcmp, which compares two vectors of bytes in
an amount of time that's independent of their contents. It also changes
several MAC compares in the code to use this over the standard memcmp,
which may leak information about the size of a matching prefix.
(cherry picked from commit 2ee798880a246d648ecddadc5b91367bee4a5d98)

side, if possible.

Don't advertise compressed char2 for SuiteB as it is not supported.

new feature: if ctx==NULL in SSL_CTX_ctrl perform syntax checking only for some operations (currently curves and signature algorithms)

change the current certificate (in s->cert->key) to the one used and then
SSL_get_certificate and SSL_get_privatekey will automatically work.

right response is stapled. Also change SSL_get_certificate() so it
returns the certificate actually sent.  See
http://rt.openssl.org/Ticket/Display.html?id=2836.

some invalid operations for testing purposes. Currently this can be used
to sign using digests the peer doesn't support, EC curves the peer
doesn't support and use certificates which don't match the type associated
with a ciphersuite.

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

the permitted signature algorithms for server and client authentication
are the same but it is now possible to set different algorithms for client
authentication only.

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.

appropriate checks in tls1_check_chain.

the certificate can be used for (if anything). Set valid_flags field
in new tls1_check_chain function. Simplify ssl_set_cert_masks which used
to have similar checks in it.

Add new "cert_flags" field to CERT structure and include a "strict mode".
This enforces some TLS certificate requirements (such as only permitting
certificate signature algorithms contained in the supported algorithms
extension) which some implementations ignore: this option should be used
with caution as it could cause interoperability issues.

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.