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)
X509_CRL_get0_tbs_sigalg() corresponds to X509_get0_tbs_sigalg() and
retrieves the AlgorithmIdentifier inside the TBSCertList which is not
currently accessible in any sane way from public API.
This PR adds X509_get0_tbs_sigalg() to the public API, documents it,
adds a simple regress check so there is coverage and mentions the
addition in CHANGES.md.
On top of that, fix a typo in .gitignore and clean up some order
inconsistencies in X509_get0_signature.pod.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27971)
This covers all LMS algorithm parameter sets.
The following changes were done to handle the tests:
(1) Changed LMS to use OSSL_PKEY_PARAM_PUB_KEY instead of
OSSL_PKEY_PARAM_ENCODED_PUBLIC_KEY for import/export.
(There is no reason to have the encoded form for verify operations).
(2) Fixed a bug for W=1 with truncated digests. The checksum was using
a value of 8-w, which was off by 1 for this case. A value was added to
the ots parameters that represents this value.
(3) A check in evp_test for a NID was removed since LMS does not have
OIDS (HSS does).
(4) the unused PROPERTIES param was removed from the LMS keymanager.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/27885)
Add HKDF-SHA256, HKDF-SHA384 and HKDF-SHA512 which are versions
of HKDF that have the digest pre-set. The digest cannot be changed
for contexts of these types.
RFC 8619 defines algorithm identifiers for these combinations.
These algorithm identifiers will be used in future features, e.g.
KEMRecipientInfo.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/27247)
Previously, this change had grouped the public and private
portions of the ML-KEM key structure into one allocation that
was changed to use secure memory. There were concerns raised
that there may be use cases where storage of many ML-KEM public
keys may be necessary. Since the total secure memory size is configured
by the user, reduce the footprint of secure memory usage to
reduce the impact of these changes on users of these flows.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27625)
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)
Align PKCS12 PBMAC1 PBKDF2 salt length with
PKCS5_DEFAULT_PBE2_SALT_LEN.
With this change, newly created PKCS12 PBMAC1 PBKDF2 keystores use mac
salt length of 16 bytes by default. This increases interoperability
with FIPS implementations which require at least 16 bytes of salt
length. Otherwise FIPS implementations fail to to open keystore with
invalid salt length errors (unapproved):
Mac verify error: invalid password?
80EBD061AD7F0000:error:1C800070:Provider routines:kdf_pbkdf2_set_ctx_params:invalid salt length:providers/implementations/kdfs/pbkdf2.c:293:
80EBD061AD7F0000:error:118C0103:PKCS12 routines:PBMAC1_PBKDF2_HMAC:internal error:crypto/pkcs12/p12_mutl.c:143:
80EBD061AD7F0000:error:1180006D:PKCS12 routines:PKCS12_verify_mac:mac generation error:crypto/pkcs12/p12_mutl.c:324:
80EBD061AD7F0000:error:1C800070:Provider routines:kdf_pbkdf2_set_ctx_params:invalid salt length:providers/implementations/kdfs/pbkdf2.c:293:
80EBD061AD7F0000:error:118C0103:PKCS12 routines:PBMAC1_PBKDF2_HMAC:internal error:crypto/pkcs12/p12_mutl.c:143:
80EBD061AD7F0000:error:1180006D:PKCS12 routines:PKCS12_verify_mac:mac generation error:crypto/pkcs12/p12_mutl.c:324:
The compile time constant is made possible to override with a build
time define, such that one can revert back to 8 if so is needed for
backwards compatibility.
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27446)
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)
The provider based STORE loaders do have settable parameters, so they should
be displayed when '-verbose' is given, just like for any other list.
Out of necessity, this also introduces OSSL_STORE_LOADER_settable_ctx_params()
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26437)
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)