This change includes bss_sock.c to deal with introduction of EPROTO use.
Reroll of rsa_ossl.c changes made at 3.5 downward.
Build a workaround in timing_load_creds.c on NonStop for lack of rusage.
This simulates getrusage() that is not available on NonStop.
Update bioprinttest.c to handle missing PTRxPRT definitions from inttypes.h.
Fixes: #29023
Signed-off-by: Randall S. Becker <randall.becker@nexbridge.ca>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/29024)
This introduces a new function, `SELF_TEST_kats_single()`, to the FIPS
provider. This allows for deferring running the Known Answer Tests (KATs)
for a specific algorithm. This is useful to avoid running
computationally costly tests upfront and instead run them only if the
algorithm is actually going to be used.
To support this, a `deferred` flag has been added to the test data
structures. The main self-test function, `SELF_TEST_kats()`, is updated to
skip tests marked for deferred execution, preserving its existing startup
behavior for all other tests.
Signed-off-by: Simo Sorce <simo@redhat.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28725)
On linux ktls can only be enabled on established TCP sockets.
When SSL_set_fd() is called before the connection is established
ktls_enable() fails and ktls is not setup.
This moves ktls_enable() call within then ktls_start() function.
Multiple calls to ktls_start() will trigger additional ktls_enable()
calls which fail with EEXIST, but do not affect the ktls socket.
CLA: trivial
Signed-off-by: Ulrich Weber <ulrich.weber@gmail.com>
Reviewed-by: Paul Yang <paulyang.inf@gmail.com>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27908)
This change introduces a new public API symbol: SSL_get_peer_addr().
The change is QUIC-only, there are no changes for TLS connections
- API: add peer address query for QUIC connections
* Internal: declare/implement ossl_quic_get_peer_addr(SSL*, BIO_ADDR*)
* Public: declare/implement SSL_get_peer_addr(SSL*, BIO_ADDR*)
Rationale:
- Allow applications to retrieve the remote UDP tuple for QUIC sessions
(e.g., logging, access control, diagnostics)
Provided documentation and test cases for SSL_get_peer_addr().
Set peer via channel API on new-conn.
- In ch_on_new_conn_common(), BIO_ADDR_copy(&ch->cur_peer_addr, peer)
was replaced with ossl_quic_channel_set_peer_addr(ch, peer) so
addressed_mode is enabled at connection bring-up.
Dropped redundant peer detection in create_qc_from_incoming_conn()
The peer address is now propagated in ch_on_new_conn_common() via
ossl_quic_channel_set_peer_addr(), so the channel is already in
"addressed" mode. This also avoids querying the (unconnected) server
UDP BIO, reduces duplication, and simplifies the accept path. All
regression tests pass.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28690)
a new config option _no_rcu_ is added into HT_CONFIG. When _no_rcu_ is
set then hashtable can be guarded with any other locking primitives,
and behives as ordinary hashtable. Also, all the impact of the
atomics used internally to the hash table was mitigated.
RCU performance
# INFO: @ test/lhash_test.c:747
# multithread stress runs 40000 ops in 40.779656 seconds
No RCU, guarded with RWLOCK
# INFO: @ test/lhash_test.c:747
# multithread stress runs 40000 ops in 36.976926 seconds
Signed-off-by: Nikola Pajkovsky <nikolap@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28677)
When defining a custom hash function for a hashtable key, you typically start with:
HT_START_KEY_DEFN(key)
HT_DEF_KEY_FIELD(k, unsigned char *)
HT_END_KEY_DEFN(KEY)
In this setup, the hash function signature requires keybuf and len as
parameters rather than the hashtable key itself. As a result,
accessing members of the hashtable structure becomes awkward, since
you must do something like:
#define FROM_KEYBUF_TO_HT_KEY(keybuf, type) (type)((keybuf) - sizeof(HT_KEY))
static uint64_t ht_hash(uint8_t *keybuf, size_t keylen)
{
KEY *k = FROM_KEYBUF_TO_HT_KEY(keybuf, KEY *);
...
}
This kind of pointer arithmetic is both unnecessary and error-prone.
A cleaner approach is to pass the HT pointer directly into the hash
function. From there, you can safely cast it to the required type
without the pointer gymnastics.
Signed-off-by: Nikola Pajkovsky <nikolap@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28677)
Switching from ANSI-C we can use implementation of printf like
function provided by libc on target platform. This applies
starting from 3.6 and onwards.
The slight exception here is old windows printf functions
before 2015, those are supported.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28305)
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)
during memfail testing:
https://github.com/openssl/openssl/actions/runs/16794088536/job/47561223902
We get lots of test failures in ossl_rcu_read_lock. This occurs
because we have a few cases in the read lock path that attempt mallocs,
which, if they fail, trigger an assert or a silent failure, which isn't
really appropriate. We should instead fail gracefully, by informing the
caller that the lock failed, like we do for CRYPTO_THREAD_read_lock.
Fortunately, these are all internal apis, so we can convert
ossl_rcu_read_lock to return an int indicating success/failure, and fail
gracefully during the test, rather than hitting an assert abort.
Fixesopenssl/project#1315
Reviewed-by: Paul Yang <paulyang.inf@gmail.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28195)
Such routines allow alleviating the need to perform explicit integer
overflow check during allocation size calculation and generally make
the allocations more semantic (as they signify that a collection
of NUM items, each occupying SIZE bytes is being allocated), which paves
the road for additional correctness checks in the future.
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28059)
Recently, our overnight QUIC interop runs began failing in CI when an
openssl server was tested against an ngtcp2 client:
https://github.com/openssl/openssl/actions/runs/16739736813
The underlying cause bears some explination for historical purposes
The problem began happening with a recent update to ngtcp2 in which
ngtcp2 updated its wolfssl tls backend to support ML-KEM, which caused
ngtcp to emit a client hello message that offered several groups
(including X25519MLKEM768) but only provided a keyshare for x25519.
This in turn triggered the openssl server to respond with a hello retry
request (HRR), requesting an ML-KEM keyshare instead, which ngtcp2
obliged. However all subsequent frames from the client were discarded by
the server, due to failing packet body decryption.
The problem was tracked down to a mismatch in the initial vectors used
by the client and server, leading to an AEAD tag mismatch.
Packet protection keys generate their IV's in QUIC by xoring the packet
number of the received frame with the base IV as derived via HKDF in the
tls layer.
The underlying problem was that openssl hit a very odd corner case with
how we compute the packet number of the received frame. To save space,
QUIC encodes packet numbers using a variable length integer, and only
sends the changed bits in the packet number. This requires that the
receiver (openssl) store the largest received pn of the connection,
which we nominally do.
However, in default_port_packet_handler (where QUIC frames are processed
prior to having an established channel allocated) we use a temporary qrx
to validate the packet protection of those frames. This temporary qrx
may be incorporated into the channel in some cases, but is not in the
case of a valid frame that generates an HRR at the TLS layer. In this
case, the channel allocates its own qrx independently. When this
occurs, the largest_pn value of the temporary qrx is lost, and
subsequent frames are unable to be received, as the newly allocated qrx
belives that the larges_pn for a given pn_space is 0, rather than the
value received in the initial frame (which was a complete 32 bit value,
rather than just the changed lower 8 bits). As a result the IV
construction produced the wrong value, and the decrypt failed on those
subsequent frames.
Up to this point, that wasn't even a problem, as most quic
implementations start their packet numbering at 0, so the next packet
could still have its packet number computed properly. The combination
of ngtcp using large random values for initial packet numbers, along
with the HRR triggering a separate qrx creation on a channel led to the
discovery of this discrepancy.
The fix seems pretty straightforward. When we detect in
port_default_packet_handler, that we have a separate qrx in the new
channel, we migrate processed packets from the temporary qrx to the
canonical channel qrx. In addition to doing that, we also need to
migrate the largest_pn array from the temporary qrx to the channel_qrx
so that subsequent frame reception is guaranteed to compute the received
frame packet number properly, and as such, compute the proper IV for
packet protection decryption.
Fixesopenssl/project#1296
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28115)
According to RFC 9002, section 6.2.2.1 the client the client must keep PTO (probe
time out) armed if it has not seen HANDSHAKE_DONE quic message from server.
Not following RFC spec here may cause the QUIC session to stale during TLS handshake.
Fixesopenssl/project#1266
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28023)
Introduces SSL_ACCEPT_STREAM_UNI and SSL_ACCEPT_STREAM_BIDI flags to SSL_accept_stream, allowing callers to specify whether to accept only unidirectional or bidirectional streams. Returns the first of its type from the queue
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27883)
This thread-local key isn't per thread*context, and is potentially in a
hot path for users of openssl that switch their default contexts
regularly, so lets leave it as an OS level key, rather than a library
managed key.
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27794)
Allow for use of default context in the thread-local api by using
get_concrete
This creates a problem however in that get_concrete access a
thread-local api, creating a recursive call that exhausts stack space
So create a special context token that identifys the no context use case
when we want to store thread-local data without an explicit context
index
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27794)
Thread event handlers in the fips provider create a thread-local storage
key per context, meaning we can exhaust our thread-local space quickly
by creating lots of contexts. Avoid that by moving to the new
thread-local storage api.
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27794)
As opposed to CRYPTO_THREAD_[get|set]_local counterparts
These api use an ennumerated set of fixed key ids, that allow for
thread-local storage indexed by key AND libctx value. They also store
this data against a single OS level thread-local key, reducing the
amount of (limited) thread-local key storage space we use
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27794)
This function is old and fairly broken. Code archeology in our git tree
hasn't revealed why it was creted (though it may have possibly been to
support older win32 systems that couldn't do 64 bit integers properly,
like windows 95/98).
There seems to be no good reason to keep it around, and given that it
has potentially serious side effects, lets just remove it.
Fixes#27761
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27763)
The fips provider has an internal provider. In some circumstances we
could end up trying to find it, but failing because it hasn't been loaded
yet. We just always ensure it is loaded early to avoid this.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27408)
Calling SSL_accept() was raising two errors on the stack if you passed
the wrong object type. Similarly SSL_get_error() was adding an error to
the stack if the wrong object type was passed and returning the wrong
result.
We also ensure SSL_set_accept_state() and SSL_set_connect_state() don't
raise spurious errors since these are void functions.
Fixes#27347Fixes#27348
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27351)
Milan Broz
Daniel Kubec
Randall S. Becker
Simo Sorce
Ondřej Surý
Joshua Rogers
Ulrich Weber
Gustaf Neumann
Nikola Pajkovsky
Eugene Syromiatnikov
sashan
Pauli
openssl-machine
Alexandr Nedvedicky
Neil Horman
GAlvare
Chiller Dragon
Andrew Dinh
Tomas Mraz
Richard Levitte
Alexis Goodfellow
Jai S
Matt Caswell
Gerd Hoffmann