summaryrefslogtreecommitdiff
path: root/src/lib/libssl/tls13_client.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Use cipher suite values instead of IDs.jsing2024-07-221-2/+2
| | | | | | | | | | | | | | | | OpenSSL has had the concept of cipher IDs, which were a way of working around overlapping cipher suite values between SSLv2 and SSLv3. Given that we no longer have to deal with this issue, replace the use of IDs with cipher suite values. In particular, this means that we can stop mapping back and forth between the two, simplifying things considerably. While here, remove the 'valid' member of the SSL_CIPHER. The ssl3_ciphers[] table is no longer mutable, meaning that ciphers cannot be disabled at runtime (and we have `#if 0' if we want to do it at compile time). Clean up the comments and add/update RFC references for cipher suites. ok tb@
* Remove cipher from SSL_SESSION.jsing2024-07-201-2/+2
| | | | | | | | | | | | | | | | For a long time SSL_SESSION has had both a cipher ID and a pointer to an SSL_CIPHER (and not both are guaranteed to be populated). There is also a pointer to an SSL_CIPHER in the SSL_HANDSHAKE that denotes the cipher being used for this connection. Some code has been using the cipher from SSL_SESSION and some code has been using the cipher from SSL_HANDSHAKE. Remove cipher from SSL_SESSION and use the version in SSL_HANDSHAKE everywhere. If resuming from a session then we need to use the SSL_SESSION cipher ID to set the SSL_HANDSHAKE cipher. And we still need to ensure that we update the cipher ID in the SSL_SESSION whenever the SSL_HANDSHAKE cipher changes (this only occurs in a few places). ok tb@
* Convert EVP_Digest{Sign,Verify}* to one-shot for TLSv1.3tb2023-06-101-11/+5
| | | | | | | Using one-shot EVP_DigestSign() and EVP_DigestVerify() is slightly shorter and is needed for Ed25519 support. ok jsing
* Make internal header file names consistenttb2022-11-261-2/+2
| | | | | | | | | | | | | | | | Libcrypto currently has a mess of *_lcl.h, *_locl.h, and *_local.h names used for internal headers. Move all these headers we inherited from OpenSSL to *_local.h, reserving the name *_internal.h for our own code. Similarly, move dtls_locl.h and ssl_locl.h to dtls_local and ssl_local.h. constant_time_locl.h is moved to constant_time.h since it's special. Adjust all .c files in libcrypto, libssl and regress. The diff is mechanical with the exception of tls13_quic.c, where #include <ssl_locl.h> was fixed manually. discussed with jsing, no objection bcook
* Get rid of SSL_CTX_INTERNAL and SSL_INTERNAL.jsing2022-10-021-2/+2
| | | | | | | | These are no longer necessary due to SSL_CTX and SSL now being fully opaque. Merge SSL_CTX_INTERNAL back into SSL_CTX and SSL_INTERNAL back into SSL. Prompted by tb@
* Only permit CCS messages if requesting middlebox compatibility mode.jsing2022-09-111-4/+4
| | | | | | | | Currently the TLSv1.3 client always permits the server to send CCS messages. Be more strict and only permit this if the client is actually requesitng middlebox compatibility mode. ok tb@
* Deduplicate peer certificate chain processing code.jsing2022-08-171-22/+4
| | | | | | | | | | | | | | Rather than reimplement this in each TLS client and server, deduplicate it into a single function. Furthermore, rather than dealing with the API hazard that is SSL_get_peer_cert_chain() in this code, simply produce two chains - one that has the leaf and one that does not. SSL_get_peer_cert_chain() can then return the appropriate one. This also moves the peer cert chain from the SSL_SESSION to the SSL_HANDSHAKE, which makes more sense since it is not available on resumption. ok tb@
* Provide QUIC encryption levels.jsing2022-07-241-5/+5
| | | | | | | | | | | | QUIC wants to know what "encryption level" handshake messages should be sent at. Provide an ssl_encryption_level_t enum (via BoringSSL) that defines these (of course quictls decided to make this an OSSL_ENCRYPTION_LEVEL typedef, so provide that as well). Wire these through to tls13_record_layer_set_{read,write}_traffic_key() so that they can be used in upcoming commits. ok tb@
* Simplify tls13_server_encrypted_extensions_recvtb2022-07-221-8/+2
| | | | | | | We can rely on tlsext_client_parse() to set the alert, so no need to do this in the error path. ok jsing
* Rename uses 'curve' to 'group' and rework tls1 group API.tb2022-07-021-2/+2
| | | | | | | | | | This reworks various tls1_ curve APIs to indicate success via a boolean return value and move the output to an out parameter. This makes the caller code easier and more consistent. Based on a suggestion by jsing ok jsing
* Cleanup/simplify ssl_cert_type()jsing2022-02-031-2/+2
| | | | | | | | Remove the X509 argument as it is unused - this was passed so that ssl_cert_type() can get the public key from the X509 object if the EVP_PKEY argument is NULL, however this is never the case. ok tb@
* Remove peer_pkeys from SSL_SESSION.jsing2022-01-111-12/+8
| | | | | | | | | | peer_pkeys comes from some world where peers can send multiple certificates - in fact, one of each known type. Since we do not live in such a world, get rid of peer_pkeys and simply use peer_cert instead (in both TLSv1.2 and TLSv1.3, both clients and servers can only send a single leaf (aka end-entity) certificate). ok inoguchi@ tb@
* Rename 'peer' to 'peer_cert' in SSL_SESSION.jsing2022-01-111-4/+4
| | | | | | | The 'peer' member of SSL_SESSION is the leaf/end-entity certificate provided by our peer. Rename it since 'peer' on its own is unhelpful. ok inoguchi@ tb@
* Merge SESS_CERT into SSL_SESSION.jsing2022-01-081-10/+8
| | | | | | | There is no reason for SESS_CERT to exist - remove it and merge its members into SSL_SESSION for the time being. More clean up to follow. ok inoguchi@ tb@
* Rename CERT to SSL_CERT and CERT_PKEY to SSL_CERT_PKEY.jsing2022-01-081-6/+6
| | | | | | | Nearly all structs in libssl start with an SSL_ suffix, rename CERT and CERT_PKEY for consistency. ok inoguchi@ tb@
* Rename tls13_key_share to tls_key_share.jsing2022-01-051-9/+9
| | | | | | | | | In preparation to use the key share code in both the TLSv1.3 and legacy stacks, rename tls13_key_share to tls_key_share, moving it into the shared handshake struct. Further changes will then allow the legacy stack to make use of the same code for ephemeral key exchange. ok inoguchi@ tb@
* Fold SSL_SESSION_INTERNAL back into SSL_SESSION.jsing2021-10-251-6/+6
| | | | ok beck@ tb@
* Provide a way to determine our maximum legacy version.jsing2021-10-231-5/+5
| | | | | | | | | | | | | | With the introduction of TLSv1.3, we need the ability to determine our maximum legacy version and to track our peer's maximum legacy version. This is needed for both the TLS record layer when using TLSv1.3, plus it is needed for RSA key exhange in TLS prior to TLSv1.3, where the maximum legacy version is incorporated in the pre-master secret to avoid downgrade attacks. This unbreaks RSA KEX for the TLS client when the non-version specific method is used with TLSv1.0 or TLSv1.1 (clearly no one does this). ok tb@
* Provide a ssl_sigalg_for_peer() function and use in the TLSv1.3 code.jsing2021-06-291-6/+3
| | | | | | | | | | | | Provide an ssl_sigalg_for_peer() function that knows how to figure out which signature algorithm should be used for a peer provided signature, performing appropriate validation to ensure that the peer provided value is suitable for the protocol version and key in use. In the TLSv1.3 code, this replaces the need for separate calls to lookup the sigalg from the peer provided value, then perform validation. ok inoguchi@ tb@
* Move the RSA-PSS check for TLSv1.3 to ssl_sigalg_pkey_ok().jsing2021-06-291-2/+2
| | | | | | | | Also, rather than passing in a check_curve flag, pass in the SSL * and handle version checks internally to ssl_sigalg_pkey_ok(), simplifying the callers. ok inoguchi@ tb@
* Require a ServerHello following a HelloRetryRequest to use the same cipher.jsing2021-06-291-2/+11
| | | | | | | | | RFC 8446 section 4.1.4 requires that the client ensure the cipher suite in the TLSv1.3 HelloRetryRequest and subsequent ServerHello is the same. Reported via GitHub issue #675. ok inoguchi@ tb@
* Track the sigalgs used by ourselves and our peer.jsing2021-06-271-3/+4
| | | | | | | | | | | Move the sigalg pointer from SSL_HANDSHAKE_TLS13 to SSL_HANDSHAKE, naming it our_sigalg, adding an equivalent peer_sigalg. Adjust the TLSv1.3 code that records our signature algorithm. Add code to record the signature algorithm used by our peer. Needed for upcoming API additions. ok tb@
* Change ssl_sigalgs_from_value() to perform sigalg list selection.jsing2021-06-271-3/+3
| | | | | | | | | Rather that passing in a sigalg list at every call site, pass in the appropriate TLS version and have ssl_sigalgs_from_value() perform the sigalg list selection itself. This allows the sigalg lists to be made internal to the sigalgs code. ok tb@
* Rename ssl_sigalg() to ssl_sigalg_from_value().jsing2021-06-271-3/+3
| | | | | | | This makes the code more self-documenting and avoids the ambiguity between ssl_sigalg the struct and ssl_sigalg the function. ok tb@
* Rewrap a comment to avoid an overlong linetb2021-06-081-3/+3
|
* Make local header inclusion consistent.jsing2021-05-161-3/+2
| | | | | Consistently include local headers in the same location, using the same grouping/sorting across all files.
* Avoid pulling ssl_sigalgs.h in via ssl_locl.h.jsing2021-05-161-1/+2
| | | | | Forward declare struct sigalg in ssl_locl.h and avoid including ssl_sigalgs.h. Explicitly include ssl_sigalgs.h where it is needed.
* Move finished and peer finished to the handshake struct.jsing2021-03-291-8/+6
| | | | | | | | | This moves the finish_md and peer_finish_md from the 'tmp' struct to the handshake struct, renaming to finished and peer_finished in the process. This also allows the remaining S3I(s) references to be removed from the TLSv1.3 client and server. ok inoguchi@ tb@
* Rename new_cipher to cipher.jsing2021-03-241-5/+5
| | | | | | | | This is in the SSL_HANDSHAKE struct and is what we're currently negotiating, so there is really nothing more "new" about the cipher than there is the key block or other parts of the handshake data. ok inoguchi@ tb@
* Move the TLSv1.3 handshake struct inside the shared handshake struct.jsing2021-03-211-57/+55
| | | | | | | | | | | | | | | | There are currently three different handshake structs that are in use - the SSL_HANDSHAKE struct (as S3I(s)->hs), the SSL_HANDSHAKE_TLS13 struct (as S3I(s)->hs_tls13 or ctx->hs in the TLSv1.3 code) and the infamous 'tmp' embedded in SSL3_STATE_INTERNAL (as S3I(s)->tmp)). This is the first step towards cleaning up the handshake structs so that shared data is in the SSL_HANDSHAKE struct, with sub-structs for TLSv1.2 and TLSv1.3 specific information. Place SSL_HANDSHAKE_TLS13 inside SSL_HANDSHAKE and change ctx->hs to refer to the SSL_HANDSHAKE struct instead of the SSL_HANDSHAKE_TLS13 struct. This allows the TLSv1.3 code to access the shared handshake data without needing the SSL struct. ok inoguchi@ tb@
* Improve internal version handling.jsing2021-03-101-8/+12
| | | | | | | | | | | | | | | | | | Add handshake fields for our minimum TLS version, our maximum TLS version and the TLS version negotiated during the handshake. Initialise our min/max versions at the start of the handshake and leave these unchanged. The negotiated TLS version is set in the client once we receive the ServerHello and in the server at the point we select the highest shared version. Provide an ssl_effective_version() function that returns the negotiated TLS version if known, otherwise our maximum TLS version - this is effectively what is stored in s->version currently. Convert most of the internal code to use one of these three version fields, which greatly simplifies code (especially in the TLS extension handling code). ok tb@
* Only use TLS versions internally (rather than both TLS and DTLS versions).jsing2021-02-251-2/+2
| | | | | | | | | | | | | | DTLS protocol version numbers are the 1's compliment of human readable TLS version numbers, which means that newer versions decrease in value and there is no direct mapping between TLS protocol version numbers and DTLS protocol version numbers. Rather than having to deal with this internally, only use TLS versions internally and map between DTLS and TLS protocol versions when necessary. Rename functions and variables to use 'tls_version' when they contain a TLS version (and never a DTLS version). ok tb@
* Fix bizarre punctuation and capitalization in a comment.tb2021-02-221-2/+2
|
* Simplify version checks in the TLSv1.3 clienttb2021-02-221-22/+10
| | | | | | | | | | | | Ensure that the server announced TLSv1.3 (and nothing higher) in the supported_versions extension. In that case, the legacy_version must be TLSv1.2 according to RFC 8446, 4.1.3 and 4.2.1. This commit also removes some unreachable code which is a remnant of very early TLSv1.3 code from before the legacy fallback was introduced. Simplify a few checks and adjust some comments nearby. ok jsing
* Use tls13_secret_{init,cleanup}() for the finished_keytb2021-01-061-5/+5
| | | | | | | | This trades an array on the stack for a dynamically allocated secret in tls13_{client,server}_finished_send() but has the benefit of wiping out an intermediate secret on function exit. ok jsing
* Use consistent names in tls13_{client,server}_finished_{recv,send}().jsing2021-01-051-6/+6
| | | | | | | | | In tls13_{client,server}_finished_recv() we use verify_data_len, which makes more sense than hmac_len. Use the same name in tls13_{client,server}_finished_send(), keeping things consistent between functions. ok tb@
* Fix SSL_get{,_peer}_finished() with TLSv1.3tb2020-12-141-1/+14
| | | | | | | | | | As reported by Steffen Ullrich and bluhm, the Finished tests in p5-Net-SSLeay's t/local/43_misc_functions.t broke with with TLSv1.3. The reason for this is that we don't copy the MDs over to the SSL, so the API functions can't retrieve them. This commit fixes this part of the test (one unrelated test still fails). ok inoguchi jsing
* 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@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-18 02:47:13 +0000