This reverts commit 487cd50bbe2cd30aedfcb35fda706061c05628e9.

Change-Id: I03d4dcc6246c1037abc8afc34ddec50ba0a8451f
Reviewed-on: http://mgit-tm.rnd.huawei.com/5004161Tested-by: Npublic jenkins <public_jenkins@notesmail.huawei.com>
Reviewed-by: Ngaokui 00368537 <gaokui1@huawei.com>
Reviewed-by: Nliwei 00495960 <sirius.liwei@huawei.com>

Description:D-Transport: Connection Setup on Server side
Team:OTHERS
Feature or Bugfix:Feature
Binary Source:No
PrivateCode(Yes/No):No

Change-Id: I1214f2f74b233555f2903a23990640852e42cca6
Reviewed-on: http://mgit-tm.rnd.huawei.com/4999713Reviewed-by: Nwangyanbo 00291255 <wangyanbo3@huawei.com>
Tested-by: Npublic jenkins <public_jenkins@notesmail.huawei.com>
Reviewed-by: Ngaokui 00368537 <gaokui1@huawei.com>
Reviewed-by: Ntenghui 00211420 <th.tenghui@huawei.com>

SSL(_CTX)?_set_client_CA_list() was a server side only function in 1.1.0.
If it was called on the client side then it was ignored. In 1.1.1 it now
makes sense to have a CA list defined for both client and server (the
client now sends it the the TLSv1.3 certificate_authorities extension).
Unfortunately some applications were using the same SSL_CTX for both
clients and servers and this resulted in some client ClientHellos being
excessively large due to the number of certificate authorities being sent.

This commit seperates out the CA list updated by
SSL(_CTX)?_set_client_CA_list() and the more generic
SSL(_CTX)?_set0_CA_list(). This means that SSL(_CTX)?_set_client_CA_list()
still has no effect on the client side. If both CA lists are set then
SSL(_CTX)?_set_client_CA_list() takes priority.

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

(cherry picked from commit 98732979001dbb59320803713c4c91ba40234250)

Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/7564)

(cherry picked from commit 2087028612027368e9508e1b253aab715a5a35d6)

Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/7564)

(cherry picked from commit e931f370aa38d8645b35fb8d6260cb44d37b6b61)

Historically SSL_CTX_set_ssl_version() has reset the cipher list
to the default.  Splitting TLS 1.3 ciphers to be tracked separately
caused a behavior change, in that TLS 1.3 cipher configuration was
preserved across calls to SSL_CTX_set_ssl_version().  To restore commensurate
behavior with the historical behavior, set the ciphersuites to the default as
well as setting the cipher list to the default.

Closes: #7226
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7270)

(cherry picked from commit 2340ed277b7c5365e83a32eb7d5fa32c4071fb21)

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)

We already have SSL_set_post_handshake_auth(). This just adds the SSL_CTX
equivalent.
Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6938)

Having post handshake auth automatically switched on breaks some
applications written for TLSv1.2. This changes things so that an explicit
function call is required for a client to indicate support for
post-handshake auth.

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

Reviewed-by: NPaul Dale <paul.dale@oracle.com>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6786)

Commit 1c4aa31d changed how we process
and store SNI information during the handshake, so that a hostname is
only saved in the SSL_SESSION structure if that SNI value has actually
been negotiated.  SSL_get_servername() was adjusted to match, with a new
conditional being added to handle the case when the handshake processing
is ongoing, and a different location should be consulted for the offered
SNI value.  This was done in an attempt to preserve the historical
behavior of SSL_get_servername(), a function whose behavior only mostly
matches its documentation, and whose documentation is both lacking and
does not necessarily reflect the actual desired behavior for such an
API.  Unfortunately, sweeping changes that would bring more sanity to
this space are not possible until OpenSSL 1.2.0, for ABI compatibility
reasons, so we must attempt to maintain the existing behavior to the
extent possible.

