The X509_NAME comparison function converts its arguments to DER using
i2d_X509_NAME before comparing the results using memcmp(). For every
invocation of the comparison function (of which there are many when
loading many certificates), it allocates two buffers of the appropriate
size for the DER encoding.
Switching to static buffers (possibly of X509_NAME_MAX size as defined
in crypto/x509/x_name.c) would not work with multithreaded use, e.g.,
when two threads sort two separate STACK_OF(X509_NAME)s at the same
time. A suitable re-usable buffer could have been added to the
STACK_OF(X509_NAME) if sk_X509_NAME_compfunc did have a void* argument,
or a pointer to the STACK_OF(X509_NAME) – but it does not.
Instead, copy the solution chosen in SSL_load_client_CA_file() by
filling an LHASH_OF(X509_NAME) with all existing names in the stack and
using that to deduplicate, rather than relying on sk_X509_NAME_find(),
which ends up being very slow.
Adjust SSL_add_dir_cert_subjects_to_stack() to keep a local
LHASH_OF(X509_NAME)s over the complete directory it is processing.
In a small benchmark that calls SSL_add_dir_cert_subjects_to_stack()
twice, once on a directory with one entry, and once with a directory
with 1000 certificates, and repeats this in a loop 10 times, this change
yields a speed-up of 5.32:
| Benchmark 1: ./bench 10 dir-1 dir-1000
| Time (mean ± σ): 6.685 s ± 0.017 s [User: 6.402 s, System: 0.231 s]
| Range (min … max): 6.658 s … 6.711 s 10 runs
|
| Benchmark 2: LD_LIBRARY_PATH=. ./bench 10 dir-1 dir-1000
| Time (mean ± σ): 1.256 s ± 0.013 s [User: 1.034 s, System: 0.212 s]
| Range (min … max): 1.244 s … 1.286 s 10 runs
|
| Summary
| LD_LIBRARY_PATH=. ./bench 10 dir-1 dir-1000 ran
| 5.32 ± 0.06 times faster than ./bench 10 dir-1 dir-1000
In the worst case scenario where many entries are added to a stack that
is then repeatedly used to add more certificates, and with a larger test
size, the speedup is still very significant. With 15000 certificates,
a single pass to load them, followed by attempting to load a subset of
1000 of these 15000 certificates, followed by a single certificate, the
new approach is ~85 times faster:
| Benchmark 1: ./bench 1 dir-15000 dir-1000 dir-1
| Time (mean ± σ): 176.295 s ± 4.147 s [User: 174.593 s, System: 0.448 s]
| Range (min … max): 173.774 s … 185.594 s 10 runs
|
| Benchmark 2: LD_LIBRARY_PATH=. ./bench 1 dir-15000 dir-1000 dir-1
| Time (mean ± σ): 2.087 s ± 0.034 s [User: 1.679 s, System: 0.393 s]
| Range (min … max): 2.057 s … 2.167 s 10 runs
|
| Summary
| LD_LIBRARY_PATH=. ./bench 1 dir-15000 dir-1000 dir-1 ran
| 84.48 ± 2.42 times faster than ./bench 1 dir-15000 dir-1000 dir-1
Signed-off-by: Clemens Lang <cllang@redhat.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25056)
Fixes#24892
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25046)
It appears nonstops new threading model defines some level of rwlock
pthread api, but its not working properly. Disable rwlocks for
_KLT_MODEL_ for now
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/24969)
Noted that we didn't check return codes of the atomic loads/stores in
the new hashtable, and they can fail
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/24969)
To ensure that the value of h->md doesn't get recomputed during a delete
operation use ossl_rcu_deref on it
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/24969)
If the implementation of this function falls to using a pthread lock to
update a value, it should be a write lock, not a read lock
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/24969)
If the name is not found in namemap, we need
to try to fetch the algorithm and query the
namemap again.
Fixes#19338
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/24940)
Also fixes Coverity 1604639
There is no point in checking ba_ret as it can never be NULL.
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/24931)
This entropy source can be used instead of SEED-SRC. Sample
openssl.cnf configuration is provided. It is built as a separate
provider, because it is likely to require less frequent updates than
fips provider. The same build likely can span multiple generations of
FIPS 140 standard revisions.
Note that rand-instances currently chain from public/private instances
to primary, prior to consuming the seed. Thus currently a unique ESV
needs to be obtained, and resue of jitterentropy.a certificate is not
possible as is. Separately a patch will be sent to allow for
unchaining public/private RAND instances for the purpose of reusing
ESV.
Also I do wonder if it makes sense to create a fips variant of stock
SEED-SRC entropy source, which in addition to using getrandom() also
verifies that the kernel is operating in FIPS mode and thus is likely
a validated entropy source. As in on Linux, check that
/proc/sys/crypto/fips_enabled is set to 1, and similar checks on
Windows / MacOS and so on.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24844)
There is a issue currently related to CMAC TDES, when the new provider
is tested against older branches.
The new strict check caused backwards compatibility issues when
using old branch with the new FIPS provider.
To get around this CMAC now allows TDES by default, but it can be either
enabled via config or a settable. (i.e it uses an indicator)
Where the TDES cipher check can be done turned out to be problematic.
Shifting the check in the TDES cipherout of the init doesnt work because
ciphers can run thru either final or cipher (and checking on every
cipher call seemed bad). This means it needs to stay in the cipher init.
So the check needs to be done in CMAC BEFORE the underlying TDES cipher
does it check.
When using an indicator the TDES cipher needs its "encrypt-check" set
so that needs to be propagated from the CMAC object. This requires
the ability to set the param at the time the cipher ctx is inited.
An internal function was required in order to pass params to CMAC_Init.
Note also that the check was done where it is, because EVP_Q_mac() calls
EVP_MAC_CTX_set_params(ctx, cipher_param)
EVP_MAC_CTX_set_params(ctx, params)
EVP_MAC_init(ctx, key, keylen, params)
Where the second call to set_params would set up "encrypt-check" after
"cipher".
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25022)
The operation is non-sensical.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/24862)
In FIPS 140-3, RSA Signing with X9.31 padding is not approved,
but verification is allowed for legacy purposes. An indicator has been added
for RSA signing with X9.31 padding.
A strict restriction on the size of the RSA modulus has been added
i.e. It must be 1024 + 256 * s (which is part of the ANSI X9.31 spec).
Added implementation comments to the X9.31 padding code
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/24021)
Under FIPS, we've got a whitelist of algorithms. There is no need to then
also check for XOF digests because they aren't possible.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25007)
Coverity flagged an issue in our bio_enc tests in which we failed to
check the return code of BIO_read for an error condition which can lead
to our length computation going backwards.
Just check the error code before adding it to length
Fixesopenssl/project#779
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/25006)
Coverity flagged a second error in this code
we're comparing block_padding and hs_padding for >= 0, which is always
true
With the change to the use of strtoul, inputs that are preceded with a -
(i.e. negative values), are caught already, so the check is redundant
just remove the check entirely
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/24993)
Coverity flagged an overflow warning in the cmsapitest.
Its pretty insignificant, but if a huge file is passed in via BIO, its
possible for the length variable returned to overflow.
Just check it as we read to silence coverity on it.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/24995)
This leaves 3DES with the FIPS query "FIPS=yes", which allows
Triple-DES to be used for Decryption by default.
Disallow CMAC using Triple-DES in FIPS.
This does not use a FIPS indicator.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/24960)
This is a FIPS 140-3 requirement.
This uses a FIP indicator if either the FIPS configurable "dsa_sign_disabled" is set to 0,
OR OSSL_SIGNATURE_PARAM_FIPS_SIGN_CHECK is set to 0 in the dsa signing context.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24799)
Coverity flagged an overflow warning here that can occur if BIO_write
returns an error.
The overflow itself is a bit of a non-issue, but if BIO_write returns
< 0, then the return from i2a_ASN1_OBJECT will be some odd value
representing whatever the offset from the error code to the number of
bytes the dump may or may not have written (or some larger negative
error code if both fail.
So lets fix it. Only do the dump if the BIO_write call returned 0 or
greaater.
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Paul Yang <kaishen.yy@antfin.com>
(Merged from https://github.com/openssl/openssl/pull/24976)
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24977)
The strtoul tests that were recently added had a compile time check for
__WORDSIZE to properly determine the string to use for an maximal
unsigned long. Unfortunately musl libc doesn't define __WORDSIZE so we
were in a position where on that platform we fall to the 32 bit unsigned
long variant, which breaks on x86 platforms.
Fix it by doing a preprocessor comparisong on ULONG_MAX instead.
NOTE: This works because preprocessors do arithmetic evaluation on
macros for every compiler we support. We should be wary of some more
esoteric compilers though.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/24974)
In this commit, we also return different error if the digest is XOF.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23889)
The quic-srtm fuzzer uses a loop in which an integer command is
extracted from the fuzzer buffer input to determine the action to take,
switching on the values between 0 and 3, and ignoring all other
commands. Howver in the failing fuzzer test case here:
https://oss-fuzz.com/testcase-detail/5618331942977536
The buffer provided shows a large number of 0 values (indicating an SRTM
add command), and almost no 1, 2, or 3 values. As such, the fuzzer only
truly exercises the srtm add path, which has the side effect of growing
the SRTM hash table unboundedly, leading to a timeout when 10 entries
need to be iterated over when the hashtable doall command is executed.
Fix this by ensuring that the command is always valid, and reasonably
distributed among all the operations with some modulo math.
Introducing this change bounds the hash table size in the reproducer
test case to less than half of the initially observed size, and avoids
the timeout.
Fixesopenssl/project#679
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24827)
Found by running the checkpatch.pl Linux script to enforce coding style.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22097)
