summaryrefslogtreecommitdiffstats
path: root/lib/libssl/tls13_client.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* 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@
* Provide a reference from the TLSv1.3 context to the handshake state.jsing2019-02-091-18/+21
| | | | | | | This allows ctx->hs to be used throughout the TLSv1.3 code, rather than S3I(ctx->ssl)->hs_tls13. ok inoguchi@ tb@
* Implement processing of EncryptedExtensions in the TLS 1.3 client.jsing2019-02-071-1/+27
| | | | ok bcook@ tb@
* Implement parsing and processing of TLSv1.3 ServerHello messages.jsing2019-02-041-1/+178
| | | | ok tb@
* Provide the initial TLSv1.3 client implementation.jsing2019-01-211-0/+139
Move tls13_connect() to a new tls13_client.c file and provide a legacy wrapper to it, which allocates a struct tls_ctx if necessary. Also move tls13_client_hello_send() to tls13_client.c and actual implement the building of a client hello. ok tb@
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.