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)

This patch makes the decoding of SSLv3 and TLS CBC records constant
time. Without this, a timing side-channel can be used to build a padding
oracle and mount Vaudenay's attack.

This patch also disables the stitched AESNI+SHA mode pending a similar
fix to that code.

In order to be easy to backport, this change is implemented in ssl/,
rather than as a generic AEAD mode. In the future this should be changed
around so that HMAC isn't in ssl/, but crypto/ as FIPS expects.
(cherry picked from commit e130841bccfc0bb9da254dc84e23bc6a1c78a64e)

client hello message. Previously this could only be retrieved on an initial
connection and it was impossible to determine the cipher IDs of any uknown
ciphersuites.

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.

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.

possible to have different stores per SSL structure or one store in
the parent SSL_CTX. Include distint stores for certificate chain
verification and chain building. New ctrl SSL_CTRL_BUILD_CERT_CHAIN
to build and store a certificate chain in CERT structure: returing
an error if the chain cannot be built: this will allow applications
to test if a chain is correctly configured.

Note: if the CERT based stores are not set then the parent SSL_CTX
store is used to retain compatibility with existing behaviour.

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.

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.

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.