History log of /openbsd/lib/libssl/tls13_internal.h (Results 1 – 25 of 103)
Revision Date Author Comments
# 34cd1859 27-Jan-2024 jsing <jsing@openbsd.org>

Make tls13_legacy_return_code() static.


# 9c83d710 27-Jan-2024 jsing <jsing@openbsd.org>

Add message callbacks for alerts in the TLSv1.3 stack.

This will make it easier to regress test shutdown behaviour in the TLSv1.3
stack. Additionally, `openssl -msg` now shows alerts for TLSv1.3
con

Add message callbacks for alerts in the TLSv1.3 stack.

This will make it easier to regress test shutdown behaviour in the TLSv1.3
stack. Additionally, `openssl -msg` now shows alerts for TLSv1.3
connections.

ok tb@

show more ...


# f7e8f89f 24-Jul-2022 jsing <jsing@openbsd.org>

Provide record layer callbacks for QUIC.

QUIC uses TLS to complete the handshake, however unlike normal TLS it does
not use the TLS record layer, rather it provides its own transport. This
means tha

Provide record layer callbacks for QUIC.

QUIC uses TLS to complete the handshake, however unlike normal TLS it does
not use the TLS record layer, rather it provides its own transport. This
means that we need to intercept all communication between the TLS handshake
and the record layer. This allows TLS handshake message writes to be
directed to QUIC, likewise for TLS handshake message reads. Alerts also
need to be sent via QUIC, plus it needs to be provided with the traffic
keys that are derived by TLS.

ok tb@

show more ...


# 6ea83a9d 24-Jul-2022 jsing <jsing@openbsd.org>

Provide QUIC encryption levels.

