Can't hurt and seems to prevent problems from some over-aggressive
(LTO?) compilers.

Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 98ab5764)

Reviewed-by: Andy Polyakov <appro@openssl.org>

Add tests for have_precompute_mult for the optimised curves (nistp224,
nistp256 and nistp521) if present

Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 8ce4e7e6)

During precomputation if the group given is well known then we memcpy a
well known precomputation. However we go the wrong label in the code and
don't store the data properly. Consequently if we call have_precompute_mult
the data isn't there and we return 0.

RT#3600

Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 615614c8)

The function DH_check_pub_key() was missing some return value checks in
some calls to BN functions.

RT#4278

Reviewed-by: Andy Polyakov <appro@openssl.org>
(cherry picked from commit f5a12207)

A new return value for DH_check_pub_key was recently added:
DH_CHECK_PUBKEY_INVALID. As this is a flag which can be ORed with other
return values it should have been set to the value 4 not 3.

RT#4278

Reviewed-by: Andy Polyakov <appro@openssl.org>
(cherry picked from commit cb389fe8)

Reviewed-by: Viktor Dukhovni <openssl-users@dukhovni.org>

Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 41a28cb2)

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

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

Add details about the latest issues into CHANGES and NEWS ready for the
next release.

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

Following on from the previous commit, add a test to ensure that
DH_compute_key correctly fails if passed a bad y such that:

y^q (mod p) != 1

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

Modified version of the commit ffaef3f1

 in the master branch by Stephen
Henson. This makes the SSL_OP_SINGLE_DH_USE option a no-op and always
generates a new DH key for every handshake regardless.

CVE-2016-0701 (fix part 2 or 2)

Issue reported by Antonio Sanso

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

Historically OpenSSL only ever generated DH parameters based on "safe"
primes. More recently (in version 1.0.2) support was provided for
generating X9.42 style parameter files such as those required for RFC
5114 support. The primes used in such files may not be "safe". Where an
application is using DH configured with parameters based on primes that
are not "safe" then an attacker could use this fact to find a peer's
private DH exponent. This attack requires that the attacker complete
multiple handshakes in which the peer uses the same DH exponent.

A simple mitigation is to ensure that y^q (mod p) == 1

CVE-2016-0701 (fix part 1 of 2)

Issue reported by Antonio Sanso.

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

Based on patch by: Nimrod Aviram <nimrod.aviram@gmail.com>

CVE-2015-3197

Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit dd67493c)

Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>

Calling SSL_shutdown while in init previously gave a "1" response, meaning
everything was successfully closed down (even though it wasn't). Better is
to send our close_notify, but fail when trying to receive one.

The problem with doing a shutdown while in the middle of a handshake is
that once our close_notify is sent we shouldn't really do anything else
(including process handshake/CCS messages) until we've received a
close_notify back from the peer. However the peer might send a CCS before
acting on our close_notify - so we won't be able to read it because we're
not acting on CCS messages!

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

For BSD systems, Configure adds a shared_ldflags including a reference
to the Makefile variable LIBRPATH, but since it must be passed down to
Makefile.shared, care must be taken so the value of LIBRPATH doesn't
get expanded too early, or it ends up giving an empty string.

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(cherry picked from commit c64879d3)

RT#4080

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>

Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 02f70372)

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>

While empty inputs to SSL_set1_host() clear the reference identifier
list.

(cherry-picked from 1.1.0-dev)

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

    - bugfix: should not treat '--' as invalid domain substring.
    - '-' should not be the first letter of a domain

Signed-off-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(cherry picked from commit 9aa00b18)

Conflicts:
	apps/x509.c

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>

Error in the definition of the macro SSL_set1_sigalgs(ctx, slist,
slistlen): the third parameter 'slistlen' not used in the substitution
code; used 'clistlen' instead. As a result of this, compilation error
occurs when any application uses this macro.

Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@openssl.org>

Reviewed-by: Viktor Dukhovni <openssl-users@dukhovni.org>

Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
(cherry picked from commit 1918e01c)

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

Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 41977c53)

Describe the usage of the OCSP callback functions on both the client and
the server side.

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

It makes no sense to call the OCSP status callback if we are resuming a
session because no certificates will be sent.

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

If a server sends the status_request extension then it may choose
to send the CertificateStatus message. However this is optional.
We were treating it as mandatory and the connection was failing.

Thanks to BoringSSL for reporting this issue.

RT#4120

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