Problem was that Windows threads that were terminating before libcrypto
was initialized were referencing uninitialized or possibly even
unrelated thread local storage index.
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/6752)
This is done by calling die again, just make sure to reset the __DIE__
handler first.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6776)
A number intended to treat the base as secret should not be branching on
whether it is zero. Test-wise, this is covered by existing tests in bnmod.txt.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6733)
On the same note, change the 'NASM not found' message to give specific
advice on how to handle the failure.
Fixes#6765
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6771)
asn1_encode : x, y => 0 | x，0 | y
(because of DER encoding rules when x and y have high bit set)
CLA: Trivial
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6694)
If there's anything in the |biosk| stack, the first element is always
the input BIO. It should never be freed in this function, so we must
take careful steps not to do so inadvertently when freeing the stack.
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/6769)
The result is that we don't have to produce different names on
different platforms, and we won't have confusion on Windows depending
on if the script was built with mingw or with MSVC.
Partial fix for #3254
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6764)
In some circumstances it is possible for a client to have a session
reporting a max early data value that is greater than the server will
support. In such cases the client could encounter an aborted connection.
Fixes#6735
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/6740)
ecp_nistz256_set_from_affine is called when application attempts to use
custom generator, i.e. rarely. Even though it was wrong, it didn't
affect point operations, they were just not as fast as expected.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6738)
The ecp_nistz256_scatter_w7 function is called when application
attempts to use custom generator, i.e. rarely. Even though non-x86_64
versions were wrong, it didn't affect point operations, they were just
not as fast as expected.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6738)
The API used to set what SNI value to send in the ClientHello
can also be used on server SSL objects, with undocumented and
un-useful behavior. Unfortunately, when generic SSL_METHODs
are used, s->server is still set, prior to the start of the
handshake, so we cannot prevent this nonsensical usage at the
present time. Leave a note to revisit this when ABI-breaking
changes are permitted.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6378)
In particular, adhere to the rule that we must not modify any
property of an SSL_SESSION object once it is (or might be) in
a session cache. Such modifications are thread-unsafe and have
been observed to cause crashes at runtime.
To effect this change, standardize on the property that
SSL_SESSION->ext.hostname is set only when that SNI value
has been negotiated by both parties for use with that session.
For session resumption this is trivially the case, so only new
handshakes are affected.
On the client, the new semantics are that the SSL->ext.hostname is
for storing the value configured by the caller, and this value is
used when constructing the ClientHello. On the server, SSL->ext.hostname
is used to hold the value received from the client. Only if the
SNI negotiation is successful will the hostname be stored into the
session object; the server can do this after it sends the ServerHello,
and the client after it has received and processed the ServerHello.
This obviates the need to remove the hostname from the session object
in case of failed negotiation (a change that was introduced in commit
9fb6cb810b in order to allow TLS 1.3
early data when SNI was present in the ClientHello but not the session
being resumed), which was modifying cached sessions in certain cases.
(In TLS 1.3 we always produce a new SSL_SESSION object for new
connections, even in the case of resumption, so no TLS 1.3 handshakes
were affected.)
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6378)
These tiny functions only read from the input SSL, and we are
about to use them from functions that only have a const SSL* available,
so propagate const a bit further.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6378)
The spec says that a client MUST set legacy_version to TLSv1.2, and
requires servers to verify that it isn't SSLv3.
Fixes#6600
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6747)
Originally suggested solution for "Return Of the Hidden Number Problem"
is arguably too expensive. While it has marginal impact on slower
curves, none to ~6%, optimized implementations suffer real penalties.
Most notably sign with P-256 went more than 2 times[!] slower. Instead,
just implement constant-time BN_mod_add_quick.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: David Benjamin <davidben@google.com>
(Merged from https://github.com/openssl/openssl/pull/6664)
It was false positive, but one can as well view it as readability issue.
Switch even to unsigned indices because % BN_BYTES takes 4-6 instructions
with signed dividend vs. 1 (one) with unsigned.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Using the rsa_pss_rsae_sha256 sig alg should imply that the key OID is
rsaEncryption. Similarly rsa_pss_pss_sha256 implies the key OID is
rsassaPss. However we did not check this and incorrectly tolerated a key
OID that did not match the sig alg sent by the peer.
Fixes#6611
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6732)
The GOST ciphers are dynamically loaded via the GOST engine, so we must
be able to support that. The engine also uses DSA and CMS symbols, so we
skip the test on no-dsa or no-cms.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6730)