QUIC wants to know what "encryption level" handshake messages should be
sent at. Provide an ssl_encryption_level_t enum (via BoringSSL) that
defines these (of course

Provide QUIC encryption levels.

QUIC wants to know what "encryption level" handshake messages should be
sent at. Provide an ssl_encryption_level_t enum (via BoringSSL) that
defines these (of course quictls decided to make this an
OSSL_ENCRYPTION_LEVEL typedef, so provide that as well).

Wire these through to tls13_record_layer_set_{read,write}_traffic_key() so
that they can be used in upcoming commits.

ok tb@

show more ...


# fc718d1d 20-Jul-2022 jsing <jsing@openbsd.org>

Remove tls_buffer_set_data() and remove/revise callers.

There is no way that tls_buffer_set_data() can currently work in
conjunction with tls_buffer_expand(). This fact is currently hidden by the
wa

Remove tls_buffer_set_data() and remove/revise callers.

There is no way that tls_buffer_set_data() can currently work in
conjunction with tls_buffer_expand(). This fact is currently hidden by the
way that PHH works, which reads the same data from the record layer (which
it needs to do anyway, since we may not have all of the handshake message
in a single record).

Since this is broken, mop it up and change the PHH callback to not provide
the record data.

ok beck@ tb@

show more ...


# 6a3d21ee 17-Jul-2022 jsing <jsing@openbsd.org>

Pass SSL pointer to tls13_ctx_new().

struct tls13_ctx already knows about SSL's and this way tls13_ctx_new() can
set up various pointers, rather than duplicating this in
tls13_legacy_accept() and tl

Pass SSL pointer to tls13_ctx_new().

struct tls13_ctx already knows about SSL's and this way tls13_ctx_new() can
set up various pointers, rather than duplicating this in
tls13_legacy_accept() and tls13_legacy_connect().

ok tb@

show more ...


# 4b4fb912 03-Jun-2022 tb <tb@openbsd.org>

Provide #defines for the two currently registered PskKeyExchangeModes.

ok jsing


# b8e3503d 05-Jan-2022 jsing <jsing@openbsd.org>

Rename tls13_key_share to tls_key_share.

In preparation to use the key share code in both the TLSv1.3 and legacy
stacks, rename tls13_key_share to tls_key_share, moving it into the shared
handshake

Rename tls13_key_share to tls_key_share.

In preparation to use the key share code in both the TLSv1.3 and legacy
stacks, rename tls13_key_share to tls_key_share, moving it into the shared
handshake struct. Further changes will then allow the legacy stack to make
use of the same code for ephemeral key exchange.

ok inoguchi@ tb@

show more ...


# f6184395 23-Oct-2021 jsing <jsing@openbsd.org>

Rename tls13_buffer to tls_buffer.

This code will soon be used in the DTLSv1.2 and TLSv1.2 stack. Also
introduce tls_internal.h and move/rename the read/write/flush callbacks.

ok beck@ tb@


# 1e0f72fe 16-Sep-2021 jsing <jsing@openbsd.org>

Implement flushing for TLSv1.3 handshakes.

When we finish sending a flight of records, flush the record layer output.
This effectively means calling BIO_flush() on the wbio.

Some things (such as ap

Implement flushing for TLSv1.3 handshakes.

When we finish sending a flight of records, flush the record layer output.
This effectively means calling BIO_flush() on the wbio.

Some things (such as apache2) have custom BIOs that perform buffering and
do not actually send on BIO_write(). Without BIO_flush() the server thinks
it has sent data and starts receiving records, however the client never
sends records since it never received those that the server should have
sent.

Joint work with tb@

ok tb@

show more ...


# 55ec4bc3 14-Sep-2021 tb <tb@openbsd.org>

zap trailing white space


# d6a7e173 14-Sep-2021 tb <tb@openbsd.org>

Call the info cb on connect/accept exit in TLSv1.3

The p5-Net-SSLeay test expects the info callback to be called on
connect exit. This is the behavior in the legacy stack but wasn't
implemented in t

Call the info cb on connect/accept exit in TLSv1.3

The p5-Net-SSLeay test expects the info callback to be called on
connect exit. This is the behavior in the legacy stack but wasn't
implemented in the TLSv1.3 stack. With this commit, p5-Net-SSLeay
tests are happy again after the bump.

ok bluhm inoguchi jsing

show more ...


# 8ccc3944 04-Sep-2021 jsing <jsing@openbsd.org>

Factor out the TLSv1.3 code that handles content from TLS records.

Currently, the plaintext content from opened TLS records is handled via
the rbuf code in the TLSv1.3 record layer. Factor this out

Factor out the TLSv1.3 code that handles content from TLS records.

Currently, the plaintext content from opened TLS records is handled via
the rbuf code in the TLSv1.3 record layer. Factor this out and provide a
separate struct tls_content, which knows how to track and manipulate the
content.

This makes the TLSv1.3 code cleaner, however it will also soon also be used
to untangle parts of the legacy record layer.

ok beck@ tb@

show more ...


# 2d0d1bb8 28-Jun-2021 tb <tb@openbsd.org>

Expand info callback support for TLSv1.3

During the TLSv1.3 handshake, update the legacy state and call the
info callback at the appropriate moment. This is done by mapping
the TLSv1.3 states to th

Expand info callback support for TLSv1.3

During the TLSv1.3 handshake, update the legacy state and call the
info callback at the appropriate moment. This is done by mapping
the TLSv1.3 states to the states in the old state machine whenever
that is possible. The callbacks are called at the beginning and end
of the handshake, and just before the state machine advances.

This should fix a periodic warning in logs of tor relays about a
variable that wasn't set although it should have been.

input/ok jsing, ok inoguchi (early version)

show more ...


# d4edc922 21-Mar-2021 jsing <jsing@openbsd.org>

Move the TLSv1.3 handshake struct inside the shared handshake struct.

There are currently three different handshake structs that are in use -
the SSL_HANDSHAKE struct (as S3I(s)->hs), the SSL_HANDSH

Move the TLSv1.3 handshake struct inside the shared handshake struct.

There are currently three different handshake structs that are in use -
the SSL_HANDSHAKE struct (as S3I(s)->hs), the SSL_HANDSHAKE_TLS13 struct
(as S3I(s)->hs_tls13 or ctx->hs in the TLSv1.3 code) and the infamous
'tmp' embedded in SSL3_STATE_INTERNAL (as S3I(s)->tmp)).

This is the first step towards cleaning up the handshake structs so that
shared data is in the SSL_HANDSHAKE struct, with sub-structs for TLSv1.2
and TLSv1.3 specific information. Place SSL_HANDSHAKE_TLS13 inside
SSL_HANDSHAKE and change ctx->hs to refer to the SSL_HANDSHAKE struct
instead of the SSL_HANDSHAKE_TLS13 struct. This allows the TLSv1.3 code
to access the shared handshake data without needing the SSL struct.

ok inoguchi@ tb@

show more ...


# 631a1dd7 05-Jan-2021 tb <tb@openbsd.org>

Add tls13_secret_{init,cleanup}()

These are two functions that will help streamlining various functions
in the TLSv1.3 code that do not need to know about the interna of this
struct.

input/ok jsing


# 607bf314 16-Nov-2020 jsing <jsing@openbsd.org>

Implement exporter for TLSv1.3.

This implements the key material exporter for TLSv1.3, as defined in
RFC8446 section 7.5.

Issue reported by nmathewson on github.

ok inoguchi@ tb@


# 08d6ed5e 30-Jul-2020 tb <tb@openbsd.org>

Add minimal info callback support for TLSv1.3

As abieber@ found the hard way, some python frameworks (twisted, synapse)
thought it a great idea to use the info callback mechanism (designed to
get st

Add minimal info callback support for TLSv1.3

As abieber@ found the hard way, some python frameworks (twisted, synapse)
thought it a great idea to use the info callback mechanism (designed to
get state information about SSL objects) to modify state information such
as setting and verifying the SNI. The switch of TLS_method() to default
to TLSv1.3 broke these contraptions. Further bits of the info callback
mechanism will likely metastasize throughout the TLSv1.3 stack if we
need them, so we only do what's really necessary now.

Lots of debugging, crucial hint and testing by abieber

input & ok jsing

show more ...


# 9b8a142f 03-Jul-2020 tb <tb@openbsd.org>

Improve argument order for the internal tlsext API

Move is_server and msg_type right after the SSL object so that CBS
and CBB and alert come last. This brings these functions more in
line with other

Improve argument order for the internal tlsext API

Move is_server and msg_type right after the SSL object so that CBS
and CBB and alert come last. This brings these functions more in
line with other internal functions and separates state from data.

requested by jsing

show more ...


# 095832a3 06-Jun-2020 beck <beck@openbsd.org>

Implement a rolling hash of the ClientHello message, Enforce RFC 8446
section 4.1.2 to ensure subsequent ClientHello messages after a
HelloRetryRequest messages must be unchanged from the initial
Cli

Implement a rolling hash of the ClientHello message, Enforce RFC 8446
section 4.1.2 to ensure subsequent ClientHello messages after a
HelloRetryRequest messages must be unchanged from the initial
ClientHello.

ok tb@ jsing@

show more ...


# e4de2a75 29-May-2020 jsing <jsing@openbsd.org>

Wire up the servername callback in the TLSv1.3 server.

This makes SNI work correctly with TLSv1.3.

Found the hard way by danj@, gonzalo@ and others.

ok beck@ inoguchi@ tb@


# 3aebe440 23-May-2020 jsing <jsing@openbsd.org>

Provide the option to retry or return after post-handshake messages.

In TLSv1.3 post-handshake handshake messages are used for key updates and
session tickets. These are in-band and mean that when t

Provide the option to retry or return after post-handshake messages.

In TLSv1.3 post-handshake handshake messages are used for key updates and
session tickets. These are in-band and mean that when the upper layer goes
to read application data, we can end up reading and having to process
handshake messages - this option changes whether we retry and read the
next TLS record, or if we return, signalling that we want more data to
be available.

ok beck@ inoguchi@ tb@

show more ...


# 17fca910 19-May-2020 beck <beck@openbsd.org>

Add support for TLS 1.3 server to send certificate status
messages with oscp staples.

ok jsing@ tb@


# 3290fa22 16-May-2020 jsing <jsing@openbsd.org>

Add TLS13_ERR_NO_CERTIFICATE.

This was missed in previous tls13_server.c commit.

ok inoguchi@ tb@


# 6423e56f 11-May-2020 jsing <jsing@openbsd.org>

Propagate record overflows to the record layer and alert.

ok beck@ tb@


12345