summaryrefslogtreecommitdiff
path: root/src/lib/libssl/tls13_client.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* 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@
* 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-04-26 07:21:14 +0000