ChangeCipherSpec messages have a defined value. They also may not occur
in the middle of a handshake message. The current logic will accept a
ChangeCipherSpec with value 2. It also would accept up to three bytes of
handshake data before the ChangeCipherSpec which it would discard
(because s->init_num gets reset).

Instead, require that s->init_num is 0 when a ChangeCipherSpec comes in.

RT#4391
Reviewed-by: NAndy Polyakov <appro@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

The write BIO for handshake messages is bufferred so that we only write
out to the network when we have a complete flight. There was some
complexity in the buffering logic so that we switched buffering on and
off at various points through out the handshake. The only real reason to
do this was historically it complicated the state machine when you wanted
to flush because you had to traverse through the "flush" state (in order
to cope with NBIO). Where we knew up front that there was only going to
be one message in the flight we switched off buffering to avoid that.

In the new state machine there is no longer a need for a flush state so
it is simpler just to have buffering on for the whole handshake. This
also gives us the added benefit that we can simply call flush after every
flight even if it only has one message in it. This means that BIO authors
can implement their own buffering strategies and not have to be aware of
the state of the SSL object (previously they would have to switch off
their own buffering during the handshake because they could not rely on
a flush being received when they really needed to write data out). This
last point addresses GitHub Issue #322.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

Since with SSL_VERIFY_NONE, the connection may continue and the
session may even be cached, we should save some evidence that the
chain was not sufficiently verified and would have been rejected
with SSL_VERIFY_PEER.  To that end when a CT callback returs failure
we set the verify result to X509_V_ERR_NO_VALID_SCTS.

Note: We only run the CT callback in the first place if the verify
result is still X509_V_OK prior to start of the callback.

RT #4502
Reviewed-by: NTim Hudson <tjh@openssl.org>

Set ctx->error = X509_V_ERR_OUT_OF_MEM when verificaiton cannot
continue due to malloc failure.  Also, when X509_verify_cert()
returns <= 0 make sure that the verification status does not remain
X509_V_OK, as a last resort set it it to X509_V_ERR_UNSPECIFIED,
just in case some code path returns an error without setting an
appropriate value of ctx->error.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

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

In the SSLV2ClientHello processing code in ssl3_get_record, the value of
|num_recs| will always be 0. This isn't obvious from the code so a comment
is added to explain it.
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

The function ssl3_get_record() can obtain multiple records in one go
as long as we are set up for pipelining and all the records are app
data records. The logic in the while loop which reads in each record is
supposed to only continue looping if the last record we read was app data
and we have an app data record waiting in the buffer to be processed. It
was actually checking that the first record had app data and we have an
app data record waiting. This actually amounts to the same thing so wasn't
wrong - but it looks a bit odd because it uses the |rr| array without an
offset.
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

Pipelining introduced the concept of multiple records being read in one
go. Therefore we work with an array of SSL3_RECORD objects. The pipelining
change erroneously made a change in ssl3_get_record() to apply the current
record offset to the SSL3_BUFFER we are using for reading. This is wrong -
there is only ever one read buffer. This reverts that change. In practice
this should make little difference because the code block in question is
only ever used when we are processing a single record.
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

Fix various references to s3_clnt.c and s3_srvr.c which don't exist
any more.

GitHub Issue #765
Reviewed-by: NRichard Levitte <levitte@openssl.org>

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

MR: #2153

This involves providing more session ticket key data, for both the cipher and
the digest
Signed-off-by: NKurt Roeckx <kurt@roeckx.be>
Reviewed-by: NMatt Caswell <matt@openssl.org>

GH: #515, MR: #2153

Signed-off-by: NKurt Roeckx <kurt@roeckx.be>
Reviewed-by: NMatt Caswell <matt@openssl.org>

GH: #515, MR: #2153

Document thread-safe lock creation
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

To allow OCSP stapling to work with libcurl.

Github PR #200
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

Since 50932c4a "PACKETise ServerHello processing",
ssl_next_proto_validate() incorrectly allows empty protocol name.
draft-agl-tls-nextprotoneg-04[1] says "Implementations MUST ensure that
the empty string is not included and that no byte strings are
truncated."
This patch restores the old correct behavior.

[1] https://tools.ietf.org/html/draft-agl-tls-nextprotoneg-04Reviewed-by: NEmilia Käsper <emilia@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

Add a status return value instead of void.
Add some sanity checks on reference counter value.
Update the docs.
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

The current limit of 2^14 bytes is too low (e.g. RFC 5246 specifies the
maximum size of just the extensions field to be 2^16-1), and may cause
bogus failures.

RT#4063
Reviewed-by: NKurt Roeckx <kurt@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/413)

Per RFC 4507, section 3.3:

   This message [NewSessionTicket] MUST be sent if the
   server included a SessionTicket extension in the ServerHello.  This
   message MUST NOT be sent if the server did not include a
   SessionTicket extension in the ServerHello.

The presence of the NewSessionTicket message should be determined
entirely from the ServerHello without probing.

RT#4389
Reviewed-by: NEmilia Käsper <emilia@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

RT#4438
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NStephen Henson <steve@openssl.org>

RT#4403
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

Reviewed-by: NStephen Henson <steve@openssl.org>

The V2ClientHello code creates an empty compression list, but the
compression list must explicitly contain the null compression (and later
code enforces this).

RT#4387
Reviewed-by: NStephen Henson <steve@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

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

Per RFC 5246,

    Note: this extension is not meaningful for TLS versions prior to 1.2.
    Clients MUST NOT offer it if they are offering prior versions.
    However, even if clients do offer it, the rules specified in [TLSEXT]
    require servers to ignore extensions they do not understand.

Although second sentence would suggest that there would be no interop
problems in always offering the extension, WebRTC has reported issues
with Bouncy Castle on < TLS 1.2 ClientHellos that still include
signature_algorithms. See also
https://bugs.chromium.org/p/webrtc/issues/detail?id=4223

RT#4390
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NStephen Henson <steve@openssl.org>

When setting a new SRTP connection profile using
SSL_CTX_set_tlsext_use_srtp() or SSL_set_tlsext_use_srtp() we should
free any existing profile first to avoid a memory leak.
Reviewed-by: NKurt Roeckx <kurt@openssl.org>

No code change
Reviewed-by: NKurt Roeckx <kurt@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

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

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

If the application has limited the size of the async pool using
ASYNC_init_thread() then we could run out of jobs while trying to start a
libssl io operation. However libssl was failing to handle this and treating
it like a fatal error. It should not be fatal...we just need to retry when
there are jobs available again.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Based on an orignal commit by GitHub user BertramScharpf. Rebased and
updated to take account of all the updates since this was first raised.

GH PR#62
Reviewed-by: NRich Salz <rsalz@openssl.org>

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

If no serverinfo extension is found in some cases, do not abort the handshake,
but simply omit/skip that extension.

Check for already-registered serverinfo callbacks during serverinfo
registration.

Update SSL_CTX_use_serverinfo() documentation to mention the need to reload the
same serverinfo per certificate, for servers with multiple server certificates.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

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

This macro was defined by no-longer-supported __MWERKS__ compiler.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Building with -DCHARSET_EBCDIC and using --strict-warnings resulted in
lots of miscellaneous errors. This fixes it.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

The tls_client_key_exchange_post_work() frees the pms on error. It also
calls ssl_generate_master_secret() which also free the pms. If an error
occurs after ssl_generate_master_secret() has been called then a double
free can occur.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

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

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

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