When an SSL's context is swtiched from a ticket-enabled context to
a ticket-disabled context in the servername callback, no session-id
is generated, so the session can't be resumed.

If a servername callback changes the SSL_OP_NO_TICKET option, check
to see if it's changed to disable, and whether a session ticket is
expected (i.e. the client indicated ticket support and the SSL had
tickets enabled at the time), and whether we already have a previous
session (i.e. s->hit is set).

In this case, clear the ticket-expected flag, remove any ticket data
and generate a session-id in the session.

If the SSL hit (resumed) and switched to a ticket-disabled context,
assume that the resumption was via session-id, and don't bother to
update the session.

Before this fix, the updated unit-tests in 06-sni-ticket.conf would
fail test #4 (server1 = SNI, server2 = no SNI).

The pub_key field for DH isn't actually used in DH_compute_key at all.
(Note the peer public key is passed in as as BIGNUM.) It's mostly there
so the caller may extract it from DH_generate_key. It doesn't
particularly need to be present if filling in a DH from external
parameters.

The check in DH_set0_key conflicts with adding OpenSSL 1.1.0 to Node.
Their public API is a thin wrapper over the old OpenSSL one:
https://nodejs.org/api/crypto.html#crypto_class_diffiehellman

They have separate setPrivateKey and setPublicKey methods, so the public
key may be set last or not at all. In 1.0.2, either worked fine since
operations on DH objects generally didn't use the public key. (Like
with OpenSSL, Node's setPublicKey method is also largely a no-op, but so
it goes.) In 1.1.0, DH_set0_key prevents create a private-key-only DH
object.

This guards against the name constraints check consuming large amounts
of CPU time when certificates in the presented chain contain an
excessive number of names (specifically subject email names or subject
alternative DNS names) and/or name constraints.

Name constraints checking compares the names presented in a certificate
against the name constraints included in a certificate higher up in the
chain using two nested for loops.

Move the name constraints check so that it happens after signature
verification so peers cannot exploit this using a chain with invalid
signatures. Also impose a hard limit on the number of name constraints
check loop iterations to further mitigate the issue.

Thanks to NCC for finding this issue. Fix written by Martin Kreichgauer.

c2i_ASN1_BIT_STRING takes length as a long but uses it as an int. Check
bounds before doing so. Previously, excessively large inputs to the
function could write a single byte outside the target buffer. (This is
unreachable as asn1_ex_c2i already uses int for the length.)

Thanks to NCC for finding this issue. Fix written by Martin Kreichgauer.

OpenSSL 1.1.0 made SSL_CTX and SSL structs opaque and introduced a new
API to set the minimum and maximum protocol version for SSL_CTX with
TLS_method(). Add getters to introspect the configured versions:

Simply put, any NAME type OSS_STORE_INTO is a new object that can be
looked into, and potentially lead to a whole tree of data to dive
into. The recursive option allows someone to view the whole tree and
its data in one go.

On related note an attempt was made to merge rotations with logical
operations. I mean as we know, ARM ISA has merged rotate-n-logical
instructions which can be used here. And they were used to improve
keccak1600-armv4 performance. But not here. Even though this approach
resulted in improvement on Cortex-A53 proportional to reduction of
amount of instructions, ~8%, it didn't exactly worked out on
non-Cortex cores. Presumably because they break merged instructions
to separate μ-ops, which results in higher *operations* count. X-Gene
and Denver went ~20% slower and Apple A7 - 40%. The optimization was
therefore dismissed.

If an alert gets sent and then we close the connection immediately with
data still in the input buffer then a TCP-RST gets sent. Some OSs
immediately abandon data in their input buffer if a TCP-RST is received -
meaning the alert data itself gets ditched. Sending a TCP-FIN before the
TCP-RST seems to avoid this.

The extensions not sent when TLS 1.2 is not used caused the message
length to be 109, which is less than the 127 threshold needed
to activate the F5 workaround. Add another 20 bytes of dummy ALPN
data do push it over the threshold.

Also, fix the definition of the (unused) local macro indicating
the threshold.

In OpenSSL 1.1.0, when there were no extensions added to the ServerHello,
we did not write the extension data length bytes to the end of the
ServerHello; this is needed for compatibility with old client implementations
that do not support TLS extensions (such as the default configuration of
OpenSSL 0.9.8). When ServerHello extension construction was converted
to the new extensions framework in commit7da160b0f46d832dbf285cb0b48ae56d4a8b884d, this behavior was inadvertently
limited to cases when SSLv3 was negotiated (and similarly for ClientHellos),
presumably since extensions are not defined at all for SSLv3. However,
extensions for TLS prior to TLS 1.3 have been defined in separate
RFCs (6066, 4366, and 3546) from the TLS protocol specifications, and as such
should be considered an optional protocol feature in those cases.

Accordingly, be conservative in what we send, and skip the extensions block
when there are no extensions to be sent, regardless of the TLS/SSL version.
(TLS 1.3 requires extensions and can safely be treated differently.)

Don't use ciphersuites for inflating the ClientHello in clienthellotest

clienthellotest tries to fill out the size of the ClientHello by adding
extra ciphersuites in order to test the padding extension. This is
unreliable because they are very dependent on configuration options. If we
add too much data the test will fail! We were already also adding some dummy
ALPN protocols to pad out the size, and it turns out that this is sufficient
just in itself, so drop the extra ciphersuites.