There is an overflow bug in the x64_64 Montgomery squaring procedure used in
exponentiation with 512-bit moduli. No EC algorithms are affected. Analysis
suggests that attacks against 2-prime RSA1024, 3-prime RSA1536, and DSA1024 as a
result of this defect would be very difficult to perform and are not believed
likely. Attacks against DH512 are considered just feasible. However, for an
attack the target would have to re-use the DH512 private key, which is not
recommended anyway. Also applications directly using the low level API
BN_mod_exp may be affected if they use BN_FLG_CONSTTIME.

CVE-2019-1551
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/10575)

Ungraceful 'exit' probably causes unexpeced error on background activity.
So replace 'exit' with recommended 'travis_terminate'. Also see
https://travis-ci.community/t/exit-0-cannot-exit-successfully-on-arm/5731/4

Change-Id: I382bd93a3e15ecdf305bab23fc4adefbf0348ffb
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: NShane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10561)

(cherry picked from commit 6df44cf65fbc7e150965149d7e681ac3e22d11d8)

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

(cherry picked from commit 7ba46774b7f1b2e83d44323a8831b615a49f9f37)

Fixes #8941
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10478)

(cherry picked from commit d3a27c5ee45a29edd9c0d60ad5929f67996f89fd)

Issue #8675 describes a problem where calling EVP_DecryptUpdate() with an
empty chunk causes the result to be different compared to if you do not
use an empty chunk. This adds a test for that case.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9057)

Even with custom ciphers, the combination in == NULL && inl == 0
should not be passed down to the backend cipher function.  The reason
is that these are the values passed by EVP_*Final, and some of the
backend cipher functions do check for these to see if a "final" call
is made.

An exception is made for CCM mode which has special handling for the case
where inl == 0: this may mean the total plaintext or ciphertext length is 0.

This is based on an original commit by Richard Levitte.

Fixes #8675
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9057)

It appears that 'sock_timeout' is defined at least with DJGPP, so we
rename our symbol and hope the new name isn't taken.
Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10515)

(cherry picked from commit e9b95e42fbae668cb605287fa462a0d5f58b9caf)

Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10420)

We used EVP_EncryptInit_ex() to initialise, but EVP_DecryptUpdate()
and EVP_DecryptFinal_ex() to actually perform encryption.  This worked
long ago, when the Encrypt and Decrypt variants were the same, but
doesn't now (actually haven't for a very long time).

This shows how seldom PVK is actually used.

Fixes #9338
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/10521)

This replaces doc/HOWTO/proxy_certificates.txt
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10507)

(cherry picked from commit 2a03823606b2d7e73e5dc890c3202e186511151f)

Fixes #10444
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10447)

(cherry picked from commit 72a5412b4858cc7c5627a121f78685a2a4065521)

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

(cherry picked from commit acc7b9fb5c162c2ca522e5e1e09d1efbde8dc6a0)

As was done for ciphers, supported groups, and EC point formats in
https://github.com/openssl/openssl/pull/9162, only write the negotiated
SNI hostname value to the session object when not resuming, even for
TLS 1.3 resumptions.  Otherwise, when using a stateful session cache
(as is done by default when 0-RTT data is enabled), we can have multiple
SSLs active using the same in-memory session object, which leads to
double-frees and similar race conditions in the SNI handler prior
to this commit.

Fortunately, since draft-ietf-tls-tls13-22, there is no requirement
that the SNI hostname be preserved across TLS 1.3 resumption, and thus
not a need to continually update the session object with the "current"
value (to be used when producing session tickets, so that the subsequent
resumption can be checked against the current value).  So we can just
relax the logic and only write to the session object for initial handshakes.
This still leaves us in a somewhat inconsistent state, since if the SNI value
does change across handshakes, the session object will continue to record
the initial handshake's value, even if that bears no relation to the
current handshake.  The current SSL_get_servername() implementation
prefers the value from the session if s->hit, but a more complete fix
for that and related issues is underway in
https://github.com/openssl/openssl/pull/10018; there is no need to wait
for the complete fix for SNI name handling in order to close the
race condition and avoid runtime crashes.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10441)

(cherry picked from commit 2a5385511051d33be8d2b20d7669d8b1862fe510)

Check for NULL and return error if so.
This can possibly be called from apps/ca.c with a NULL argument.
Reviewed-by: NPaul Yang <kaishen.yy@antfin.com>
(Merged from https://github.com/openssl/openssl/pull/10474)

(cherry picked from commit ab5c77b4766e0992751d86560193ca42b49cf316)

Add NULL check for return from pkey_asn1_meths.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10473)

(cherry picked from commit 9bada854de16bcc1a9dc199b4b352b19ab6897fc)

Verifications are public, there is no need to clear the used storage before
freeing it.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10475)

(cherry picked from commit cff7d199e0dc51ae939de5fb7702aab2a9ef30fc)

We store a secondary frame pointer info for the debugger
in the red zone.

Fixes #8853

[extended tests]
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9624)

(cherry picked from commit 9ce91035bcf7d74fe15c94650f3bc1f89b7c0f07)

In addition to 67c81ec3 which introduced this behavior in CCM mode
docs but only implemented it for AES-CCM.
Signed-off-by: NPatrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10331)

(cherry picked from commit f7382fbbd846dd3bdea6b8c03b6af22faf0ab94f)

Conflicts:
	test/recipes/30-test_evp_data/evpciph.txt

Signed-off-by: NPatrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10454)

(cherry picked from commit 97a986f78289fef71bf8778dc4763458e983750c)

Reviewed-by: NPaul Dale <paul.dale@oracle.com>
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/10388)

(cherry picked from commit 2555285fa5e4248ad4a5a0bc14ae4606443856c2)

Signed-off-by: NPatrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10446)

