In a hypothetical scenario that jent_entropy_init_ex fails, or if
get_jitter_random-value fails, there are a few unexpected
posibilities.
If jent_entropy_init_ex fails, the seed initialisation may return NULL
and then DRBG will be initiated with NULL seed, which will
automatically fallback to os-seed, which will escape module boundary
(if this jitter rng is from the fips module), and call getrandom
syscall.
And separately if get_jitter_random_value fails, it may put DRBG in an
error state, but it might not put the FIPS module in error state, like
it should as per the ISO standard.
To instrument these things, I had to create tampered
jitterentropy-library that always returns errors for init_ex and
read_entropy apis, and then use gdb tracing on both libcrypto.so and
fips.so.
The most minimal solution to above hypothetical error code paths, is
to simply call ossl_set_error_state. It is either harmless, or in case
of fips-jitter will correctly put the FIPS module into error state and
prevent any further operation; and cruitially prevent silent fallback
to getrandom syscall.
Note it is unlikely that this ever was out of compliance, as often
enough getrandom syscall goes to a kernel with validated entropy
source; and openssl fips module still did reject sampling which is too
entropy source compliant.
Nonetheless it is good to fix this hypothetical error path, and
backport this to 3.5 and up.
This is similar / additional fixes, to this previous change:
- https://github.com/openssl/openssl/pull/25957
- b9886a6f34
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/29226)
(cherry picked from commit 21069c983b)
we assume these to be order sensitive and not self contained, so
as per our new style we disable clang format around them.
we should consider renaming to .inc, or doing away with some
of these and just putting the code inline, but that's for
later consideration.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/29243)
If OPENSSL_LINE ends up on a different line than the following call here,
this test breaks.
We should perhaps reconsider if testing the reporting of OPENSSL_LINE
is what we want in a malloc test, but that's for another time than now.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/29243)
Similar to the previous errtest.c fix this also is not broken
by any reformatting today, but this change makes this follow
the same pattern as the other things that test OPENSSL_LINE
after the fact so we maintain the same paradigm everywhere.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/29243)
(in it's final form it will work with either compiler
because it's currently one line, but was tripped up before
by the #ifdef, so redid it to be consistent with the
other changes previously in this stack)
While I am here correct the test to test for all possible
return values of ERR_get_error_all, without the #ifdefs
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/29243)
Fortunately due to the initial size of the allocated
buffer and the limit for unfragmented DTLS record size
the use-after-realloc cannot be triggered.
But we fix the potentially problematic code anyway.
Reported Joshua Rogers. It was found with the ZeroPath security
tooling.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/29278)
(cherry picked from commit 6d1d85c31b)
Check parameters of ECDSA signatures on verify and fail for invalid
malformed signatures in the code path for s390x accelerators. Handle
condition code of kdsa instruction for detecting invalid parameters.
For NIST P521 curves, kdsa ignores completely the upper 14 bytes of
the sections for r and s in the parameter-block, so adapt the offset
and length for bignum conversions for these curves. This will detect
cases of malformed signatures which are not covered by the kdsa
parameter checking.
Fixes: #29173
Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/29214)
(cherry picked from commit 8e28ea9e62)
The kdsa instruction is doing some parameter checking for the verify
function codes, like r/s equals zero and range checks. To handle these
cases correctly in the calling functions, the asm returns now also
condition code 2.
Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/29214)
(cherry picked from commit bcaa2a3af6)
- Add explicit links to related EVP_* functions for each signature method
- Clarify the differences between sign/verify, message sign/verify, and digest sign/verify functions
- Document TLS 1.3 requirements: digest_sign/verify functions are mandatory for libssl usage
- Provide guidance for provider developers on which functions to implement for different use cases
Fixes#27127
Signed-off-by: Samaresh Kumar Singh <ssam3003@gmail.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Nikola Pajkovsky <nikolap@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/29166)
(cherry picked from commit 47418dd8de)
tls1_set_groups(), which is used by SSL_CTX_set1_groups() does not check
whether the NIDs passed as argument actually have an implementation
available in any of the currently loaded providers. It is not simple to
add this check, either, because it would require access to the SSL_CTX,
which this function does not receive. There are legacy callers that do
not have an SSL_CTX pointer and are public API.
This becomes a problem, when an application sets the first group to one
that is not supported by the current configuration, and can trigger
sending of an empty key share.
Set the first entry of the key share list to 0 (and the key share list
length to 1) to signal to tls1_construct_ctos_key_share that it should
pick the first supported group and generate a key share for that. See
also tls1_get_requested_keyshare_groups, which documents this special
case.
See: https://issues.redhat.com/browse/RHEL-128018
Signed-off-by: Clemens Lang <cllang@redhat.com>
Reviewed-by: Norbert Pocs <norbertp@openssl.org>
Reviewed-by: Simo Sorce <simo@redhat.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/29192)
(cherry picked from commit 5375e940e2)
QUIC connections always pad data at the packet level during packet
encryption, and so have no ability to do padding at the record level.
We want to be able to inform the user of this condition when
applications call SSL_set_block_padding_ex directly by returning an
error, we have no idea of what kind of SSL objects are created when the
config file is written.
As such, silently ignore this config file option when QUIC objects are created.
Fixes#28953
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/29193)
Like SSL_is_quic, it would be helpful to know if SSL_CTX objects create
QUIC SSL's or not.
Note, this is a public function in the master branch, but is made
private for older stable branches, so as not to introduce new public
API's there (3.6-3.0)
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/29193)
Using SSL_CTX_set_cert_verify_callback but still calling
X509_verify_cert is useful if applications want to dynamically
configure the X509_STORE_CTX, or postprocess the result, in a way that
does not quite fit the somewhat unpredictable behavior of the
SSL_CTX_set_verify callback. (In my experience, applications rarely
realize it is called multiple times. It's also too late at that point to
reconfigure the X509_STORE_CTX as verification has already started.)
There is one note in the docs that the callback needs to stash the
verify result with X509_STORE_CTX_set_error, but it is not immediately
obvious that X509_verify_cert will do so, or that it is the built-in
behavior. Add a paragraph discussing this.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28960)
(cherry picked from commit 069181d7f3)
The OSSL_FUNC_signature_{sign,verify}_message_* functions were added
in OpenSSL 3.4 but weren't documented in the HISTORY section of
provider-signature(7), while the corresponding EVP_PKEY_sign_message_*
functions are properly documented in EVP_PKEY_sign(3).
This adds the missing HISTORY entry to document when these provider
functions were introduced.
Fixes#29088
CLA: trivial
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Norbert Pocs <norbertp@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/29130)
(cherry picked from commit 6b4ad7f8d8)
This fixes the following compilation error on HP-UX:
```
11:07:19 crypto/evp/bio_ok.c: In function 'block_in':
11:07:19 crypto/evp/bio_ok.c:579: error: 'SIZE_MAX' undeclared (first use in this function)
11:07:19 crypto/evp/bio_ok.c:579: error: (Each undeclared identifier is reported only once
11:07:19 crypto/evp/bio_ok.c:579: error: for each function it appears in.)
```
Signed-off-by: Lars Erik Wik <lars.erik.wik@northern.tech>
CLA: trivial
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Norbert Pocs <norbertp@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28793)
(cherry picked from commit 695a5aaf0b)