The above-mentioned commit did not take into account the behavior
of SSL_get_servername() during resumption handshakes for TLS 1.2 and
prior, where no SNI negotiation is performed.  In that case we would
not properly parse the incoming SNI and erroneously return NULL as
the servername, when instead the logical session is associated with
the SNI value cached in the SSL_SESSION.  (Note that in some cases an
SNI callback may not need to do anything in a TLS 1.2 or prior resumption
flow, but we are calling the callbacks and did not provide any guidance
that they should no-op if the connection is being resumed, so we must
handle this case in a usable fashion.)  Update our behavior accordingly to
return the session's cached value during the handshake, when resuming.
This fixes the boringssl tests.

[extended tests]
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6792)

In particular, adhere to the rule that we must not modify any
property of an SSL_SESSION object once it is (or might be) in
a session cache.  Such modifications are thread-unsafe and have
been observed to cause crashes at runtime.

To effect this change, standardize on the property that
SSL_SESSION->ext.hostname is set only when that SNI value
has been negotiated by both parties for use with that session.
For session resumption this is trivially the case, so only new
handshakes are affected.

On the client, the new semantics are that the SSL->ext.hostname is
for storing the value configured by the caller, and this value is
used when constructing the ClientHello.  On the server, SSL->ext.hostname
is used to hold the value received from the client.  Only if the
SNI negotiation is successful will the hostname be stored into the
session object; the server can do this after it sends the ServerHello,
and the client after it has received and processed the ServerHello.

This obviates the need to remove the hostname from the session object
in case of failed negotiation (a change that was introduced in commit
9fb6cb81 in order to allow TLS 1.3
early data when SNI was present in the ClientHello but not the session
being resumed), which was modifying cached sessions in certain cases.
(In TLS 1.3 we always produce a new SSL_SESSION object for new
connections, even in the case of resumption, so no TLS 1.3 handshakes
were affected.)
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6378)

Previoulsy we just had max_early_data which controlled both the value of
max early_data that we advertise in tickets *and* the amount of early_data
that we are willing to receive from clients. This doesn't work too well in
the case where we want to reduce a previously advertised max_early_data
value. In that case clients with old, stale tickets may attempt to send us
more early data than we are willing to receive. Instead of rejecting the
early data we abort the connection if that happens.

To avoid this we introduce a new "recv_max_early_data" value. The old
max_early_data becomes the value that is advertised in tickets while
recv_max_early_data is the maximum we will tolerate from clients.

Fixes #6647
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/6655)

Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6469)

Fixes #6389
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6469)

Implement support for stateful TLSv1.3 tickets, and use them if
SSL_OP_NO_TICKET is set.
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6563)

Because TLS 1.3 sends more non-application data records some clients run
into problems because they don't expect SSL_read() to return and set
SSL_ERROR_WANT_READ after processing it.

This can cause problems for clients that use blocking I/O and use
select() to see if data is available. It can be cleared using
SSL_CTX_clear_mode().
Reviewed-by: NMatt Caswell <matt@openssl.org>
GH: #6260

In TLSv1.2 and below we always cache new sessions by default on the server
side in the internal cache (even when we're using session tickets). This is
in order to support resumption from a session id.

In TLSv1.3 there is no session id. It is only possible to resume using the
ticket. Therefore, in the default case,  there is no point in caching the
session in the internal store.

There is still a reason to call the external cache new session callback
because applications may be using the callbacks just to know about when
sessions are created (and not necessarily implementing a full cache). If
the application also implements the remove session callback then we are
forced to also store it in the internal cache so that we can create
timeout events. Otherwise the external cache could just fill up
indefinitely.

This mostly addresses the issue described in #5628. That issue also proposes
having an option to not create full stateless tickets when using the
internal cache. That aspect hasn't been addressed yet.
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NBen Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/6293)

Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5227)

We send a session ticket automatically in TLSv1.3 at the end of the
handshake. This commit provides the ability to set how many tickets should
be sent. By default this is one.

Fixes #4978
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5227)

When a server call SSL_write_early_data() to write to an unauthenticated
client the buffering BIO is still in place, so we should ensure we flush
the write.
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6198)

The function SSL_get_shared_ciphers() is supposed to return ciphers shared
by the client and the server. However it only ever returned the client
ciphers.

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

