summaryrefslogtreecommitdiff
path: root/src/lib/libssl/tls13_client.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Remove cipher_list_by_id.jsing2020-09-111-3/+2
| | | | | | | | | | | | | | | | | When parsing a cipher string, a cipher list is created, before being duplicated and sorted - the second copy being stored as cipher_list_by_id. This is done only so that a client can ensure that the cipher selected by a server is in the cipher list. This is pretty pointless given that most clients are short-lived and that we already had to iterate over the cipher list in order to build the client hello. Additionally, any update to the cipher list requires that cipher_list_by_id also be updated and kept in sync. Remove all of this and replace it with a simple linear scan - the overhead of duplicating and sorting the cipher list likely exceeds that of a simple linear scan over the cipher list (64 maximum, more typically ~9 or so). ok beck@ tb@
* Improve argument order for the internal tlsext APItb2020-07-031-7/+7
| | | | | | | | Move is_server and msg_type right after the SSL object so that CBS and CBB and alert come last. This brings these functions more in line with other internal functions and separates state from data. requested by jsing
* Improve client certificate selection for TLSv1.3tb2020-06-041-16/+80
| | | | | | This allows clients to use EC certificates. ok inoguchi, jsing
* Wire up SSL_MODE_AUTO_RETRY mode to retrying after PHH messages.jsing2020-05-231-1/+4
| | | | ok beck@ inoguchi@ tb@
* Replace SSL_PKEY_RSA_ENC/SSL_PKEY_RSA_SIGN with SSL_PKEY_RSA.jsing2020-05-191-3/+3
| | | | | | | | | | | | | | | | | Some time prior to SSLeay 0.8.1b, SSL_PKEY_RSA_SIGN got added with the intention of handling RSA sign only certificates... this incomplete code had the following comment: /* check to see if this is a signing only certificate */ /* EAY EAY EAY EAY */ And while the comment was removed in 2005, the incomplete RSA sign-only handling has remained ever since. Remove SSL_PKEY_RSA_SIGN and rename SSL_PKEY_RSA_ENC to SSL_PKEY_RSA. While here also remove the unused SSL_PKEY_DH_RSA. ok tb@
* Add support for TLS 1.3 server to send certificate statusbeck2020-05-191-3/+3
| | | | | | messages with oscp staples. ok jsing@ tb@
* Send a decode error alert if a server provides an empty certificate list.jsing2020-05-171-2/+2
| | | | | | | According to RFC 8446 section 4.4.2.4, a client receiving an empty certificate list must abort the handshake with a decode error alert. ok beck@ inoguchi@ tb@ ('it rarely is the alert you'd expect it to be...')
* Ensure that a TLSv1.3 server has provided a certificate.jsing2020-05-161-1/+9
| | | | | | | | | | | | The RFC requires that a server always provide a certificate for authentication. Ensure that this is the case, rather than proceeding and attempting validation. In the case where validation was disabled and the server returned an empty certificate list, this would have previously resulted in a NULL pointer deference. Issue reported by otto@ ok inoguchi@ tb@
* Switch the legacy version to TLS1_2_VERSION when processing server hello.jsing2020-05-131-2/+2
| | | | | | | | | | | | Switch the legacy version when processing the server hello, rather than when the client hello has been sent. This ensures that we accept a response from the server that has a record version other than TLS1_2_VERSION, as is the case where the server is negotiating TLSv1.0 or TLSv1.1. Issue spotted by inoguchi@ ok inoguchi@ tb@
* Provide alert defines for TLSv1.3 and use in the TLSv1.3 code.jsing2020-05-101-17/+17
| | | | | | | | 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@
* Send dummy ChangeCipherSpec messages from the TLSv1.3 client.jsing2020-05-091-1/+5
| | | | | | | | 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@
* Add a middlebox_compat flag and condition session ID randomisation on it.jsing2020-05-091-2/+2
| | | | ok tb@
* Add support for certificate status requests in TLS 1.3 clientbeck2020-05-091-4/+12
| | | | ok jsing@, tb@, inoguchi@
* 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@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-22 12:27:38 +0000