This flag was not set anywhere within the codebase (only read). It could
only be set by an app reaching directly into s->s3->flags and setting it
directly. However that method became impossible when libssl was opaquified.

Even in 1.0.2/1.0.1 if an app set the flag directly it is only relevant to
ssl3_connect(), which calls SSL_clear() during initialisation that clears
any flag settings. Therefore it could take effect if the app set the flag
after the handshake has started but before it completed. It seems quite
unlikely that any apps really do this (especially as it is completely
undocumented).

The purpose of the flag is suppress flushing of the write bio on the client
side at the end of the handshake after the client has written the Finished
message whilst resuming a session. This enables the client to send
application data as part of the same flight as the Finished message.

This flag also controls the setting of a second flag SSL3_FLAGS_POP_BUFFER.
There is an interesting comment in the code about this second flag in the
implementation of ssl3_write:

	/* This is an experimental flag that sends the
	 * last handshake message in the same packet as the first
	 * use data - used to see if it helps the TCP protocol during
	 * session-id reuse */

It seems the experiment did not work because as far as I can tell nothing
is using this code. The above comment has been in the code since SSLeay.

This commit removes support for SSL3_FLAGS_DELAY_CLIENT_FINISHED, as well
as the associated SSL3_FLAGS_POP_BUFFER.
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NKurt Roeckx <kurt@openssl.org>

Reviewed-by: NKurt Roeckx <kurt@openssl.org>

Add support for loading verify and chain stores in SSL_CONF.

Commands to set verify mode and client CA names.

Add documentation.
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NMatt Caswell <matt@openssl.org>

Reviewed-by: NMatt Caswell <matt@openssl.org>

The PSK identity hint should be stored in the SSL_SESSION structure
and not in the parent context (which will overwrite values used
by other SSL structures with the same SSL_CTX).
Reviewed-by: NMatt Caswell <matt@openssl.org>

Reviewed-by: NMatt Caswell <matt@openssl.org>

Reviewed-by: NMatt Caswell <matt@openssl.org>

We always free the handshake buffer when digests are freed so move
it into ssl_free_digest_list()
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

Rewrite ssl3_digest_cached_records handling. Only digest cached records
if digest array is NULL: this means it is safe to call
ssl3_digest_cached_records multiple times (subsequent calls are no op).

Remove flag TLS1_FLAGS_KEEP_HANDSHAKE instead only update handshake buffer
if digest array is NULL.

Add additional "keep" parameter to ssl3_digest_cached_records to indicate
if the handshake buffer should be retained after digesting cached records
(needed for TLS 1.2 client authentication).
Reviewed-by: NMatt Caswell <matt@openssl.org>

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

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

If RSA or DSA is disabled we will never use a ciphersuite with
RSA/DSA authentication as it is already filtered out by the cipher
list logic.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

As numerous comments indicate the certificate and key array is not an
appopriate structure to store the peers certificate: so remove it and
just the s->session->peer instead.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

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

This reverts commit d480e182.

Commit broke TLS handshakes due to fragility of digest caching: that will be
fixed separately.
Reviewed-by: NRich Salz <rsalz@openssl.org>

We always free the handshake buffer when digests are freed so move
it into ssl_free_digest_list()
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

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

While closing RT3588 (Remove obsolete comment) Kurt and I saw that a
few lines to completely clear the SSL cipher state could be moved into
a common function.
Reviewed-by: NKurt Roeckx <kurt@openssl.org>

It is valid for an extension block to be present in a ClientHello, but to
be of zero length.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

Fix error handling in ssl_session_dup, as well as incorrect setting up of
the session ticket. Follow on from CVE-2015-1791.

Thanks to LibreSSL project for reporting these issues.
Reviewed-by: NTim Hudson <tjh@openssl.org>

Determine disabled algorithm masks when algorithms are loaded instead of
recalculating them each time.
Reviewed-by: NRich Salz <rsalz@openssl.org>

Restore GOST mac setup which was accidentally removed during cipher
refactor.
Reviewed-by: NRich Salz <rsalz@openssl.org>

This is a workaround so old that nobody remembers what buggy clients
it was for. It's also been broken in stable branches for two years and
nobody noticed (see
https://boringssl-review.googlesource.com/#/c/1694/).
Reviewed-by: NTim Hudson <tjh@openssl.org>

It should not be possible for DTLS message fragments to span multiple
packets. However previously if the message header fitted exactly into one
packet, and the fragment body was in the next packet then this would work.
Obviously this would fail if packets get re-ordered mid-flight.
Reviewed-by: NTim Hudson <tjh@openssl.org>

The underlying field returned by RECORD_LAYER_get_rrec_length() is an
unsigned int. The return type of the function should match that.
Reviewed-by: NTim Hudson <tjh@openssl.org>

This adds additional checks to the processing of extensions in a ClientHello
to ensure that either no extensions are present, or if they are then they
take up the exact amount of space expected.

With thanks to the Open Crypto Audit Project for reporting this issue.
Reviewed-by: NStephen Henson <steve@openssl.org>

Reviewed-by: NMatt Caswell <matt@openssl.org>
MR #588

Reviewed-by: NMatt Caswell <matt@openssl.org>
MR #588

Reviewed-by: NRich Salz <rsalz@openssl.org>

Add extension and ciphersuites to trace code.
Reviewed-by: NRich Salz <rsalz@openssl.org>

At least in the case of SSLv3 we can't send an extention.
Reviewed-by: NMatt Caswell <matt@openssl.org>
MR #811

Remove a comment that suggested further clean up was required.
DH_free() performs the necessary cleanup.

With thanks to the Open Crypto Audit Project for reporting this issue.
Reviewed-by: NRich Salz <rsalz@openssl.org>

Ensure OPENSSL_cleanse() is called on the premaster secret value calculated for GOST.

With thanks to the Open Crypto Audit Project for reporting this issue.
Reviewed-by: NRich Salz <rsalz@openssl.org>

The session object on the client side is initially created during
construction of the ClientHello. If the client is DTLS1.2 capable then it
will store 1.2 as the version for the session. However if the server is only
DTLS1.0 capable then when the ServerHello comes back the client switches to
using DTLS1.0 from then on. However the session version does not get
updated. Therefore when the client attempts to resume that session the
server throws an alert because of an incorrect protocol version.
Reviewed-by: NTim Hudson <tjh@openssl.org>

If a NewSessionTicket is received by a multi-threaded client when
attempting to reuse a previous ticket then a race condition can occur
potentially leading to a double free of the ticket data.

CVE-2015-1791

This also fixes RT#3808 where a session ID is changed for a session already
in the client session cache. Since the session ID is the key to the cache
this breaks the cache access.

Parts of this patch were inspired by this Akamai change:
https://github.com/akamai/openssl/commit/c0bf69a791239ceec64509f9f19fcafb2461b0d3Reviewed-by: NRich Salz <rsalz@openssl.org>

dtls1_get_message has an |mt| variable which is the type of the message that
is being requested. If it is negative then any message type is allowed.
However the value of |mt| is not checked in one of the main code paths, so a
peer can send a message of a completely different type and it will be
processed as if it was the message type that we were expecting. This has
very little practical consequences because the current behaviour will still
fail when the format of the message isn't as expected.
Reviewed-by: NAndy Polyakov <appro@openssl.org>