Adds storage for currently understood remote QUIC transport parameters in the SSL_SESSION struct, including serialization and deserialization support. Sets defaults for these values on SSL_SESSION creation. This enables clients to remember and reuse required QUIC transport parameters for 0-RTT.
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28301)
Some are only checking for a value < 0, some for <= 0, some for == 0, etc.
The documentation tells us that -1 is returned on error, so at least the
== 0 ones are wrong. In general, the return values are checked
inconsistently. This patch makes the return value checks consistent to
the form that seems to occur most.
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28306)
Current QUIC stack may leave connection monitored by SSL_poll() to stale
during regular shutdown. The issue is triggered when ACK for client's
FIN gets delayed. The sequeance of operations to trigger
the stale of QUIC connection at client goes as follows:
- application calls SSL_shutdown() on connection,
the shutdown can not proceed, because bi-directional
stream must be flushed. The client awaits ACK from
server acknowledging reception of FIN on client's stream
- the stream object gets destroyed, because application
received all data from server.
- application updates poll set and passes to SSL_poll()
- ssl poll ticks the engine. Engine receives delayed ACK
and marks stream as flushed. At this point the SSL_shutdown()
operation may proceed given the application calls the
SSL_shutdown(). However there is no mechanism to make SSL_poll()
return so application is unable to proceed with its event
loop where SSL_shutdown() may get called.
This change introduces ossl_quic_channel_notify_flush_done() function
which notifies channel when all streams are flushed (all FINs got ACKed).
The first thing SSL_shudown() does it calls ossl_quic_stream_map_begin_shutdown_flush().
The function walks list of all streams attached to channel and notes how many
streams is missing ACK for their FIN. In our test case it finds one such stream.
Call to SSL_shutdown() returns and application destroys the SSL stream object
and updates a poll set.
SSL_poll() gets called. The QUIC stack (engine) gets ticked and reads data
from socket. It processes delayed ACK now. The ACK-manager updates the
stream notifying the server ACKs the FIN sent by client. The stream
is flushed now. Thw shutdown_flush_done() for stream gets called on
behalf of ACK manager.
The shutdown_flush_done() does two things:
- it marks stream as flushed
- it decrements the num_shutdown_flush counter initialized
be earlier call to ossl_quic_stream_map_begin_shutdown_flush()
called by SSL_shutdown()
The change here calls ossl_quic_channel_notify_flush_done() when
num_shutdown_flush reaches zero.
The ossl_quic_channel_notify_flush_done() then calls function
ossl_quic_channel_notify_flush_done(), which just moves the state
of the channel (connection) from active to terminating state.
The change of channel state is sufficent for SSL_poll() to
signal _EC event on connection.
Once application receives _EC event on connection it should
check the state of the channel/reason of error. In regular case
the error/channel state hints application to call SSL_shutdown()
so connection object can proceed with connection shutdown.
The SSL_shutdown() call done now moves channel to terminated
state. So the next call to SSL_poll() can signal _ECD which
tells application it's time to stop polling on SSL connection
object and destroy it.
Fixesopenssl/project#1291
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28116)
When looking in the stack of objects in the store we need to ensure we
are holding a read lock for the store.
Issue detected via thread sanitizer after the test from the previous
commit was added.
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28198)
Previously #27529 made a change to `by_store_ctrl_ex` in order to open
the OSSL_STORE early. The reason given in that PR is:
"This way, we can call OSSL_STORE_open_ex() in by_store_ctrl_ex(), and
get to see possible errors when the URI is loaded"
That PR then kept the store open until cache_objects is called and then
reused it. Unfortunately by the time cache_objects() is called we could be
in a multi-threaded scenario where the X509_STORE is being shared by
multiple threads. We then get a race condition where multiple threads are
all using (and ultimately closing) the same `OSSL_STORE_CTX`.
The purpose of keeping the `OSSL_STORE` object between by_store_ctrl_ex()
and `cache_objects` is presumably an optimisation to avoid having to open
the store twice. But this does not work because of the above issue.
We just take the hit and open it again.
Fixes#28171
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28198)
Fixes#28313
Recently Deterministic ECDSA was added to the FIPS provider.
I cant run s390 directly but I suspect the call to
ossl_ec_group_do_inverse_ord() fails because it passes a NULL bn_ctx.
This potentially then calls ec_field_inverse_mod_ord() that has code in
it that fails in fips mode if the BN_CTX is not passed.
It cant create it internally since it does not know what the OSSL_LIB_CTX is,
which is required when creating a BN_CTX.
The solution is to create a BN_CTX that uses the ec_key lib ctx and pass
that in.
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28314)
FIPS 140-3 IG states that SHA-224 needs standalone KAT, if it is
implemented without SHA-256. As OpenSSL implements SHA-256, upgrade
existing higher level KAT from SHA-224 to SHA-256 without adding
SHA-224 digest KAT.
Upgrade KATs that use SHA-1 to SHA-256, and add explicit SHA-1 KAT.
SHA-1 and SHA-224 are promised to be deprecated by 2030, as per draft
[NIST SP 800-131A Rev. 3](https://csrc.nist.gov/pubs/sp/800/131/a/r3/ipd).
With upgrades to these KATs it makes it easier to build a modules with
SHA-1 and SHA-224 marked as unapproved services, or removed
altogether.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28307)
[FIPS 186-5](https://doi.org/10.6028/NIST.FIPS.186-5) approved
deterministic ECDSA in the same manner as [RFC
6979](https://datatracker.ietf.org/doc/html/rfc6979).
Thus add deterministic ECDSA capability to the FIPS provider.
DSA signature generation has been deprecated and removed from FIPS
186-5, thus deterministic DSA signature creation is not added to the
FIPS provider.
Testing can be done by performing 20-test_dgst.t but need to version
guarded against different FIPS provider versions. Thus is left out of
this PR for now.
It is not clear if HMAC-DRBG-KDF should be exposed publically for
direct usage as an approved usage, or if it should be marked as
unapproved or better yet made completely internal to the FIPS
provider.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28213)
Creating public key context from name would always fail
for composite signature algorithms (such as RSA-SHA256)
because the public key algorithm name (e.g., RSA) does
not match the name of the composite algorithm.
Relates to #27855.
Signed-off-by: Pavol Žáčik <zacik.pa@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28224)
Detected another memfail failure
https://github.com/openssl/openssl/actions/runs/16926186604/job/47962169870
Tracking it back, it occurs because tls1_set_server_sigalgs attempts to
preform an allocation, and in the event of failure, returns 0 without
setting SSLfatal, like the other failure paths in this function do when
returning 0, which translates to a return of WORK_ERROR higher up the
stack
The result is that on the next call to check_fatal in
read_state_machine, we fail the assert when deubg is enabled (as it is
in the coverage tests).
Fix it by calling SSLfatal when the call to OPENSSL_calloc fails in this
function.
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28250)
