X509_STORE was using STACK_OF(X509_OBJECT) which is not ideal structure. The
better solution is to use hashmap. The performance gains come from the fact that
sorting was removed and therefore read lock is just enough for looking up
objects/cert/crls from hashmap.
When X509_STORE_get0_objects() is called, the hashmap converts back to
the STACK_OF(X509_OBJECT), and goes back to the original
implementation with the performance hit on lookup side because stack is not
sorted anymore.
Note, hashmap maps X509_NAME to STACK_OF(X509_OBJECT), and the stack is never
sorted which may lead to performance impact if stack contains a huge of objects.
Before the change
| Threads | mean/us | var/us |
|---------+-----------+---------|
| 1 | 2.434803 | .034190 |
| 2 | 3.033588 | .247471 |
| 4 | 6.551132 | .150209 |
| 6 | 12.548113 | .258445 |
| 8 | 17.566257 | .168508 |
| 10 | 22.782846 | .182674 |
| 12 | 27.928990 | .426779 |
| 14 | 32.844572 | .307754 |
| 16 | 37.816247 | .660630 |
| 18 | 42.662465 | .434926 |
After the change
| Threads | mean/us | var/us |
|---------+----------+---------|
| 1 | 2.385398 | .015329 |
| 2 | 2.775794 | .172223 |
| 4 | 3.071882 | .126400 |
| 6 | 3.174147 | .139685 |
| 8 | 3.479235 | .297154 |
| 10 | 4.206260 | .149006 |
| 12 | 5.044039 | .194108 |
| 14 | 5.890640 | .185817 |
| 16 | 6.447808 | .256179 |
| 18 | 7.489261 | .149204 |
Resolves: https://github.com/openssl/project/issues/1275
Signed-off-by: Nikola Pajkovsky <nikolap@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28599)
https://github.com/openssl/openssl/actions/runs/15214054228/job/42795224720
the theory I have for the cause of this failure is:
1. qtest_create_quic_connection_ex is called for the client
2. The client is in blocking mode, so we fall into the conditional on line 512
3. We create the server thread on line 519, which is non-blocking
4. The scheduler in the failing case, lets the server run ahead of the client
5. Server thread enters qtest_create_quic_connection_ex and iterates steps
6-9 in the do_while loop starting on line 530
6. Server calls qtest_add_time
7. Server calls ossl_quic_tserver_tick
8. Server calls ossl_quic_tserver_is_term_any, received NULL return
9. Server calls qtest_wait_for_timeout
10. Eventually qtest_wait_for_timeout returns zero, adn the server jumps to
the error label, returning zero to globservret, and the thread exits
11. Client thread regains the cpu, and attempts to call SSL_connect, which
fails, as the server is no longer listening
12. We fall into the error case on line 556, and SSL_get_error returns
SSL_ERROR_SSL, which causes clienterr to get set to 1
13. We exit the do{} while loop on line 581, and do the TEST_true check on
line 593. The server having exited wait_for_thread returns true, but
globserverret is still zero from step 10 above, and so the test fails
I can't prove this is the case, as the test only appears to fail in CI,
and we can't dump verbose logging there, lest we affect the timing of
the tests, so this is just a theory, but it seems to fit the
observations we have.
Attempting to fix this, by creating a thread interlock with a condition
variable that blocks the server from ticking the quic reactor until such
time as the client is about to call SSL_connect to prevent the race
condition
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27704)
Initially tests that were written which make use of the noisy dgram BIO,
were done under the assumption that, despite any packet mangling done by
the noisy dgram bio, the connection would still be established. This
was initiall guaranteed by configuring the BIO to avoid
corrupting/dropping/duplicating/re-injecting the first packet received,
thus ensuring that the client and server hello frames would make it to
the peer successfully.
This implicitly made the assumption that the client and server hellos
were contained within a single datagram, which until recently was true.
However, with the introduction of ML-KEM keyshares, the above assumption
no longer holds. Large ML-KEM keyshares generally expand these TLS
messages accross multiple datagrams, and so it is now possible that
those initial records can become corrupted/lost etc, leading to
unexpected connection failures.
Lets fix it by restoring the guarantee that these tests were written
under by making the backoff time configurable to a number of frames, and
configuring the quic connection objects used in the test to not drop the
first two initial frames, once again guaranteeing that the client and
server hello arrive at the peer uncorrupted, so that we get a good
connection established.
Fixes#27103
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/27169)
In preparation for supporting the handling of version negotiation, we
need to be able to detect why the decoding of quic header failed.
Specifically, ossl_quic_wire_decode_pkt_hdr fails if the version
provided in the header isn't QUIC_VERSION_1. We want to keep that, as
we don't support anything else, but the server code needs to
differentiate when we fail decode because of a version problem, vs some
other more fatal malforming issue.
So add a uint64_t *fail_cause pointer that gets filled out with a
failure cause. We only use VERSION failures right now, but we can
expand this later if needed
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25968)
The sslapitest has a helper function to load the dasync engine which is
useful for testing pipelining. We would like to have the same facility
from sslbuffertest, so we move the function to the common location
ssltestlib.c
Follow on from CVE-2024-4741
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24395)
- add test vectors for tls1_3 integrity-only ciphers
- recmethod_local.h: add new member for MAC
- tls13_meth.c: add MAC only to tls 1.3
- tls13_enc.c: extend function to add MAC only
- ssl_local.h: add ssl_cipher_get_evp_md_mac()
- s3_lib.c: add the new ciphers and add #ifndef OPENSSL_NO_INTEGRITY_ONLY_CIPHERS
- ssl_ciph.c : add ssl_cipher_get_evp_md_mac() and use it
- tls13secretstest.c: add dummy test function
- Configure: add integrity-only-ciphers option
- document the new ciphers
Reviewed-by: Matt Caswell <matt@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/22903)
If either endpoint issues a PING frame while we are introducing noise
into the communication then there is a danger that the connection itself
will fail. We detect the PING and then back off on generating noise for a
short while. It should be sufficient to just ensure that the next datagram
does not get dropped for each endpoint.
Fixes#22199
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22243)