(cherry picked from commit 985412f8c14853b9936852bc7ef4d9438db27b88)

Avoid conflicts with some linkers.
Signed-off-by: NPatrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10439)

(cherry picked from commit e74b5dcf16dfd7c91d9f9a7e69c447f00d778e17)

Conflicts:
	test/build.info

Signed-off-by: NJoerg Schmidbauer <jschmidb@de.ibm.com>
Reviewed-by: NPatrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10417)

(cherry picked from commit c31950b964a2f3f7b9e6ad98076954178ee1e77d)

Add more explicit documentation about the relation between
EC_POINT_point2oct(), EC_POINT_point2hex(), EC_POINT_point2bn() and
their reverse.

In particular highlight that EC_POINT_point2oct() and
EC_POINT_oct2point() conform to, respectively, Sec. 2.3.3 and Sec. 2.3.4
of the SECG SEC 1 standard (which is the normative reference for the
already mentioned RFC 5480), highlighting with a note how this affect
the encoding/decoding of the point at infinity (which in contrast with
any other valid generic point of a curve is assigned an exceptional
fixed octet string encoding, i.e., 0x00).
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10329)

(cherry picked from commit 3cc26f2eba8a8c16ac559e68c05c094d7ea6bd8b)

Adds tests for each curve to ensure that encodings obtained through
EC_POINT_hex2point() can be fed to EC_POINT_point2hex() yielding a point
identical to the one from which the encoding is generated.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10329)

(cherry picked from commit 35ed029b5a488924890fda2487c87f664361a33b)

EC_POINT_bn2point() rejected BIGNUMs with a zero value.

This behavior indirectly caused failures when converting a point
at infinity through EC_POINT_point2hex() and then back to a point with
EC_POINT_hex2point().

With this change such BIGNUMs are treated like any other and exported to
an octet buffer filled with zero.
It is then EC_POINT_oct2point() (either the default implementation or
the custom one in group->meth->oct2point) to determine if such encoding
maps to a valid point (generally the point at infinity is encoded as
0x00).

Fixes #10258
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10329)

(cherry picked from commit d47c10875656790d146f62ac3c437db54c58dbf7)

https://github.com/openssl/openssl/issues/10224#issuecomment-546593113
highlighted that existing testing infrastructure is not covering common
usage patterns of the `req` app.

This commit explicitly adds request generations thorugh the CLI using
RSA, DSA and ECDSA (P-256) keys.

(cherry picked from commit b2a7310af0dd190712bae2e462a7708483dd4628)
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10369)

This also removes the incorrect documentation comments by those
functions.
Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10403)

The resumption_label variable when CHARSET_EBCDIC was enabled, was misspelled.
Instead of evaluating to 'res binder' as expected, it evaluated to 'red binder'.

CLA: trivial
Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/10396)

(cherry picked from commit 6ed12cec7216c3e81b58f5cafa41775e456feaee)

Many Windows-based GOST TLS implementations are unable to extend the
list of supported SignatureAlgorithms because of lack of the necessary
callback in Windows. So for TLS 1.2 it makes sense to imply the support
of GOST algorithms in case when the GOST ciphersuites are present.

This is a backport of #10377 to 1.1.1 branch
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10378)

Appease -Wstring-plus-int.
Signed-off-by: NPatrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/9608)

(cherry picked from commit e0249827b3fa81ff6c59fb14ef85d38361dd5e31)

'__builtin_strncpy' offset [275, 4095] from the object at
'direntry' is out of the bounds of referenced subobject 'd_name'
with type 'char[256]' at offset 19
Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10343)

(cherry picked from commit db5cf86535b305378308c58c52596994e1ece1e6)

Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/10361)

(cherry picked from commit d1c1fb2d41a627293483d832aaffcb6eca9075f9)

We also add this to our x86_64 builds on appveyor

(cherry picked from commit b4a7b4ec4acc712b1f22a83966ac986b510f25d8)
Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10365)

If no connection could be made, addr_iter will eventually end up being
NULL, and if the user didn't check the returned error value, the
BIO_CONN_S_CONNECT code will be performed again and will crash.

So instead, we add a state BIO_CONN_S_CONNECT_ERROR that we enter into
when we run out of addresses to try.  That state will just simply say
"error" back, until the user does something better with the BIO, such
as free it or reset it.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10333)

i2v_GENERAL_NAMES call i2v_GENERAL_NAME repeatedly as required. Each
time i2v_GENERAL_NAME gets called it allocates adds data to the passed in
stack and then returns a pointer to the stack, or NULL on failure. If
the passed in stack is itself NULL then it allocates one.

i2v_GENERAL_NAMES was not correctly handling the case where a NULL gets
returned from i2v_GENERAL_NAME. If a stack had already been allocated then
it just leaked it.
Reviewed-by: NDmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10300)

(cherry picked from commit 45b244620a74248b46ebe1c85e86437b9641447a)

clang imposes some restrictions on the assembler code that
gcc does not.
Signed-off-by: NPatrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10330)

(cherry picked from commit 6f93f06135cbbd36c3fe98d63717e8303a5d559b)

Conflicts:
	crypto/perlasm/s390x.pm (non-existant)
	crypto/s390xcpuid.pl (code to be changed non-existant)

This system services is based on FreeBSD 12's getentropy(), and is
therefore treated the same way as getentropy() with regards to amount
of entropy bits per data bit.
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8926)

(cherry picked from commit 8b9896eb293a0861f0b8c191b7a278f176b729e6)

Signed-off-by: NChristian Heimes <christian@python.org>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6553)

(cherry picked from commit 132b5facf8d681db5dfa45828d8b02f1bf5df64b)

Signed-off-by: NPatrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10311)

(cherry picked from commit 351ba5bd27645d5b5a2bc643b2709bd30bcdf09c)