summaryrefslogtreecommitdiff
path: root/src/lib/libssl/tls13_handshake.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Rework the exit path of tls13_handshake_recv_action()tb2024-02-031-12/+14
| | | | | | | | | | | | | If an error occurs in action->recv() for a handshake that needs to downgrade to legacy TLS, the artistic exit path led to hiding the error under TLS13_IO_USE_LEGACY. Rework the exit path to be easier to follow, preserving behavior except that the error can no longer be masked. Detailed analysis and initial diff by Masaru Masuda. Fixes https://github.com/libressl/openbsd/issues/146 ok beck
* Make internal header file names consistenttb2022-11-261-2/+2
| | | | | | | | | | | | | | | | Libcrypto currently has a mess of *_lcl.h, *_locl.h, and *_local.h names used for internal headers. Move all these headers we inherited from OpenSSL to *_local.h, reserving the name *_internal.h for our own code. Similarly, move dtls_locl.h and ssl_locl.h to dtls_local and ssl_local.h. constant_time_locl.h is moved to constant_time.h since it's special. Adjust all .c files in libcrypto, libssl and regress. The diff is mechanical with the exception of tls13_quic.c, where #include <ssl_locl.h> was fixed manually. discussed with jsing, no objection bcook
* Drop unused KeyUpdate from debug printftb2022-04-191-3/+1
| | | | | | | | | The handshake state machine does not handle key updates since that's a post-handshake handshake message. This is code under #ifdef TLS13_DEBUG and if it is ever to be reused in tls13_handshake_msg.c, that will have to be revisited. ok inoguchi jsing
* Implement flushing for TLSv1.3 handshakes.jsing2021-09-161-3/+29
| | | | | | | | | | | | | | | 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@
* Merge SSL_METHOD_INTERNAL into SSL_METHOD.jsing2021-07-011-2/+2
| | | | | | | Now that SSL_METHOD is opaque and in internal headers, we can remove SSL_METHOD_INTERNAL by merging it back into SSL_METHOD. ok tb@
* Use the order action->sender == ctx->mode everywhere for consistency.tb2021-06-281-3/+3
|
* ctx->alert is not a boolean, so compare it explicitly against 0.tb2021-06-281-3/+3
|
* Expand info callback support for TLSv1.3tb2021-06-281-6/+184
| | | | | | | | | | | | | 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)
* Move the TLSv1.3 handshake struct inside the shared handshake struct.jsing2021-03-211-5/+7
| | | | | | | | | | | | | | | | 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@
* Add minimal info callback support for TLSv1.3tb2020-07-301-1/+10
| | | | | | | | | | | | | | 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
* Remove const modifier in return type of tls13_handshake_active_state()tb2020-06-021-3/+3
| | | | | | which make no sense as pointed out by gcc on sparc64. ok jsing
* Send dummy ChangeCipherSpec messages from the TLSv1.3 servertb2020-05-101-1/+14
| | | | | | | | | | | | | | | If the client has requested middle box compatibility mode by sending a non-empty legacy_session_id, the server must send a dummy CCS right after its first handshake message. This means right after ServerHello or HelloRetryRequest. Two important improvements over the backed-out diffr: make sure that First: client and server can send their dummy CCS at the correct moment (right before the next flight or right after the current flight). Second: as jsing noted, we also need to deal with the corner case that tls13_send_dummy_ccs() can return TLS13_IO_WANT_POLLOUT. with/ok jsing
* Provide alert defines for TLSv1.3 and use in the TLSv1.3 code.jsing2020-05-101-3/+3
| | | | | | | | Rather than using a mess of SSL_AL_*, SSL_AD_*, SSL3_AD_* and TLS1_AD_* defines, provide our own TLS13_ALERT_* defines and use those. This also provides the alerts that are new to TLSv1.3. ok beck@
* Provide an easy way to get debug information from TLSv1.3 handshakes.jsing2020-05-101-2/+57
| | | | | | This makes it easier to debug TLSv1.3 handshake failures. "Yes please!" tb@, ok beck@
* Back out server side CCS sending. It breaks TLSv1.3 client communicationtb2020-05-091-8/+1
| | | | | | | | with TLSv1.2 servers, since it makes clients send their dummy CCS too early... There's an obvious but dirty bandaid which I can't bring myself to applying - this business is already disgusting enough. Issue found the hard way by sthen
* Send dummy ChangeCipherSpec messages from the TLSv1.3 servertb2020-05-091-1/+8
| | | | | | | | | If the client has requested middle box compatibility mode by sending a non-empty legacy_session_id, the server must send a dummy CCS right after its first handshake message. This means right after ServerHello or HelloRetryRequest. ok jsing
* Send dummy ChangeCipherSpec messages from the TLSv1.3 client.jsing2020-05-091-1/+7
| | | | | | | | When operating in middlebox compatibility mode, the TLSv1.3 client needs to send a dummy ChangeCipherSpec message immediately before its second flight of handshake messages (when early data is not offered). ok tb@
* Pull the sending of alerts up into tls13_handshake_perform().jsing2020-05-091-14/+11
| | | | | | | | | | This fixes the case where a send function signals that an alert should be sent, then returns failure. Previously the failure would be propagated up, without the alert being sent. Issued noted by tb@ ok tb@
* Add const to TLS1.3 internal vectorsinoguchi2020-05-021-12/+12
| | | | ok tb@
* tls13_handshake internal functions to static in libsslinoguchi2020-04-291-11/+12
| | | | ok jsing@ tb@
* Improve TLSv1.3 state machine for HelloRetryRequest handling.jsing2020-04-221-16/+18
| | | | | | | | | | | | | | | | | | | The state machine currently handles the HelloRetryRequest case by using WITH_HRR - in other words, we're explicitly indicating when we transition to the alternate path. The problem here is that we do not know if we're going to receive a ServerHello or a HelloRetryRequest until we process the message. This means that the ServerHello processing code has to handle both types of messages. The state machine and associated processing code becomes cleaner if we flip this around so that we assume we are going to receive a HelloRetryRequest and upon discovering that it is not, trigger WITHOUT_HRR and hand off to the ServerHello processing function. In particular, this makes the logic much more straight forward on the server side, when adding support for HRR. With feedback from tb@ ok tb@
* Remove some unnecessary handshake enums/functions.jsing2020-03-101-7/+1
| | | | | | | Both session tickets and key updates are post-handshake handshake messages, which were originally included in the handshake code. ok inoguchi@ tb@
* Pull the handshake message transcript code into its own function.jsing2020-02-051-6/+12
| | | | | | This is soon going to be used in the TLSv1.3 client code. ok tb@
* Rework tls13_legacy_handshake_message_{recv,sent}_cb() to usetb2020-02-051-3/+3
| | | | | | their own CBS as a preparation for upcoming HRR diffs. ok jsing
* Remove unused stub implementation of tls13_accept(). The correcttb2020-01-291-11/+1
| | | | | | and used version is in tls13_server.c. ok inoguchi jsing
* Revert change to certificate request check from r1.45.jsing2020-01-251-3/+3
| | | | | | This code was correct, it was the entry in the table that was incorrect. ok beck@
* Preserve the transcript hash for the client finished message,beck2020-01-251-2/+3
| | | | | | and correct the message type for certificate request. ok jsing@
* Support legacy message callbacks. First step for SSL_set_msg_callback(3)tb2020-01-251-1/+7
| | | | | | support. Makes openssl s_client -msg work for handshake messages. ok beck jsing
* Correct backwards test so that we may accept a certificate requstbeck2020-01-251-3/+3
| | | | | | from the server. ok jsing@
* Complete the initial TLSv1.3 implementation.jsing2020-01-241-1/+2
| | | | ok beck@ tb@
* Preserve the TLS transcript at additional points.jsing2020-01-241-9/+23
| | | | | | | | | This is needed for the TLSv1.3 server and will also be needed for client certificate authentication. Note that we preserve on receive but before recording the new handshake message, whereas we preserve on send after recording the new handshake message. ok tb@
* Switch to encrypted records in the TLSv1.3 server.jsing2020-01-241-1/+2
| | | | | | | This adds code to perform key derivation and set the traffic keys once the ServerHello message has been sent, enabling encrypted records. ok beck@ tb@
* Pass a CBB to TLSv1.3 send handlers.jsing2020-01-231-6/+11
| | | | | | | This avoids the need for each send handler to call tls13_handshake_msg_start() and tls13_handshake_msg_finish(). ok beck@ tb@
* Pass a handshake message content CBS to TLSv1.3 receive handlers.jsing2020-01-221-6/+16
| | | | | | | | | This avoids every receive handler from having to get the handshake message content itself. Additionally, pull the trailing data check up so that each receive handler does not have to implement it. This makes the code more readable and reduces duplication. ok beck@ tb@
* The legacy_record_version must be set to TLS1_2_VERSION excepttb2020-01-221-1/+2
| | | | | | | | | in the ClientHello where it may be set to TLS1_VERSION. Use the minimal supported version to decide whether we choose to do so or not. Use a sent hook to set it back TLS1_2_VERSION right after the ClientHello message is on the wire. ok beck jsing
* Add alert processing in tls client code, by adding alert to thebeck2020-01-211-2/+7
| | | | | | | tls13 context, and emiting the alert at the upper layers when the lower level code fails ok jsing@, tb@
* Add alerts to the tls 1.3 record layer and handshake layerbeck2020-01-201-5/+3
| | | | ok jsing@, inoguchi@, tb@
* Move the TLSv1.3 server message handling stubs.jsing2019-11-171-124/+1
|
* By design, our state machine is a DAG contrary to the state machine intb2019-04-051-1/+23
| | | | | | | | | | | | the spec. To avoid the obvious loop in the RFC's state machine, we added a CLIENT_HELLO_RETRY state which is a second ClientHello with special rules. There is, however, no state to react to this second client hello. This adds a matching SERVER_HELLO_RETRY state to the handshakes table. This means in particular that the WITH_HRR state cannot be set in tls13_server_hello_recv(), so remove this now dead check. ok jsing
* Zap two dead #defines that were unused since jsing deleted thetb2019-04-051-5/+1
| | | | | | record_type member of the tls13_handshake_action struct. ok jsing
* Implement legacy fallback for the TLS 1.3 client.jsing2019-04-041-1/+4
| | | | | | | If the Server Hello received indicates that the server did not negotiate TLS 1.3, fallback to the original TLS client implementation. ok bcook@, tb@
* Correct return value handling in tls13_handshake_recv_action().jsing2019-03-171-2/+4
| | | | | | | | The recv action handler returns success/failure, rather than a TLS13_IO_* value, which is what tls13_handshake_recv_action() needs to return. Failure previously mapped to TLS13_IO_EOF, which is not ideal. ok tb@
* Automatically complete the handshake from tls13_legacy_{read,write}_bytes()jsing2019-02-281-1/+2
| | | | | | | | | | | | | | If the TLS handshake has not been completed, automatically complete the handshake as part of the read/write call, implementing the current SSL_read()/SSL_write() behaviour. Once the TLS handshake is completed we push a WANT_POLLIN or WANT_POLLOUT back up to the caller, since some applications appear to incorrectly call SSL_read() or SSL_write(), rather than repeating the previous call. This can lead to attempts to read data that does not exist, since the WANT_POLLIN was actually triggered as part of the handshake. ok inoguchi@ tb@
* Remove unused record_type from TLSv1.3 handshake actions.jsing2019-02-281-16/+1
| | | | ok tb@
* Add a handshake action sent handler and use it for client finished.jsing2019-02-251-1/+6
| | | | | | | | | | The write traffic key needs to be changed to the client application traffic key after the client finished message has been sent. The send handler generates the client finished message, however we cannot switch keys at this stage since the client finished message has not yet been protected by the record layer. ok tb@
* Notify the record layer upon handshake completion.jsing2019-02-141-2/+4
| | | | ok tb@
* Handle finished messages in TLSv1.3 client.jsing2019-02-131-13/+1
| | | | | | | This adds support for processing of the server finished message and generation of the client finished message. ok tb@
* Implement handling of Certificate and CertificateVerify messages.jsing2019-02-111-30/+1
| | | | | | | This allows the TLS 1.3 client to process the certificates that the server has sent and verify that the server has possession of the private key. ok tb@
* Preserve the transcript hash at specific stages of the TLSv1.3 handshake.jsing2019-02-101-1/+11
| | | | | | | | | There are various points where we need the hash of all messages prior to the current message. Support this by having the handshake code preserve the transcript hash prior to recording the current message, which avoids the need to sprinkle this throughout multiple handlers. ok inoguchi@ tb@
* Implement processing of EncryptedExtensions in the TLS 1.3 client.jsing2019-02-071-7/+1
| | | | ok bcook@ tb@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-19 20:24:49 +0000