summaryrefslogtreecommitdiff
path: root/src/lib/libssl/tls13_client.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Move legacy stack interfacing functions into tls13_legacy.c.jsing2020-04-281-102/+4
| | | | | | No functional change. ok inoguchi@ tb@
* Rename tls13_client_synthetic_handshake_message() and move to tls13_lib.c.jsing2020-04-281-45/+2
| | | | | | | | The server-side will need to use the same function. No functional change. ok inoguchi@ tb@
* Shuffle some functions around.jsing2020-04-271-101/+107
| | | | | | | | | | Move functions so that they are in the order that the TLSv1.3 messages are processed. While here, also move tls13_client_end_of_early_data_send() from tls13_client.c to tls13_server.c. No functional change. ok beck@ tb@
* Improve TLSv1.3 state machine for HelloRetryRequest handling.jsing2020-04-221-37/+73
| | | | | | | | | | | | | | | | | | | 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@
* Consolidate TLSv1.3 constants.jsing2020-04-211-11/+1
| | | | | | | Move all of the TLSv1.3 constants to the top of tls13_lib.c. Also mark these all as const so that they end up in .rodata rather than .data. ok tb@
* Generate client key share using our preferred group.jsing2020-04-171-12/+15
| | | | | | | | Generate a client key share using our preferred group, rather than always using X25519. This means that the key share group can be controlled via SSL{_CTX,}_set1_groups() and SSL{_CTX,}_set1_groups_list(). ok beck@
* Ensure legacy session ID is persistent during client TLS session.jsing2020-04-081-9/+14
| | | | | | | | | | | | Generate an unpredictable 32-byte legacy session ID during client initialisation, rather than when the ClientHello message is being created. Otherwise in the case of a HelloRetryRequest the legacy session ID values will differ between the first and second ClientHello messages, which is not permitted by the RFC. Fixes an issue talking TLSv1.3 to smtp.mail.yahoo.com. ok beck@
* Send a zero-length session identifier if TLSv1.3 is not enabled.jsing2020-04-061-4/+7
| | | | | | | | | If the maximum version is less than TLSv1.3, send a zero-length session identifier (matching the behaviour of the legacy TLS stack), rather than a 32 byte random identifier. The 32 byte random identifier is only needed for "compatibility" mode in TLSv1.3. ok beck@
* Use ctx->hs->secrets rather than the S3I(s) version.jsing2020-03-101-2/+2
| | | | ok inoguchi@ tb@
* According to RFC 8446, Section 4.4.4, recipients of incorrect Finishedtb2020-02-231-2/+2
| | | | | | | messages must terminate the connection with a decrypt_error alert, so replace the use of the deprecated decryption_failed alert accordingly. ok beck inoguchi jsing
* drop unused include <openssl/curve25519.h>tb2020-02-181-2/+1
| | | | ok inoguchi jsing
* Add support for handling hello retry requests in the TLSv1.3 client.jsing2020-02-061-5/+100
| | | | | | | | | In the case of a hello retry request, we need to replace the client hello with a synthetic handshake message, switch key share to that selected by the server, build and send a new client hello, then process the resulting server hello. ok tb@
* Refactor the server hello processing code in the TLSv1.3 client.jsing2020-02-051-21/+42
| | | | | | | | | | | | | Use flags to signal the need to switch to the legacy client and to identify a hello retry request. This allows the caller to take appropriate action, rather than trying to do this in the parsing/processing code. Split the key deriviation and record protection engagement code into a separate function, both for readability and reuse. Change handshake states outside of the processing code. ok tb@
* Remove the hello retry request processing code that was previously added.jsing2020-02-051-57/+14
| | | | | | | This got added to the wrong functions (server side, not client) - swap the now unimplemented send/recv functions between client and server. ok tb@
* Free the transcript as soon as we initialise the transcript hash.jsing2020-02-041-1/+2
| | | | | | | | Unlike TLSv1.2 there is only a single hash in use, hence as soon as we know what the hash is and have initialised the transcript hash, we can free the transcript buffers. ok inoguchi@ tb@
* Provide struct/functions for handling TLSv1.3 key shares.jsing2020-01-301-8/+13
| | | | | | | Pull out the key share handling code and provide a clean/self contained interface. This will make it easier to support groups other than X25519. ok beck@ inoguchi@ tb@
* If the TLSv1.3 code has not recorded an error and something already existsjsing2020-01-291-1/+2
| | | | | | | | on the error stack, refrain from pushing an 'unknown' error on the stack. This should allow libcrypto errors (including bio) to be visible, where we have nothing better to offer. ok tb@
* When switching back to a legacy client or server, ensure we reset thejsing2020-01-261-1/+2
| | | | | | | | handshake function pointer. Fixes an isssue found by jca@ with OpenVPN. ok beck@ tb@
* Add client certificate support for tls 1.3beck2020-01-261-2/+148
| | | | ok jsing@
* Move pad and verify context into tls13_lib.cbeck2020-01-261-20/+5
| | | | ok jsing@
* Only perform the downgrade check if our max version is less than TLSv1.3.jsing2020-01-251-15/+17
| | | | | | | Issue noticed by kn@ when talking to a TLSv1.3 capable mail server, but with smtpd capping max version to TLSv1.2. ok beck@
* It is possible to receive a pre-TLSv1.3 alert in response to a TLSv1.3jsing2020-01-251-1/+7
| | | | | | | | | | | | client hello. Allow pre-TLSv1.3 alerts (including warnings) to be received before the server hello message. Disallow pre-TLSv1.3 alerts as soon as we know that we are using TLSv1.3. Noticed by ajacoutot@ while connecting to www.openprinting.org. ok tb@
* When certificate validation fails, we must send a DECRYPT_ERROR alertbeck2020-01-231-3/+6
| | | | | | according to RFC8446. ok jsing@
* Add checking int the client to check the magic values which arebeck2020-01-231-1/+17
| | | | | | | set by a 1.3 server when it downgrades to tls 1.2 or 1.1 as per RFC 8446 section 4.1.3 ok jsing@
* Save the legacy session id in the client, and enforce that it is returnedbeck2020-01-231-6/+13
| | | | | | the same from the server. ok jsing@ tb@
* Pass a CBB to TLSv1.3 send handlers.jsing2020-01-231-16/+5
| | | | | | | 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-55/+26
| | | | | | | | | 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@
* Send alerts on certificate verification failures of server certsbeck2020-01-221-2/+2
| | | | ok tb@
* After the ClientHello has been sent or received and before the peer'stb2020-01-221-1/+4
| | | | | | | | Finished message has been received, a change cipher spec may be received and must be ignored. Add a flag to the record layer struct and set it at the appropriate moments during the handshake so that we will ignore it. ok jsing
* Correctly set the legacy version when TLSv1.3 is building a client hello.jsing2020-01-221-4/+11
| | | | | | | The legacy version field is capped at TLSv1.2, however it may be lower than this if we are only choosing to use TLSv1.0 or TLSv1.1. ok beck@ tb@
* The legacy_record_version must be set to TLS1_2_VERSION excepttb2020-01-221-1/+12
| | | | | | | | | 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 minimal support for hello retry request for RFC conformance.beck2020-01-221-1/+64
| | | | | | We currently don't support sending a modified clienthello ok jsing@ tb@
* Correct legacy fallback for TLSv1.3 client.jsing2020-01-211-7/+21
| | | | | | | | | When falling back to the legacy TLS client, in the case where a server has sent a TLS record that contains more than one handshake message, we also need to stash the unprocessed record data for later processing. Otherwise we end up with missing handshake data. ok beck@ tb@
* Add alert processing in tls client code, by adding alert to thebeck2020-01-211-16/+21
| | | | | | | tls13 context, and emiting the alert at the upper layers when the lower level code fails ok jsing@, tb@
* Provide an error framework for use with the TLSv1.3 code.jsing2020-01-201-1/+3
| | | | | | | This is based on the libtls error handling code, but adds machine readable codes and subcodes. We then map these codes back to libssl error codes. ok beck@ inoguchi@
* tls13_connect() should be static.jsing2019-11-171-2/+2
|
* Fix backoff to legacy when in client auth mode.beck2019-11-171-2/+2
| | | | ok jsing@
* Drop back to the legacy tls method if we are doing client authenticaitonbeck2019-11-171-1/+7
| | | | | | from a tls 1.3 connection, for now. ok jsing@
* By design, our state machine is a DAG contrary to the state machine intb2019-04-051-4/+1
| | | | | | | | | | | | 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
* Implement legacy fallback for the TLS 1.3 client.jsing2019-04-041-6/+81
| | | | | | | 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@
* Defer sigalgs selection until the certificate is known.jsing2019-03-251-2/+2
| | | | | | | | | | | | | Previously the signature algorithm was selected when the TLS extension was parsed (or the client received a certificate request), however the actual certificate to be used is not known at this stage. This leads to various problems, including the selection of a signature algorithm that cannot be used with the certificate key size (as found by jeremy@ via ruby regress). Instead, store the signature algorithms list and only select a signature algorithm when we're ready to do signature generation. Joint work with beck@.
* Set the SSL state as part of tls13_legacy_connect().jsing2019-02-281-2/+5
| | | | | | | | Set the SSL state to SSL_ST_CONNECT during the TLSv1.3 handshake and to SSL_ST_OK once the handshake completes, since some applications currently rely on this information to function correctly. ok inoguchi@ tb@
* Add a handshake action sent handler and use it for client finished.jsing2019-02-251-9/+14
| | | | | | | | | | 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@
* Correct a few error returns.jsing2019-02-251-4/+4
|
* Switch to application traffic keys as appropriate.jsing2019-02-141-1/+17
| | | | | | | | | Switch the read traffic key to the server application traffic key once the server finished message has been processed. Switch the write traffic key to the client application traffic key after sending the client finished message. ok tb@
* Split tls13_record_layer_set_traffic_keys() into two separate functions.jsing2019-02-141-3/+5
| | | | | | | | | This allows the read traffic key to be set independently of the write traffic key. This will become necessary for KeyUpdate handling, however also allows for switching to application traffic keys at more appropriate stages of the handshake. ok tb@
* Clean up some pesky trailing whitespace.jsing2019-02-131-10/+10
|
* Handle finished messages in TLSv1.3 client.jsing2019-02-131-1/+130
| | | | | | | 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-1/+213
| | | | | | | 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@
* Rename tls1_handshake_hash*() to tls1_transcript_hash*().jsing2019-02-091-3/+3
| | | | | | | | | While handshake hash is correct (in as far as it is a hash of handshake messages), using tls1_transcript_hash*() aligns them with the naming of the tls1_transcript*() functions. Additionally, the TLSv1.3 specification uses Transcript-Hash and "transcript hash", which this matches. ok inoguchi@ tb@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-20 06:50:49 +0000