summaryrefslogtreecommitdiff
path: root/src/lib/libssl/tls13_server.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Convert legacy server to tls_key_share.jsing2022-01-071-3/+3
| | | | | | | | | | | This requires a few more additions to the DHE key share code - we need to be able to either set the DHE parameters or specify the number of key bits for use with auto DHE parameters. Additionally, we need to be able to serialise the DHE parameters to send to the client. This removes the infamous 'tmp' struct from ssl3_state_internal_st. ok inoguchi@ tb@
* Rename tls13_key_share to tls_key_share.jsing2022-01-051-6/+6
| | | | | | | | | 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@
* Correct SSL_get_peer_cert_chain() when used with the TLSv1.3 stack.jsing2021-12-261-3/+6
| | | | | | | | | Due to a wonderful API inconsistency, a client includes the peer's leaf certificate in the stored certificate chain, while a server does not. Found due to a haproxy test failure reported by Ilya Shipitsin. ok tb@
* libssl: stop reaching into the X509 struct and simplify some code bytb2021-10-311-6/+2
| | | | | | using X509_get_key_usage(). ok beck jsing
* 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-1/+2
| | | | | | | | | | | | | | 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@
* Use X509_STORE_CTX_get0_chain() instead of grabbing the chain directlytb2021-10-231-2/+2
| | | | | | out of the X509_STORE_CTX. ok jsing
* Merge SSL_METHOD_INTERNAL into SSL_METHOD.jsing2021-07-011-3/+3
| | | | | | | Now that SSL_METHOD is opaque and in internal headers, we can remove SSL_METHOD_INTERNAL by merging it back into SSL_METHOD. 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@
* 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@
* Indent all labels with a single space.jsing2021-06-111-2/+2
| | | | | | This ensures that diff reports the correct function prototype. Prompted by tb@
* TLSv1.3 server: avoid sending alerts in legacy recordstb2021-06-081-3/+4
| | | | | | | | | As soon as we know that we're dealing with a TLSv1.3 client, set the legacy version in the record layer to 0x0303 so that we send alerts with the correct record version. Previously we would send early alerts with a record version of 0x0300. ok jsing
* Make local header inclusion consistent.jsing2021-05-161-2/+1
| | | | | 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-6/+6
| | | | | | | | 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-46/+46
| | | | | | | | | | | | | | | | 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-4/+5
| | | | | | | | | | | | | | | | | | 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@
* Add support for SSL_get_shared_ciphers() in TLSv1.3tb2021-01-091-1/+5
| | | | | | | | | As reported by Steffen Ullrich and bluhm, since enabling TLSv1.3 server some tests fail in t/local/07_sslecho.c of security/p5-Net-SSLeay due to missing support for SSL_get_shared_ciphers(). This fixes the parts related to shared ciphers. ok beck inoguchi jsing
* Rename two local variables ssl to s for consistencytb2021-01-071-7/+7
| | | | | | | | | | | | | In our tls13_* files, we use SSL *s for local variables and SSL *ssl for function arguments. This is odd, but probably the result of finger memory. We intended to use ssl everywhere. Be that as it may, all local variables except in two functions ended up being called s, so align the two outliers with that. As noted by jsing, this is not ideal either as in tls13_legacy_servername_process() the ssl_ctx is now inconsistent. Renaming all s to ssl is a substantial amount of unnecessary churn at a moment that isn't ideal, so we have to live with that. ok bcook inoguchi 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@
* Use legacy verifier when building auto chains.jsing2021-01-051-1/+3
| | | | | | | | | | | | | | | | | | The new verifier builds all chains, starting with the shortest possible path. It also does not currently return partial chains. Both of these things conflict with auto chain, where we want to build the longest possible chain (to include all intermediates, and probably the root unnecessarily), as well as using an incomplete chain when a trusted chain is not known. Depending on software configuration, we can end up building a chain consisting only of a leaf certificate, rather than a longer chain. This results in auto chain not including intermediates, which is undesireable. For now, switch auto chain building to use the legacy verifier. This should resolve the issues encountered by ajacoutot@ with sendmail. 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
* typo & punctuation in commenttb2020-11-171-3/+3
|
* Implement auto chain for the TLSv1.3 server.jsing2020-11-111-1/+23
| | | | | | | | | Apparently OpenLDAP relies on this craziness to provide intermediates, rather than specifying the chain directly like a normal TLS server would. Issue noted by sthen@ and Bernard Spil, who both also tested this diff. ok tb@
* Improve argument order for the internal tlsext APItb2020-07-031-5/+5
| | | | | | | | 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
* Switch the order of the two tests in tls13_client_hello_required_extensionstb2020-06-251-9/+9
| | | | to match the order they are listed in the RFC. No functional change.
* Enforce restrictions for ClientHello extensionstb2020-06-241-1/+44
| | | | | | | | | | | | | | | RFC 8446 section 9.2 imposes some requirements on the extensions sent in the ClientHello: key_share and supported_groups must either both be present or both be absent. If no pre_shared_key was sent, the CH must contain both signature_algorithms and supported_groups. If either of these conditions is violated, servers must abort the handshake with a missing_extensions alert. Add a function that enforces this. If we are going to enforce that clients send an SNI, we can also do this in this function. Fixes failing test case in tlsfuzzer's test-tls13-keyshare-omitted.py ok beck inoguchi jsing
* Implement a rolling hash of the ClientHello message, Enforce RFC 8446beck2020-06-061-2/+46
| | | | | | | | section 4.1.2 to ensure subsequent ClientHello messages after a HelloRetryRequest messages must be unchanged from the initial ClientHello. ok tb@ jsing@
* Align tls13_server_select_certificate() withtb2020-06-041-3/+7
| | | | | | tls13_client_select_certificate(). ok inoguchi
* distracting whitespacetb2020-06-021-5/+5
|
* Improve server certificate selection for TLSv1.3.jsing2020-05-291-16/+83
| | | | | | | | | This allows an EC certificate to be selected and used, if the client sigalgs would allow it. With feedback from tb@ ok inoguchi@ tb@
* Wire up the servername callback in the TLSv1.3 server.jsing2020-05-291-1/+16
| | | | | | | | This makes SNI work correctly with TLSv1.3. Found the hard way by danj@, gonzalo@ and others. ok beck@ inoguchi@ tb@
* Wire up SSL_MODE_AUTO_RETRY mode to retrying after PHH messages.jsing2020-05-231-1/+4
| | | | ok beck@ inoguchi@ tb@
* Do not assume that server_group != 0 or tlsext_supportedgroups != NULLtb2020-05-231-1/+3
| | | | | | | | | | | | | | | | implies that we're dealing with a HRR in the extension handling code. Explicitly check that we're in this situation by inspecting the flag in the handshake context. Add missing error checks and send the appropriate alerts. The hrr flag needs to be unset after parsing the client hello retry to avoid breaking the server hello handling. All this is far from ideal, but better than nothing. The correct fix would likely be to make the message type available but that would need to be part of a more extensive rearchitecture of the extension handling. Discussed at length with jsing
* Ensure we only attach an ocsp staple to a leaf certificate, becausebeck2020-05-221-2/+7
| | | | | | | | | | | | for the moment that is all we support. fixes an issue where gnuTLS cares that mistmatching staples come back on the certs in the chain. This should be fixed correctly later by associating the staple to the individual certs rather than the ssl, so this is temporary. running on www@. ok tb@, "got that's oopy but an interim ok" jsing@
* Actually set the hrr flag when sending a HelloRetryRequest.jsing2020-05-211-1/+3
| | | | | | | | | Without this, when SNI is in use the second ClientHello will result in an error. Found the hard way by sthen@. ok sthen@ 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@
* Avoid sending an empty certificate list from the TLSv1.3 server.jsing2020-05-161-5/+8
| | | | | | | A TLSv1.3 server must always send a certificate - return an error and abort the handshake if none is available. ok inoguchi@ tb@
* Switch back to the legacy stack where the maximum is less than TLSv1.3.jsing2020-05-131-2/+2
| | | | | | | | | This allows a server configured to only support TLSv1.2 and earlier, to correctly handle connections from a TLSv1.3 capable client. Issue reported by pvk@ ok inoguchi@ tb@
* Set the record layer legacy version from the TLSv1.3 server.jsing2020-05-111-1/+5
| | | | | | This will be used to handle record version checks. ok tb@
* Use ssl_get_new_session() in the TLSv1.3 server.jsing2020-05-111-4/+3
| | | | | | | | This correctly handles session being non-NULL and sets up a few more things, including ssl_version. Also stop setting the ssl_version to the server_version, as this is only used on the client side. ok tb@
* Send dummy ChangeCipherSpec messages from the TLSv1.3 servertb2020-05-101-1/+24
| | | | | | | | | | | | | | | If the client has requested middle box compatibility mode by sending a non-empty legacy_session_id, the server must send a dummy CCS right after its first handshake message. This means right after ServerHello or HelloRetryRequest. Two important improvements over the backed-out diffr: make sure that First: client and server can send their dummy CCS at the correct moment (right before the next flight or right after the current flight). Second: as jsing noted, we also need to deal with the corner case that tls13_send_dummy_ccs() can return TLS13_IO_WANT_POLLOUT. with/ok jsing
* Honour SSL_VERIFY_FAIL_IF_NO_PEER_CERT in the TLSv1.3 server.jsing2020-05-101-6/+10
| | | | ok beck@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-04-25 21:47:37 +0000