In TLS we have a check to make sure an incoming reneg ClientHello is
acceptable. The equivalent check is missing in the DTLS code. This means
that if a client does not signal the ability to handle secure reneg in the
initial handshake, then a subsequent reneg handshake should be rejected by
the server. In the DTLS case the reneg was being allowed if the the 2nd
ClientHello had a renegotiation_info extension. This is incorrect.

While incorrect, this does not represent a security issue because if
the renegotiation_info extension is present in the second ClientHello it
also has to be *correct*. Therefore this will only work if both the client
and server believe they are renegotiating, and both know the previous
Finished result. This is not the case in an insecure rengotiation attack.

I have also tidied up the check in the TLS code and given a better check
for determining whether we are renegotiating or not.

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

Thanks to Yun Jiang for pointing this out.

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5164)

Backport from https://github.com/openssl/openssl/pull/5141



Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/5151)

(cherry picked from commit 8b2124ab)

Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5142)

(cherry picked from commit a26dd465)

Updated uses of gmtime to now call OPENSSL_gmtime instead.

Used similar preprocessor logic to make sure localtime_r is called instead
of localtime when applicable.

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3609)

If tlsext ticket decrypt callback returns error, cleanup ctxs

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3273)

CLA: trivial

Signed-off-by: Cristian Stoica <cristian.stoica@nxp.com>

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1449)

CLA: trivial

Signed-off-by: Cristian Stoica <cristian.stoica@nxp.com>

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1449)

An index.txt entry which has an empty Subject name field will cause ca
to crash. Therefore check it when we load it to make sure its not empty.

Fixes #5109

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

Misconfiguration (e.g. an empty policy section in the config file) can
lead to an empty Subject. Since certificates should have unique Subjects
this should not be allowed.

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

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

(cherry picked from commit 7c24f9d2)

Commit 9f944291

 changed the semantics of BN_copy() to additionally
copy the BN_FLG_CONSTTIME flag if it is set. This turns out to be
ill advised as it has unintended consequences. For example calling
BN_mod_inverse_no_branch() can sometimes return a result with the flag
set and sometimes not as a result. This can lead to later failures if we
go down code branches that do not support constant time, but check for
the presence of the flag.

The original commit was made due to an issue in BN_MOD_CTX_set(). The
original PR fixed the problem in that function, but it was changed in
review to fix it in BN_copy() instead. The solution seems to be to revert
the BN_copy() change and go back to the originally proposed way.

Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/5080)

(cherry picked from commit 7d461736)

In the case of a protocol version alert being sent by a peer the record
version number may not be what we are expecting. In DTLS records with an
unexpected version number are silently discarded. This probably isn't
appropriate for alerts, so we tolerate a mismatch in the minor version
number.

This resolves an issue reported on openssl-users where an OpenSSL server
chose DTLS1.0 but the client was DTLS1.2 only and sent a protocol_version
alert with a 1.2 record number. This was silently ignored by the server.

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5019)

Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/4906)
(cherry picked from commit 794bf5f7)

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

Thanks to Douglas Fyfe @ VSI for making me aware of this

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

A backport of #4997.
Fixes #4996.

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/5020)

Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/4974)

(cherry picked from commit 8af7e94d)

Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Paul Dale <paul.dale@oracle.com>

Also documented X509_V_FLAG_TRUSTED_FIRST

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

SSL_trace() has a case which was inadvertently falling through.

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4888)

(cherry picked from commit 5bfb357a)

Looking for 'gcc' and 'clang' in the output from the C compiler is
uncertain.  Some versions report argv[0], which might be /usr/bin/cc
(for example), and others might mention gcc without being gcc or a
derivate.

Better then to fetch predefined macros and checking if __GNUC__ and
__clang__ are defined.

Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4755)

They are from the 1.1.0 or master branches

Fixes #4863

Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4887)

Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4875)

Pointer 'o' is set inside a local buffer, so it can't be NULL.
Also fix coding style and add comments

Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4754)
(cherry picked from commit cef115ff)

Some compilers react badly to non-ASCII characters

Fixes #4877

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4879)

Fixes #2533

The call to FIPS_crypto_set_id_callback() was added in revision a43cfd7b

,
but there is no prototype for it in <openssl/fips.h>.

Signed-off-by: Dr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4870)

Fixes #4865

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

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

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

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

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

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

Test reading/writing to an SSL object after a fatal error has been
detected.

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

OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an "error state"
mechanism. The intent was that if a fatal error occurred during a handshake
then OpenSSL would move into the error state and would immediately fail if
you attempted to continue the handshake. This works as designed for the
explicit handshake functions (SSL_do_handshake(), SSL_accept() and
SSL_connect()), however due to a bug it does not work correctly if
SSL_read() or SSL_write() is called directly. In that scenario, if the
handshake fails then a fatal error will be returned in the initial function
call. If SSL_read()/SSL_write() is subsequently called by the application
for the same SSL object then it will succeed and the data is passed without
being decrypted/encrypted directly from the SSL/TLS record layer.

In order to exploit this issue an attacker would have to trick an
application into behaving incorrectly by issuing an SSL_read()/SSL_write()
after having already received a fatal error.

Thanks to David Benjamin (Google) for reporting this issue and suggesting
this fix.

CVE-2017-3737

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

Credit to OSS-Fuzz for finding this.

CVE-2017-3738

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

This line will allow use private keys, which created by Crypto Pro, to
sign with OpenSSL.

CLA: trivial

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4836)

(cherry picked from commit b35bb37a)

Fixes #4775

Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4815)

(cherry picked from commit a61c15eb)

Backport of #4677 / 1687aa76



Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4715)

Fixes #4734 #4649

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4735)