Confirm that we correctly fail if supported_versions is missing from an
HRR.
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25068)
If an HRR is sent then it MUST contain supported_versions according to the
RFC. We were sanity checking any supported_versions extension that was sent
but failed to verify that it was actually present.
Fixes#25041
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25068)
-trace option didn't cover early data message which resulted in
misleading logging.
CLA: trivial
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25026)
Add inline qualifier to avoid exporting a function for one unique use
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24968)
... due to a missing const.
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24968)
CLA: trivial
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Paul Yang <kaishen.yy@antfin.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25065)
Also includes an indicator and the capability to bypass via configuration
or params.
Fixes#24937
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/25032)
FIPS doesn't permit message hashes to be processed by thee algorithms.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/25032)
Adjust the existing tests to disable DSA keygen in FIPS mode.
Allow evp_test to load DSA 'KeyParams' that can then be used to
perform a DSA KeyGen.
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24978)
This uses a FIPS indicator.
Since DSA KeyGen is only useful for DSA signing,
it reuses the DSA signing FIPS configuration option and settable ctx name.
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24978)
Added OSSL_FUNC_keymgmt_gen_get_params() and
OSSL_FUNC_keymgmt_gen_gettable_params()
This will allow a FIPS indicator parameter to be queried after keygen.
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24978)
Fixes#25089
The test to check if the FIPS indicator was correct failed in 3.1.2
since EVP_PKEY_CTX_get_params() returns 0 if there is no
gettable/getter.
The code has been modified to return 1 if there is no gettable.
Manually reproduced and tested by copying the 3.1.2 FIPS provider to master.
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25093)
Since FIPS provider performs lower bound check by default from v3.0, the
default value for new configurable item will be one.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24120)
Don't do comma separation on those platforms.
Fixes#24986
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/25018)
Avoid using a fetched cipher that is decrypt-only
which is the case for 3DES from the fips provider.
Add a decrypt-only parameter to the EVP_CIPHER and test it
in libssl when fetching.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25028)
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)
