Age | Commit message (Collapse) | Author |
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7671)
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/7667)
|
|
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7665)
|
|
dsa_builtin_paramgen2 expects the L parameter to be greater than N,
otherwise the generation will get stuck in an infinite loop.
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(cherry picked from commit 3afd38b277a806b901e039c6ad281c5e5c97ef67)
(Merged from https://github.com/openssl/openssl/pull/7493)
|
|
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/7593)
|
|
Fixes #3302
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7606)
|
|
Since 3884b47b7c we may attempt to buffer a record from the next epoch
that has already been buffered. Prior to that this never occurred.
We simply ignore a failure to buffer a duplicated record.
Fixes #6902
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7415)
|
|
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7549)
(cherry picked from commit 00496b6423605391864fbbd1693f23631a1c5239)
|
|
There is a side channel attack against the division used to calculate one of
the modulo inverses in the DSA algorithm. This change takes advantage of the
primality of the modulo and Fermat's little theorem to calculate the inverse
without leaking information.
Thanks to Samuel Weiser for finding and reporting this.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7512)
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7513)
|
|
Previously, the RNG sets `initialized=1` after the first call to
RAND_poll(), although its criterion for being initialized actually
is whether condition `entropy >= ENTROPY_NEEDED` is true.
This commit now assigns `initialized=(entropy >= ENTROPY_NEEDED)`,
which has the effect that on the next call, RAND_poll() will be
called again, if it previously failed to obtain enough entropy.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7439)
|
|
Also, some readers of the code find starting the count at 1 for EE
cert confusing (since RFC5280 counts only non-self-issued intermediate
CAs, but we also counted the leaf). Therefore, never count the EE
cert, and adjust the path length comparison accordinly. This may
be more clear to the reader.
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit dc5831da59e9bfad61ba425d886a0b06ac160cd6)
|
|
At the bottom of https://tools.ietf.org/html/rfc5280#page-12 and
top of https://tools.ietf.org/html/rfc5280#page-13 (last paragraph
of above https://tools.ietf.org/html/rfc5280#section-3.3), we see:
This specification covers two classes of certificates: CA
certificates and end entity certificates. CA certificates may be
further divided into three classes: cross-certificates, self-issued
certificates, and self-signed certificates. Cross-certificates are
CA certificates in which the issuer and subject are different
entities. Cross-certificates describe a trust relationship between
the two CAs. Self-issued certificates are CA certificates in which
the issuer and subject are the same entity. Self-issued certificates
are generated to support changes in policy or operations. Self-
signed certificates are self-issued certificates where the digital
signature may be verified by the public key bound into the
certificate. Self-signed certificates are used to convey a public
key for use to begin certification paths. End entity certificates
are issued to subjects that are not authorized to issue certificates.
that the term "self-issued" is only applicable to CAs, not end-entity
certificates. In https://tools.ietf.org/html/rfc5280#section-4.2.1.9
the description of path length constraints says:
The pathLenConstraint field is meaningful only if the cA boolean is
asserted and the key usage extension, if present, asserts the
keyCertSign bit (Section 4.2.1.3). In this case, it gives the
maximum number of non-self-issued intermediate certificates that may
follow this certificate in a valid certification path. (Note: The
last certificate in the certification path is not an intermediate
certificate, and is not included in this limit. Usually, the last
certificate is an end entity certificate, but it can be a CA
certificate.)
This makes it clear that exclusion of self-issued certificates from
the path length count applies only to some *intermediate* CA
certificates. A leaf certificate whether it has identical issuer
and subject or whether it is a CA or not is never part of the
intermediate certificate count. The handling of all leaf certificates
must be the same, in the case of our code to post-increment the
path count by 1, so that we ultimately reach a non-self-issued
intermediate it will be the first one (not zeroth) in the chain
of intermediates.
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit ed422a2d0196ada0f5c1b6e296f4a4e5ed69577f)
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/7123)
(cherry picked from commit d1c008f66bad435b18aa45aa59f72bed7c682849)
|
|
While reviewing last modification in GH#6261 Richard actually spotted
the inconsistency, but withdrew the remark, correct one in aftermath...
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7298)
|
|
It appears that, in FIPS mode, `ec_precompute_mont_data()` always failed
but the error was ignored until commit e3ab8cc from #6810.
The actual problem lies in the fact that access to the `mont_data` field
of an `EC_GROUP` struct should always be guarded by an
`EC_GROUP_VERSION(group)` check to avoid OOB accesses, because `group`
might come from the FIPS module, which does not define the `mont_data`
field inside the EC_GROUP structure.
This commit adds the required check before any access to
`group->mont_data` in `EC_GROUP_set_generator()`.
Fixes #7127
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/7135)
|
|
Manual merge of #7047 to 1.0.2-stable.
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/7300)
|
|
Fixes #7228
The function BIO_get_host_ip uses gethostbyname, which is not thread safe
and hence we grab a lock. In multi-threaded applications, this lock sometimes
causes performance bottlenecks.
This patch uses the function gethostbyname_r (thread safe version), when
available.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7250)
|
|
This commit documents the OPENSSL_VERSION_TEXT which is currently
missing in the man page.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7301)
(cherry picked from commit 7c69495712e3dc9aa8db38271f0c3faeb2037165)
|
|
This module includes bn.h via other headers, so it picks up the
definition from there and doesn't need to define them locally (any
more?). Worst case scenario, the redefinition may be different and
cause all sorts of compile errors.
Fixes #7227
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/7287)
(cherry picked from commit dda5396aaec315bdbcb080e42fb5cd0191f2ad72)
|
|
Fixes #7240
In FIPS mode, the default FIPS DRBG uses the drbg_get_entropy()
callback to reseed itself, which is provided by the wrapping
libcrypto library. This callback in turn uses ssleay_rand_bytes()
to generate random bytes.
Now ssleay_rand_bytes() calls RAND_poll() once on first call to
seed itself, but RAND_poll() is never called again (unless the
application calls RAND_poll() explicitely). This implies that
whenever the DRBG reseeds itself (which happens every 2^14
generate requests) this happens without obtaining fresh random
data from the operating system's entropy sources.
This patch forces a reseed from system entropy sources on every
call to drbg_get_entropy(). In contrary to the automatic reseeding
of the DRBG in master, this reseeding does not break applications
running in a chroot() environment (see c7504aeb640a), because the
SSLEAY PRNG does not maintain an error state. (It does not even
check the return value of RAND_poll() on its instantiation.)
In the worst case, if no random device is available for reseeding,
no fresh entropy will be added to the SSLEAY PRNG but it will happily
continue to generate random bytes as 'entropy' input for the DRBG's
reseeding, which is just as good (or bad) as before this patch.
To prevent ssleay_rand_bytes_from_system() (and hence RAND_poll())
from being called twice during instantiation, a separate
drbg_get_nonce() callback has been introduced, which is identical
with the previous implementation of drbg_get_entropy().
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/7259)
|
|
These both indicate that the file descriptor we're trying to use as a
terminal isn't, in fact, a terminal.
Fixes #7271
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/7272)
(cherry picked from commit 276bf8620ce35a613c856f2b70348f65ffe94067)
(cherry picked from commit ad1730359220cef5903d16c7f58b602fc3713414)
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7166)
(cherry picked from commit e13dc23cc0fd64c304c25a67d5fa516a77f9e8f1)
|
|
Since the SSL code started using RSA_NO_PADDING, the CAPI engine became
unusable. This change fixes that.
Fixes #7131
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7132)
|
|
Found by Coverity
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7169)
(cherry picked from commit 512d811719fc955f574090af4c3586a9aba46fa7)
|
|
With the introduction of -pkeyopt, the number of bits may change
without |newkey| being updated. Unfortunately, there is no API to
retrieve the information from a EVP_PKEY_CTX either, so chances are
that we report incorrect information. For the moment, it's better not
to try to report the number of bits at all.
Fixes #7086
Reviewed-by: Paul Yang <yang.yang@baishancloud.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7096)
(cherry picked from commit 17147181bd3f97c53592e2a5c9319b854b954039)
|
|
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7112)
|
|
They did not make it clear how the memory management works for the |pctx|
parameter.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7043)
|
|
The default input format is PEM, so explicit "-inform DER" is needed to
read DER-encoded CRL.
CLA: trivial
Reviewed-by: Paul Yang <yang.yang@baishancloud.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7094)
(cherry picked from commit 785e614a95a134831f213749332bcf40c4920f69)
(cherry picked from commit e25fc6b5b2b99ed02f8966192c94c820b6f69add)
|
|
Just remove that statement. It's not been true since 2005.
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/6906)
|
|
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7088)
(cherry picked from commit 6bcfcf16bf6aef4f9ec267d8b86ae1bffd8deab9)
|
|
This trivial patch removes a duplicated call to ASN1_INTEGER_set.
Fixes Issue #6977
Signed-off-by: Eric Brown <browne@vmware.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/6984)
(cherry picked from commit 59701e6363531cddef5b2114c0127b8453deb1f3)
|
|
(cherry picked from commit 324b95605225410763fe63f7cff36eb46ca54ee9)
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/6942)
|
|
(cherry picked from commit e02c519cd32a55e6ad39a0cfbeeda775f9115f28)
Resolved conflicts:
crypto/bn/bn_blind.c
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/6942)
|
|
In [most common] case of p and q being of same width, it's possible to
replace CRT modulo operations with Montgomery reductions. And those are
even fixed-length Montgomery reductions...
(cherry picked from commit 41bfd5e7c8ac3a0874a94e4d15c006ad5eb48e59)
Resolved conflicts:
crypto/rsa/rsa_eay.c
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/6942)
|
|
Add bn_mul_fixed_top, bn_from_mont_fixed_top, bn_mod_sub_fixed_top.
Switch to bn_{mul|sqr}_fixed_top in bn_mul_mont_fixed_top and remove
memset in bn_from_montgomery_word.
(cherry picked from commit fcc4ee09473cac511eca90faa003661c7786e4f9)
Resolved conflicts:
crypto/bn/bn_mod.c
crypto/bn_int.h
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/6942)
|
|
the option is provided in the -help message of the s_server utility
but it is not documented in the man page, this fixes it
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Yang <yang.yang@baishancloud.com>
(Merged from https://github.com/openssl/openssl/pull/7046)
|
|
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6916)
(cherry picked from commit 0da7358b0757fa35f2c3a8f51fa036466ae50fd7)
Resolved conflicts:
crypto/x509v3/v3_purp.c
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6957)
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6955)
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6951)
|
|
Just as was done recently for i2d_ASN1_OBJECT, we also make
i2d_ASN1_BOOLEAN comply with the documentation.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6943)
|
|
Since 0.9.7, all i2d_ functions were documented to allocate an output
buffer if the user didn't provide one, under these conditions (from
the 1.0.2 documentation):
For OpenSSL 0.9.7 and later if B<*out> is B<NULL> memory will be
allocated for a buffer and the encoded data written to it. In this
case B<*out> is not incremented and it points to the start of the
data just written.
i2d_ASN1_OBJECT was found not to do this, and would crash if a NULL
output buffer was provided.
Fixes #6914
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/6918)
(cherry picked from commit 6114041540d8d1fecaf23a861788c3c742d3b467)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6889)
(cherry picked from commit 582ad5d4d9b7703eb089016935133e3a18ea8205)
Resolved conflicts:
crypto/rsa/rsa_ossl.c
crypto/rsa/rsa_pk1.c
|
|
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>
(Merged from https://github.com/openssl/openssl/pull/6889)
(cherry picked from commit 83e034379fa3f6f0d308ec75fbcb137e26154aec)
|
|
"Computationally constant-time" means that it might still leak
information about input's length, but only in cases when input
is missing complete BN_ULONG limbs. But even then leak is possible
only if attacker can observe memory access pattern with limb
granularity.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6889)
(cherry picked from commit 89d8aade5f4011ddeea7827f08ec544c914f275a)
Resolved conflicts:
crypto/bn/bn_lib.c
|