summaryrefslogtreecommitdiff
path: root/src/lib/libssl/tls13_server.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* 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@
* Provide alert defines for TLSv1.3 and use in the TLSv1.3 code.jsing2020-05-101-11/+11
| | | | | | | | 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@
* Back out server side CCS sending. It breaks TLSv1.3 client communicationtb2020-05-091-24/+1
| | | | | | | | with TLSv1.2 servers, since it makes clients send their dummy CCS too early... There's an obvious but dirty bandaid which I can't bring myself to applying - this business is already disgusting enough. Issue found the hard way by sthen
* Send dummy ChangeCipherSpec messages from the TLSv1.3 servertb2020-05-091-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. ok jsing
* Make the test for the legacy_compression_method vector in the ClientHellotb2020-05-091-12/+7
| | | | | | | | stricter. Previously, we would accept any vector if it advertised the "null" compression method. RFC 8446 4.1.2 specifies that the only legal vector has length one and contains a zero byte for the null method. ok jsing
* Add support for HelloRetryRequests in the TLSv1.3 server.jsing2020-05-091-8/+41
| | | | ok inoguchi@ tb@
* crazy whitespace on one linetb2020-05-091-2/+2
|
* Refactor tls13_server_hello_sent().jsing2020-05-091-30/+36
| | | | | | | | | Split the record protection engagement code into a separate tls13_server_engage_record_protection() function and call this from tls13_server_hello_sent(). Also move some functions around to keep the logical ordering/grouping. ok inoguchi@ tb@ (as part of a larger diff)
* Move legacy stack interfacing functions into tls13_legacy.c.jsing2020-04-281-95/+4
| | | | | | No functional change. ok inoguchi@ tb@
* Shuffle some functions around.jsing2020-04-271-228/+221
| | | | | | | | | | 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@
* Switch to NEGOTIATED when using WITHOUT_HRR.jsing2020-04-251-4/+9
| | | | | | | | | | This ensures that we remain in a valid handshake state in the TLSv1.3 server. Ideally we would not switch to NEGOTIATED until after record protection has been enabled, but we'll revisit this later. Issue noted by inoguchi@ ok tb@
* Improve TLSv1.3 state machine for HelloRetryRequest handling.jsing2020-04-221-6/+6
| | | | | | | | | | | | | | | | | | | 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@
* Handle TLSv1.3 key shares other than X25519 on the server side.jsing2020-04-211-11/+15
| | | | | | | | Previously we would only select an X25519 key share from the client, ignoring any others. Change this so that we will select the first of the key shares that matches one of our supported groups. ok beck@ inoguchi@ tb@
* Generate client key share using our preferred group.jsing2020-04-171-2/+2
| | | | | | | | 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@
* Use ctx->hs->secrets rather than the S3I(s) version.jsing2020-03-101-2/+2
| | | | ok inoguchi@ tb@
* Remove some unnecessary handshake enums/functions.jsing2020-03-101-13/+1
| | | | | | | Both session tickets and key updates are post-handshake handshake messages, which were originally included in the handshake code. 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-3/+1
| | | | ok inoguchi jsing
* Remove the hello retry request processing code that was previously added.jsing2020-02-051-8/+2
| | | | | | | 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/+12
| | | | | | | 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 server side support for requesting client certificates in tls 1.3beck2020-01-261-4/+173
| | | | ok jsing@
* Add client certificate support for tls 1.3beck2020-01-261-13/+1
| | | | ok jsing@
* Move pad and verify context into tls13_lib.cbeck2020-01-261-46/+5
| | | | ok jsing@
* Complete the initial TLSv1.3 implementation.jsing2020-01-241-12/+296
| | | | ok beck@ tb@
* Store the legacy session identifier from the ClientHello so we can actuallyjsing2020-01-241-1/+10
| | | | | | echo it. ok beck@ tb@
* Switch to encrypted records in the TLSv1.3 server.jsing2020-01-241-2/+74
| | | | | | | This adds code to perform key derivation and set the traffic keys once the ServerHello message has been sent, enabling encrypted records. ok beck@ tb@
* Implement client hello processing in the TLSv1.3 server.jsing2020-01-231-5/+49
| | | | ok beck@
* Correct several issues in the current TLSv1.3 server code.jsing2020-01-231-6/+15
| | | | | | | | | | | | | Correct the parsing of the client hello support versions extension. This has one or more values, rather than just the single selected version. Allocate an SSL_SESSION - this is unused currently, but is needed as soon as we start parsing extensions. Also, pull the cipher suites list off correctly - this is u16 prefixed, not u8. ok beck@
* Implement sending client certificate requests for 1.3 serverbeck2020-01-231-1/+13
| | | | ok jsing@
* Build the encrypted extensions for the 1.3 serverbeck2020-01-231-2/+8
| | | | ok jsing@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-20 06:50:49 +0000