#
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@
|