Commit d316cdcf introduced some extra
checks into the session-cache update procedure, intended to prevent
the caching of sessions whose resumption would lead to a handshake
failure, since if the server is authenticating the client, there needs to
be an application-set "session id context" to match up to the authentication
context.  While that change is effective for its stated purpose, there
was also some collatoral damage introduced along with the fix -- clients
that set SSL_VERIFY_PEER are not expected to set an sid_ctx, and so
their usage of session caching was erroneously denied.

Fix the scope of the original commit by limiting it to only acting
when the SSL is a server SSL.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5967)

If SSL_set_bio() is called with a NULL wbio after a failed connection then
this can trigger an assertion failure. This should be valid behaviour and
the assertion is in fact invalid and can simply be removed.
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5966)

Configuration of TLSv1.3 ciphersuites wasn't working in some cases.

Fixes #5740
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5855)

Almost all *alloc failures now set an error code.
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/5842)

Reviewed-by: NDr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: NRich Salz <rsalz@openssl.org>

Fixes: #4641
GH: #4665

Based on the description in https://github.com/openssl/openssl/pull/5757,
this re-implements the "allow NULL to be passed" behavior of a number of
xxx_free routines.  I also fixed up some egregious formatting errors
that were nearby.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5761)

This removes some code because we cannot trace the original contributor
to get their agreement for the licence change (original commit e03ddfae).

After this change there will be numerous failures in the test cases until
someone rewrites the missing code.

All *_free functions should accept a NULL parameter. After this change
the following *_free functions will fail if a NULL parameter is passed:

BIO_ACCEPT_free()
BIO_CONNECT_free()
BN_BLINDING_free()
BN_CTX_free()
BN_MONT_CTX_free()
BN_RECP_CTX_free()
BUF_MEM_free()
COMP_CTX_free()
ERR_STATE_free()
TXT_DB_free()
X509_STORE_free()
ssl3_free()
ssl_cert_free()
SSL_SESSION_free()
SSL_free()

[skip ci]
Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/5757)

The sid_ctx is something of a "certificate request context" or a
"session ID context" -- something from the application that gives
extra indication of what sort of thing this session is/was for/from.
Without a sid_ctx, we only know that there is a session that we
issued, but it could have come from a number of things, especially
with an external (shared) session cache.  Accordingly, when resuming,
we will hard-error the handshake when presented with a session with
zero-length sid_ctx and SSL_VERIFY_PEER is set -- we simply have no
information about the peer to verify, so the verification must fail.

In order to prevent these future handshake failures, proactively
decline to add the problematic sessions to the session cache.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5175)

Place the session ticket AES and HMAC keys into secure memory.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2351)

When SSL_CTX is created preinitialize it with system default
configuration from system_default section.
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4848)

Since the public and private DRBG are per thread we don't need one
per ssl object anymore. It could also try to get entropy from a DRBG
that's really from an other thread because the SSL object moved to an
other thread.
Reviewed-by: NTim Hudson <tjh@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/5547)

This commit adds a new api RAND_DRBG_set_defaults() which sets the
default type and flags for new DRBG instances. See also #5576.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5632)

Fixes #4403

This commit moves the internal header file "internal/rand.h" to
<openssl/rand_drbg.h>, making the RAND_DRBG API public.
The RAND_POOL API remains private, its function prototypes were
moved to "internal/rand_int.h" and converted to lowercase.

Documentation for the new API is work in progress on GitHub #5461.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5462)

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

With the current mechanism, old cipher strings that used to work in 1.1.0,
may inadvertently disable all TLSv1.3 ciphersuites causing connections to
fail. This is confusing for users.

In reality TLSv1.3 are quite different to older ciphers. They are much
simpler and there are only a small number of them so, arguably, they don't
need the same level of control that the older ciphers have.

This change splits the configuration of TLSv1.3 ciphers from older ones.
By default the TLSv1.3 ciphers are on, so you cannot inadvertently disable
them through your existing config.

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

Adds application data into the encrypted session ticket
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3802)

Allow users to distinguish between an error occurring and an HRR being
issued.

Fixes #5549
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5562)