We use the returned data to decide how to split the data we want to write
into records.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19198)
This also means we can convert SSLfatal calls to RLAYERfatal
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19198)
There were a small number of references to the SSL_CONNECTION that can
be removed easily and replaced with record layer equivalents.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19198)
Previously we were referencing the block_padding value through the
SSL_CONNECTION. Now it is held within OSSL_RECORD_LAYER.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19198)
We wrap the callback and pass it to the record layer via the dispatch
array, in order to avoid accessing it directly via SSL_CONNECTION.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19198)
In all cases we should be able to replace this with a simple check
against rl->version.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19198)
This flag can now be managed entirely by the new record layer code so we
move it into ossl_record_layer_st.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19198)
Now that we are no longer recursively addinng the prefix record this
doesn't seem necessary any more. We always add it every time we do
tls_write_records.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19198)
This calculation is based on lots of information from state machine and
elsewhere that the record layer cannot access. In reality it is sufficient
to simply tell the record layer what version to use.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19198)
We retain a numwpipes for now in the old record layer structure for use
by DTLS. This will eventually be removed when DTLS moves over to the new
way of doing things.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19198)
We use the record layer reference to the BIO rather than the SSL object
reference. This removes an unneeded SSL object usage.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19198)
This removes unnecessary usage of the SSL object from the record layer.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19198)
This isn't a record layer responsibility so should be removed from
write_records.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19198)
Make sure we set the write record layer method and create the object
where appropriate. Move the newly restructured writing code into the
record layer object.
For now we are cheating and still accessing the underlying SSL_CONNECTION
object. This will be removed in subsequent commits.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19198)
The new write record layer architecture splits record writing into
a "write_records" call and a "retry_write_records" call - where multiple
records can be sent to "write_records" in one go. We restructure the code
into that format in order that future commits can move these functions into
the new record layer more easily.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19198)
ASYNC_init_thread() will be called automatically by ASYNC_start_job(),
so ASYNC_cleanup_thread() must be called at last, otherwise it will
cause memory leak.
Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16703)
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19240)
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19240)
The code is derived from @sftcd's work in PR #17172.
This PR puts the DHKEM algorithms into the provider layer as
KEM algorithms for EC and ECX.
This PR only implements the DHKEM component of HPKE as specified in
RFC 9180.
crypto/hpke/hpke_util.c has been added for fuctions that will
be shared between DHKEM and HPKE.
API's for EVP_PKEY_auth_encapsulate_init() and EVP_PKEY_auth_decapsulate_init()
have been added to support authenticated encapsulation. auth_init() functions
were chosen rather that a EVP_PKEY_KEM_set_auth() interface to support
future algorithms that could possibly need different init functions.
Internal code has been refactored, so that it can be shared between the DHKEM
and other systems. Since DHKEM operates on low level keys it needs to be
able to do low level ECDH and ECXDH calls without converting the keys
back into EVP_PKEY/EVP_PKEY_CTX form. See ossl_ecx_compute_key(),
ossl_ec_public_from_private()
DHKEM requires API's to derive a key using a seed (IKM). This did not sit
well inside the DHKEM itself as dispatch functions. This functionality
fits better inside the EC and ECX keymanagers keygen, since
they are just variations of keygen where the private key is generated
in a different manner. This should mainly be used for testing purposes.
See ossl_ec_generate_key_dhkem().
It supports this by allowing a settable param to be passed to keygen
(See OSSL_PKEY_PARAM_DHKEM_IKM).
The keygen calls code within ec and ecx dhkem implementation to handle this.
See ossl_ecx_dhkem_derive_private() and ossl_ec_dhkem_derive_private().
These 2 functions are also used by the EC/ECX DHKEM implementations to generate
the sender ephemeral keys.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19068)
CLA: trivial
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19239)
Ensure we are testing a handshake that includes a HelloVerifyRequest and
what happens if we drop it.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18654)
If we receive a ClientHello and send back a HelloVerifyRequest, we need
to be able to handle the scenario where the HelloVerifyRequest gets lost
and we receive another ClientHello with the message sequence number set to
0.
Fixes#18635
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18654)
Also add related references to FR #15725.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/18900)
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/18900)
CLA: trivial
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19234)
CLA: trivial
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19234)
Construction return values are no longer boolean but can return 3 different
values, so we use an enum to represent them.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18990)
If we can't construct the ticket don't send one. This requires a change
to the TLS state machine to be able to a handle a construction function
deciding not to send a message after all.
Fixes#18977
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18990)
A 0 return from a ticket key callback should indicate that crypto parameters
are not currently available and that the handshake should continue without
generating/using the ticket.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18990)
Doing so, had to fix sloppiness in using the stack API in crypto/conf/conf_def.c,
ssl/ssl_ciph.c, ssl/statem/statem_srvr.c, and mostly in test/helpers/ssltestlib.c.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/18918)
