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

Now we support (u)int64_t this can be very much simpler.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

Fix no-ec builds by having separate functions to create keys based on
an existing EVP_PKEY and a curve id.
Reviewed-by: NRich Salz <rsalz@openssl.org>

When handling ECDH check to see if the curve is "custom" (X25519 is
currently the only curve of this type) and instead of setting a curve
NID just allocate a key of appropriate type.
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1413)

DTLSv1_client_method() is deprecated, but it was the only way to obtain
DTLS1_BAD_VER support. The SSL_OP_CISCO_ANYCONNECT hack doesn't work with
DTLS_client_method(), and it's relatively non-trivial to make it work without
expanding the hack into lots of places.

So deprecate SSL_OP_CISCO_ANYCONNECT with DTLSv1_client_method(), and make
it work with SSL_CTX_set_{min,max}_proto_version(DTLS1_BAD_VER) instead.
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

DTLS version numbers are strange and backwards, except DTLS1_BAD_VER so
we have to make a special case for it.

This does leave us with a set of macros which will evaluate their arguments
more than once, but it's not a public-facing API and it's not like this is
the kind of thing where people will be using DTLS_VERSION_LE(x++, y) anyway.
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

- Always process ALPN (previously there was an early return in the
  certificate status handling)
- Don't send a duplicate alert. Previously, both
  ssl_check_clienthello_tlsext_late and its caller would send an
  alert. Consolidate alert sending code in the caller.
Reviewed-by: NRich Salz <rsalz@openssl.org>

The parameters should have parens around them when used.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

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

The ssl3_init_finished_mac() function can fail, in which case we need to
propagate the error up through the stack.

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

Reviewed-by: NRich Salz <rsalz@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>

Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NKurt Roeckx <kurt@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

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>

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>

There is a preference for suffixes to indicate that a function is internal
rather than prefixes. Note: the suffix is only required to disambiguate
internal functions and public symbols with the same name (but different
case)
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>

There was a lot of naming inconsistency, so we try and standardise on
one form.
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>

SSL_COMP_free_compression_methods() should not be called expicitly - we
should leave auto-deinit to clean this up instead.
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>

The function pqueue_print is not exported and is never called. Therefore
we should delete it.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

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

Suppress CT callbacks with aNULL or PSK ciphersuites that involve
no certificates.  Ditto when the certificate chain is validated via
DANE-TA(2) or DANE-EE(3) TLSA records.  Also skip SCT processing
when the chain is fails verification.

Move and consolidate CT callbacks from libcrypto to libssl.  We
also simplify the interface to SSL_{,CTX_}_enable_ct() which can
specify either a permissive mode that just collects information or
a strict mode that requires at least one valid SCT or else asks to
abort the connection.

Simplified SCT processing and options in s_client(1) which now has
just a simple pair of "-noct" vs. "-ct" options, the latter enables
the permissive callback so that we can complete the handshake and
report all relevant information.  When printing SCTs, print the
validation status if set and not valid.
Signed-off-by: NRob Percival <robpercival@google.com>
Reviewed-by: NEmilia Käsper <emilia@openssl.org>

We now send the highest supported version by the client, even if the session
uses an older version.

This fixes 2 problems:
- When you try to reuse a session but the other side doesn't reuse it and
  uses a different protocol version the connection will fail.
- When you're trying to reuse a session with an old version you might be
  stuck trying to reuse the old version while both sides support a newer
  version
Signed-off-by: NKurt Roeckx <kurt@roeckx.be>
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

GH: #852, MR: #2452

algo_strength contains 2 parts that need to be checked by their own.
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

MR: #2082

Don't have #error statements in header files, but instead wrap
the contents of that file in #ifndef OPENSSL_NO_xxx
This means it is now always safe to include the header file.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reduces #ifdef complexity.
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

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

MR: #1824

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

MR: #1595

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

MR: #1595

Adjust ssl_set_client_hello_version to get both the minimum and maximum and then
make ssl_set_client_hello_version use the maximum version.
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

MR: #1595

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

MR: #1595

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

MR: #1595

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

* Perform ALPN after the SNI callback; the SSL_CTX may change due to
  that processing
* Add flags to indicate that we actually sent ALPN, to properly error
  out if unexpectedly received.
* clean up ssl3_free() no need to explicitly clear when doing memset
* document ALPN functions
Signed-off-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NEmilia Käsper <emilia@openssl.org>

This capability is required for read pipelining. We will only read in as
many records as will fit in the read buffer (and the network can provide
in one go). The bigger the buffer the more records we can process in
parallel.
Reviewed-by: NTim Hudson <tjh@openssl.org>

Use the new pipeline cipher capability to encrypt multiple records being
written out all in one go. Two new SSL/SSL_CTX parameters can be used to
control how this works: max_pipelines and split_send_fragment.

max_pipelines defines the maximum number of pipelines that can ever be used
in one go for a single connection. It must always be less than or equal to
SSL_MAX_PIPELINES (currently defined to be 32). By default only one
pipeline will be used (i.e. normal non-parallel operation).

split_send_fragment defines how data is split up into pipelines. The number
of pipelines used will be determined by the amount of data provided to the
SSL_write call divided by split_send_fragment. For example if
split_send_fragment is set to 2000 and max_pipelines is 4 then:
SSL_write called with 0-2000 bytes == 1 pipeline used
SSL_write called with 2001-4000 bytes == 2 pipelines used
SSL_write called with 4001-6000 bytes == 3 pipelines used
SSL_write_called with 6001+ bytes == 4 pipelines used

split_send_fragment must always be less than or equal to max_send_fragment.
By default it is set to be equal to max_send_fragment. This will mean that
the same number of records will always be created as would have been
created in the non-parallel case, although the data will be apportioned
differently. In the parallel case data will be spread equally between the
pipelines.
Reviewed-by: NTim Hudson <tjh@openssl.org>

Reviewed-by: NEmilia Käsper <emilia@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>