summaryrefslogtreecommitdiff
path: root/src/lib/libssl/tls13_client.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* 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@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-08-12 05:05:44 +0000