Having received a ClientKeyExchange message instead of a Certificate we
know that we are not going to receive a CertificateVerify message. This
means we can free up the handshake_buffer. However we better call
ssl3_digest_cached_records() instead of just freeing it up, otherwise we
later try and use it anyway and a core dump results. This could happen,
for example, in SSLv3 where we send a CertificateRequest but the client
sends no Certificate message at all. This is valid in SSLv3 (in TLS
clients are required to send an empty Certificate message).

Found using the BoringSSL test suite.

Reviewed-by: Emilia Käsper <emilia@openssl.org>

In TLS if the server sends a CertificateRequest and the client does not
provide one, if the server cannot continue it should send a
HandshakeFailure alert. In SSLv3 the same should happen, but instead we
were sending an UnexpectedMessage alert. This is incorrect - the message
isn't unexpected - it is valid for the client not to send one - its just
that we cannot continue without one.

Reviewed-by: Emilia Käsper <emilia@openssl.org>

In TLS during ClientAuth if the CA is not recognised you should get an
UnknownCA alert. In SSLv3 this does not exist and you should get a
BadCertificate alert.

Reviewed-by: Emilia Käsper <emilia@openssl.org>

The Client Auth tests were not correctly setting the Protocol, so that this
aspect had no effect. It was testing the same thing lots of times for
TLSv1.2 every time.

Reviewed-by: Emilia Käsper <emilia@openssl.org>

Move the preparation of the client certificate to be post processing work
after reading the CertificateRequest message rather than pre processing
work prior to writing the Certificate message. As part of preparing the
client certificate we may discover that we do not have one available. If
we are also talking SSLv3 then we won't send the Certificate message at
all. However, if we don't discover this until we are about to send the
Certificate message it is too late and we send an empty one anyway. This
is wrong for SSLv3.

Reviewed-by: Emilia Käsper <emilia@openssl.org>

Mingw builds on Travis were failing because INT_MAX was undeclared.

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

The i2d_SCT_LIST function is declared as __owur, therefore we need to check
the result or a --strict-warnings build will fail.

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

and short-input performance.

[Fix bug in misaligned output handling.]

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

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

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

[Also optimize aligaddr usage in single-block subroutines.]

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

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

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

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

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

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

Instead of having fuzz/build.info.fuzz magically and conditionally
included along with the other build.info files, incorporate it in
fuzz/build.info and add the conditions there instead.

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

Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1313)

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

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

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

RT#4611

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

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

With a number of tools, especially those coming with Visual Studio,
some command options are separated from their argument with a space,
others with a space.  Since we parametrise them, we can't know
beforehand which it will be, so we must allow the input and output
options to have either.

However, spaces at the end of nmake macro values are trimmed, so allow
spaces to exist by adding a reference to an undefined macro at the end.

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

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

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

This is only done for the platforms where 'OPENSSL_USE_APPLINK' is defined.

Also, change the docs of OPENSSL_Applink to say where to find applink.c
in the installation directory.

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

The easiest way to take care of manifest files is to integrate them
into the associated binary (.exe or .dll).  MT (the Manifest Tool) is
the utility to use for this.

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

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

RT#4605

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

The set0 setters take ownership of their arguments, so the values should
be set to NULL to avoid a double-free in the cleanup block should
ssl_security(SSL_SECOP_TMP_DH) fail. Found by BoringSSL's WeakDH test.

Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1299)

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

In light of potential UKS (unknown key share) attacks on some
applications, primarily browsers, despite RFC761, name checks are
by default applied with DANE-EE(3) TLSA records.  Applications for
which UKS is not a problem can optionally disable DANE-EE(3) name
checks via the new SSL_CTX_dane_set_flags() and friends.

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

subject alternate names.

Add nameConstraints tests incluing DNS, IP and email tests both in
subject alt name extension and subject name.

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

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

New hostname checking function asn1_valid_host()

Check commonName entries against nameConstraints: any CN components in
EE certificate which look like hostnames are checked against
nameConstraints.

Note that RFC5280 et al only require checking subject alt name against
DNS name constraints.

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

With no-deprecated, some nested includes don't happen by default.

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

With OpenSSL 1.1 and on, the engines are tightly tied to the shared
library they're to be used with.  That makes them depend on the
pointer size as well as the shared library version, and this gets
reflected in the name of the directory they're installed in.

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

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

We're installing architecture dependent (compiled) programs in
architecture specific directories, while architecture independent
programs (scripts) get installed in the general programs directory.
OSSL$EXE: reflects that by having two values.

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