coexist.
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7233)

(cherry picked from commit da5fac72b1cba5651b871902eea234e693cf01e5)

Fixed a minor typo while reading the documentation.
I agree that this contribution is trivial can be freely used.

CLA: trivial
Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/7221)

Reviewed-by: NBen Kaduk <kaduk@mit.edu>
GH: #7188
(cherry picked from commit 8e593f0a0dbcb3193548ced3c2e78fbbd201b2db)

It simply isn't available on older versions.

Issue submitted by Mark Daniels

Fixes #7229
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/7230)

Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/7209)

-early_data is not compatible with -www, -WWW, -HTTP or -rev.

Fixes #7200
Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7206)

(cherry picked from commit 6ef40f1fc08f0c4ffb08438d63eed83eae7eb2b8)

Caused a compilation failure in some environments

Fixes #7204
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7205)

(cherry picked from commit bc278f30f0b766bfb82426c641dc1d51ace4a994)

The new DRBG API added the aforementioned #define. However, it is
used internally only and having it defined publicly does not serve
any purpose except causing potential version compatibility problems.

Fixes #7182
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7190)

(cherry picked from commit c402e943cd0d748ca2a74a37caeccdfc59ce2870)

Fixes: #7161 (hopefully)
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7175)

(cherry picked from commit 6839a7a7f4973a3fc2f87b12664c26d524bef1f4)

Fixes a minor typo that would cause the linker to complain about not finding -lFuzzer

CLA: trivial
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7197)

(cherry picked from commit 8e8fe187f1559a7fc9f50cc4af7f880273a4eea2)

- fix to use secure URL in generated Windows resources
- fix a potentially uninitialized variable
- fix an unused variable warning

CLA: trivial
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/7189)

Fixes #7186
Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7193)

(cherry picked from commit 88ea3685e4bf30fc529fe46e19effc6317726de8)

Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7176)

Since the SSL code started using RSA_NO_PADDING, the CAPI engine became
unusable.  This change fixes that.

Fixes #7131
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7174)

Found by Coverity
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7169)

Fixes a Coverity complaint.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7170)

If sizeof(int) != sizeof(size_t) this may not work correctly.

Fixes a Coverity issue.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7168)

Reviewed-by: NBen Kaduk <kaduk@mit.edu>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7167)

Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7164)

Hopefully this will resolve spurious travis failures.

[extended tests]
Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7163)

Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7160)

It's actually not a real issue but caused by the absence of the default case
which does not occur in reality but which makes coverity see a code path where
pkey remains unassigned.

Reported by Coverity Scan (CID 1423323)
[extended tests]
Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7158)

Reported by Coverity Scan (CID 1439138)
[extended tests]
Reviewed-by: NBen Kaduk <kaduk@mit.edu>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7156)

Reported by Coverity Scan (CID 1439136)
[extended tests]
Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7155)

The deprecated ASN.1 type LONG / ZLONG (incorrectly) produced zero
length INTEGER encoding for zeroes.  For the sake of backward
compatibility, we allow those to be read without fault when using the
replacement types INT32 / UINT32 / INT64 / UINT64.

Fixes #7134
Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7144)

Confirms #7134
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7153)

This was originally part of SipHash_Init.  However, there are cases
where there isn't any key material to initialize from when setting the
hash size, and we do allow doing so with a EVP_PKEY control.  The
solution is to provide a separate hash_size setter and to use it in
the corresponding EVP_PKEY_METHOD.

Fixes #7143
Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7145)

Confirms #7143
Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7154)

Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7154)

Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7154)

PR #3783 introduce coded to reset the server side SNI state in
SSL_do_handshake() to ensure any erroneous config time SNI changes are
cleared. Unfortunately SSL_do_handshake() can be called mid-handshake
multiple times so this is the wrong place to do this and can mean that
any SNI data is cleared later on in the handshake too.

Therefore move the code to a more appropriate place.

Fixes #7014
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
Reviewed-by: NBen Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/7149)

Ideally, SSL_get_servername() would do exactly as it is documented
and return exactly what the client sent (i.e., what we currently
are stashing in the SSL's ext.hostname), without needing to refer
to an SSL_SESSION object.  For historical reasons, including the
parsed SNI value from the ClientHello originally being stored in the
SSL_SESSION's ext.hostname field, we have had references to the
SSL_SESSION in this function.  We cannot fully excise them due to
the interaction between user-supplied callbacks and TLS 1.2 resumption
flows, where we call all callbacks but the client did not supply an
SNI value.  Existing callbacks expect to receive a valid SNI value
in this case, so we must fake one up from the resumed session in
order to avoid breakage.

Otherwise, greatly simplify the implementation and just return the
value in the SSL, as sent by the client.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7115)

Commit 1c4aa31d modified the state machine
to clean up stale ext.hostname values from SSL objects in the case when
SNI was not negotiated for the current handshake.  This is natural from
the TLS perspective, since this information is an extension that the client
offered but we ignored, and since we ignored it we do not need to keep it
around for anything else.

However, as documented in https://github.com/openssl/openssl/issues/7014 ,
there appear to be some deployed code that relies on retrieving such an
ignored SNI value from the client, after the handshake has completed.
Because the 1.1.1 release is on a stable branch and should preserve the
published ABI, restore the historical behavior by retaining the ext.hostname
value sent by the client, in the SSL structure, for subsequent retrieval.

[extended tests]
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7115)

The is_tls13_capable() function should not return 0 if no certificates
are configured directly because a certificate callback is present.

Fixes #7140
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7141)

That function was removed in favour of SSL_set_post_handshake_auth().
Update the docs accordingly.
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7139)

Even though we already sent close_notify the server may not have recieved
it yet and could issue a CertificateRequest to us. Since we've already
sent close_notify we can't send any reasonable response so we just ignore
it.
Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7114)

Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7114)

If we've sent a close_notify then we are restricted about what we can do
in response to handshake messages that we receive. However we can sensibly
process NewSessionTicket messages. We can also process a KeyUpdate message
as long as we also ignore any request for us to update our sending keys.
Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7114)