IABSD.fr/src/lib/libssl

Branch :


Log

Author Commit Date CI Message
30342cdf 2020-07-14 18:55:59 Dedup the use legacy stack code. ok inoguchi@ tb@
a759cde3 2020-07-14 18:47:50 Revert the TLSv1.3 version switching fix/hack. This is no longer necessary since the TLS_method() now supports TLSv1.3. Reverts r1.211 of ssl_lib.c. ok beck@ inoguchi@ tb@
25aa477e 2020-07-07 19:31:11 Remove some unnecessary function pointers from SSL_METHOD_INTERNAL. ssl_version is completely unused and get_timeout is the same everywhere. ok beck@ inoguchi@ tb@
94149d15 2020-07-07 19:24:23 Enable TLSv1.3 for the generic TLS_method(). This can be done now that we have both TLSv1.3 client and server. ok beck@ inoguchi@ tb@
accddc9b 2020-07-03 07:17:26 zap trailing whitespace on one line
c54b8396 2020-07-03 04:51:59 Make the message type available to the extension functions Some TLS extensions need to be treated differently depending on the handshake message they appear in. Over time, various workarounds and hacks were used to deal with the unavailability of the message type in these functions, but this is getting fragile and unwieldy. Having the message type available will enable us to clean this code up and will allow simple fixes for a number of bugs in our handling of the status_request extension reported by Michael Forney. This approach was suggested a while ago by jsing. ok beck jsing
9b8a142f 2020-07-03 04:12:50 Improve argument order for the internal tlsext API 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
2c901073 2020-06-25 07:35:05 Switch the order of the two tests in tls13_client_hello_required_extensions to match the order they are listed in the RFC. No functional change.
3b4c6944 2020-06-24 18:04:33 Make tls13_legacy_shutdown() match ssl3_shutdown() semantics. When first called, queue and send a close notify, before returning 0 or 1 to indicate if a close notify has already been received from the peer. If called again only attempt to read a close notify if there is no pending application data and only read one record from the wire. In particular, this avoids continuing to read application data where the peer continues to send application data. Issue noted by naddy@ with ftp(1). ok jca@ tb@
56fdfbb6 2020-06-24 07:28:38 Enforce restrictions for ClientHello extensions 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
47f04e97 2020-06-19 21:26:40 We inherited the constant time CBC padding removal from BoringSSL, but missed a subsequent fix for an off-by-one in that code. If the first byte of a CBC padding of length 255 is mangled, we don't detect that. Adam Langley's BoringSSL commit 80842bdb44855dd7f1dde64a3fa9f4e782310fc7 Fixes the failing tlsfuzzer lucky 13 test case. ok beck inoguchi
4d97159a 2020-06-09 16:53:52 The check_includes step is incorrect dependency management model for how our tree gets built. If this was done in all the libraries (imagine sys/dev), it would disrupt the development process hugely. So it should not be done here either. use 'make includes' by hand instead.
095832a3 2020-06-06 01:40:08 Implement a rolling hash of the ClientHello message, Enforce RFC 8446 section 4.1.2 to ensure subsequent ClientHello messages after a HelloRetryRequest messages must be unchanged from the initial ClientHello. ok tb@ jsing@
22c2c18e 2020-06-05 18:14:05 Use IANA allocated GOST ClientCertificateTypes. IANA has allocated numbers for GOST ClientCertificateType. Use them in addition to private values (left in place for compatibility). Diff from Dmitry Baryshkov <dbaryshkov@gmail.com> Sponsored by ROSA Linux ok inoguchi@ tb@
a431b810 2020-06-05 17:58:32 Stop sending GOST R 34.10-94 as a CertificateType. GOST R 34.10-94 is an obsolete certificate type, unsupported by LibreSSL and by the rest of current software, so there is no point in sending in the CertificateTypes. Diff from Dmitry Baryshkov <dbaryshkov@gmail.com> Sponsored by ROSA Linux ok inoguchi@ tb@
c18d223a 2020-06-05 17:55:24 Handle GOST in ssl_cert_dup(). Add missing case entry for SSL_PKEY_GOST01. Diff from Dmitry Baryshkov <dbaryshkov@gmail.com> Sponsored by ROSA Linux ok inoguchi@ tb@
c2a7ee20 2020-06-05 17:53:26 Enable GOST_SIG_FORMAT_RS_LE when verifying certificate signatures. GOST cipher suites requires that CertVerify signatures be generated in a special way (see ssl3_send_client_kex_gost(), ssl3_get_cert_verify()). However, the GOST_SIG_FORMAT_RS_LE flag was not passed in case of TLS 1.2 connections (because they use different code path). Set this flag on GOST PKEYs. Diff from Dmitry Baryshkov <dbaryshkov@gmail.com> Sponsored by ROSA Linux ok inoguchi@ tb@
8121cb11 2020-06-04 18:46:21 Align tls13_server_select_certificate() with tls13_client_select_certificate(). ok inoguchi
2414b9ec 2020-06-04 18:41:42 Improve client certificate selection for TLSv1.3 This allows clients to use EC certificates. ok inoguchi, jsing
debbd173 2020-06-04 18:06:43 mention that TLS_method(3) also supports TLSv1.3; tb@ OKed this part of a larger diff from inoguchi@
7a625857 2020-06-02 13:57:09 Remove const modifier in return type of tls13_handshake_active_state() which make no sense as pointed out by gcc on sparc64. ok jsing
7d26cb49 2020-06-02 04:50:17 distracting whitespace
0cd4ba86 2020-06-01 19:51:31 Split the handling of post handshake handshake messages into its own recv function. This simplifies tls13_recod_layer_read_internal() greatly and makes the phh handling easier to reason about since the code is no longer glued to the right hand edge of the terminal. ok jsing
fc1fe0f6 2020-06-01 08:04:02 Send an illegal_parameter alert if a client sends us invalid DH key shares. Previously we would fail and just close the pipe. Fixes the remaining failing test-dhe-rsa-key-exchange-with-bad-messages.py tests of tlsfuzzer. ok beck (earlier version) jsing
4c4033b4 2020-06-01 07:59:49 Add a mechanism to set an alert in those parts of the read half of the record layer that don't do I/O themselves. Use this mechanism to send a record overflow alert for messages that have overlong plaintext or inner plaintext. Fixes most of the remaining record-layer-limits failures of tlsfuzzer. ok jsing
b9f2fbd8 2020-05-31 18:03:32 Replace ssl_max_server_version() with ssl_downgrade_max_version() Replace the only occurrence of ssl_max_server_version() with a call to ssl_downgrade_max_version() and remove ssl_max_server_version(). ok beck@ tb@
3231e218 2020-05-31 16:36:35 Correct downgrade sentinels when a version pinned method is in use. Previously only the enabled protocol versions were considered, however we also have to consider the method in use which may be version pinned. Found the hard way by danj@ with haproxy and force-tlsv12. ok beck@ inoguchi@ tb@
06121fa9 2020-05-29 18:00:10 Improve server certificate selection for TLSv1.3. This allows an EC certificate to be selected and used, if the client sigalgs would allow it. With feedback from tb@ ok inoguchi@ tb@
d69bc5b9 2020-05-29 17:54:58 Handle the case where we receive a valid 0 byte application data record. In this situation we cannot return zero bytes, as that signals EOF. Rather we need to return TLS13_IO_WANT_POLLIN so tell the caller to call us again, at which point we'll pull up the next record. ok tb@
e4de2a75 2020-05-29 17:47:30 Wire up the servername callback in the TLSv1.3 server. This makes SNI work correctly with TLSv1.3. Found the hard way by danj@, gonzalo@ and others. ok beck@ inoguchi@ tb@
ddd788df 2020-05-29 17:39:42 Mop up servername_done, which is unused. ok beck@ inoguchi@ tb@
209714ae 2020-05-26 19:45:58 minor cleanup ahead of the following work: remove references to the SSL protocol which is no longer supported and use .Xr rather than .Fn for functions documented elsewhere
8d0f08c2 2020-05-26 16:54:50 Add additional length checks for TLSv1.3 plaintext and inner plaintext. Reminded by and ok beck@
a4908857 2020-05-24 15:13:22 Fix some stylistic nits from jsing. ok jsing
19d72426 2020-05-23 17:13:24 Enforce that SNI hostnames be correct as per rfc 6066 and 5980. Correct SNI alerts to differentiate between illegal parameter and an unknown name. ok tb@`
4a4f8340 2020-05-23 12:14:52 Enable SSL_MODE_AUTO_RETRY by default. In TLSv1.2 and earlier, when an application goes to read application data, handshake messages may be received instead, when the peer has triggered renegotation. A similar thing occurs in TLSv1.3 when key updates are triggered or the server sends new session tickets. Due to the SSL_read() API there is no way to indicate that we got no application data, instead after processing the in-band handshake messages it would be normal to return SSL_ERROR_WANT_READ and have the caller call SSL_read() again. However, various applications expect SSL_read() to return with either application data or a fatal error, when used on a blocking socket. These applications do not play well with TLSv1.3 post-handshake handshake messages (PHH), as they fail to handle SSL_ERROR_WANT_READ. The same code is also broken in the case of a TLSv1.2 or older renegotiation, however these are less likely to be encountered. Such code should set SSL_MODE_AUTO_RETRY in order to avoid these issues. Contrary to the naming, SSL_MODE_AUTO_RETRY does not actually retry in every case - it retries following handshake messages in the application data stream (i.e. renegotiation and PHH messages). This works around the unretried SSL_read() on a blocking socket case, however in the case where poll/select is used with blocking sockets, the retry will likely result in the read blocking after the handshake messages are processed. Rather than pushing for broken code to be fixed, OpenSSL decided to enable SSL_MODE_AUTO_RETRY by default, instead breaking code that does poll or select on blocking sockets (like s_client and s_server). Unfortunately we get to follow suit. ok beck@ inoguchi@ tb@
29323c26 2020-05-23 11:58:46 Wire up SSL_MODE_AUTO_RETRY mode to retrying after PHH messages. ok beck@ inoguchi@ tb@
3aebe440 2020-05-23 11:57:41 Provide the option to retry or return after post-handshake messages. In TLSv1.3 post-handshake handshake messages are used for key updates and session tickets. These are in-band and mean that when the upper layer goes to read application data, we can end up reading and having to process handshake messages - this option changes whether we retry and read the next TLS record, or if we return, signalling that we want more data to be available. ok beck@ inoguchi@ tb@
10b56f99 2020-05-23 11:30:12 fix a confusingly wrapped line
ec90fc19 2020-05-23 08:47:19 Do not assume that server_group != 0 or tlsext_supportedgroups != NULL 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
92931873 2020-05-22 02:37:27 Ensure we only attach an ocsp staple to a leaf certificate, because 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@
17b56951 2020-05-21 19:43:40 Simplify: transform a dangling else into an early return and unindent a bunch of code. Suggested by jsing
9bb5a347 2020-05-21 19:28:32 Make ssl_set_cert_masks() more consistent and closer to readable. Prompted by tb@ ok tb@
fa57fcd6 2020-05-21 19:27:22 Avoid a shadowing issue by renaming cbs and cbb to cbb_hs and cbb_hs, respectively. Discussed with jsing
83aac8c8 2020-05-21 19:15:54 A failure of tls13_handshake_msg_new() could lead to a NULL deref in the following tls13_handshake_msg_start() call. Add a check. Stop clobbering the ctx's hs_msg variable, use a local variable instead. ok beck jsing
e87fcc94 2020-05-21 18:34:34 Actually set the hrr flag when sending a HelloRetryRequest. Without this, when SNI is in use the second ClientHello will result in an error. Found the hard way by sthen@. ok sthen@ tb@
3a2e4416 2020-05-20 14:58:33 Revert 1.43 - this fix for PHH in blocking mode breaks SSL_accept and SSL_connect in blocking mode. While this will probably need a rethink, until we land on a solution for PHH in blocking mode, the breakage this causes is visible in real things, and we've only managed to hit the PHH breakage in a test case. ok tb@
16933562 2020-05-19 16:35:20 Replace SSL_PKEY_RSA_ENC/SSL_PKEY_RSA_SIGN with SSL_PKEY_RSA. 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@
455c43a2 2020-05-19 02:16:16 Only send ocsp staples if the client asked for ocsp certificate status. noticed by dlg@ on www.openbsd.org with curl. ok dlg@
17fca910 2020-05-19 01:30:34 Add support for TLS 1.3 server to send certificate status messages with oscp staples. ok jsing@ tb@
799f07ab 2020-05-17 19:07:15 Send alerts back correctly when handling key shares, including sending back illegal parameter if our phh key share request type is not 0 or 1. ok jsing@ tb@
60729982 2020-05-17 18:22:30 Free handshake message correctly, noticed by tb@ ok tb@ jsing@
a1c5a4de 2020-05-17 14:26:15 Send a decode error alert if a server provides an empty certificate list. 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...')
acf76599 2020-05-16 18:00:29 Return TLS13_IO_WANT_POLLIN after processing post-handshake messages. After post-handshake handshake messages have been processed, we need to return TLS13_IO_WANT_POLLIN rather than TLS13_IO_WANT_RETRY. The latter will cause us to try to read another TLS record, when there may not be any data available - this will then block in the case of a blocking read. This reverts part of r1.25. Issue noticed by inoguchi@ ok beck@ tb@
e480694f 2020-05-16 14:44:55 Ensure that a TLSv1.3 server has provided a certificate. 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@
3290fa22 2020-05-16 14:42:35 Add TLS13_ERR_NO_CERTIFICATE. This was missed in previous tls13_server.c commit. ok inoguchi@ tb@
004f5acb 2020-05-16 14:40:53 Avoid sending an empty certificate list from the TLSv1.3 server. A TLSv1.3 server must always send a certificate - return an error and abort the handshake if none is available. ok inoguchi@ tb@
648c9d53 2020-05-13 17:55:34 Fix pesky whitespace.
de3b0c62 2020-05-13 17:54:26 Remove a no longer relevant XXX comment.
35a46db7 2020-05-13 17:53:15 Switch back to the legacy stack where the maximum is less than TLSv1.3. 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@
853fbeeb 2020-05-13 17:51:48 Switch the legacy version to TLS1_2_VERSION when processing server hello. 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@
03d04020 2020-05-12 20:12:44 there should only be one i in gratuitous
676765a2 2020-05-11 18:19:19 Enable the TLSv1.3 server. ok beck@ tb@
6423e56f 2020-05-11 18:08:11 Propagate record overflows to the record layer and alert. ok beck@ tb@
204f36c2 2020-05-11 18:03:51 Add record version checks. When legacy version is below TLSv1.2 ensure that the record version is SSL3/TLS, however when the legacy version is set to TLSv1.2 require this specifically. ok beck@ tb@
e095aa7e 2020-05-11 17:49:46 Set the record layer legacy version from the TLSv1.3 server. This will be used to handle record version checks. ok tb@
4af36d07 2020-05-11 17:46:46 Provide an alert sent record layer callback. Use this to push an error on to the SSL error stack so that we report the details of the alert that we sent, rather than failing with an unknown error. ok tb@
a234fc1e 2020-05-11 17:28:33 Move the record layer callbacks into a struct. This makes the code more readable, requires less code churn when adding a new callback and is likely to avoid bugs due to function argument ordering. ok beck@ inoguchi@ tb@
05c39422 2020-05-11 17:23:35 Use ssl_get_new_session() in the TLSv1.3 server. 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@
e0a52b2d 2020-05-10 17:13:29 Send dummy ChangeCipherSpec messages from the TLSv1.3 server 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
94ac48a6 2020-05-10 16:59:51 Honour SSL_VERIFY_FAIL_IF_NO_PEER_CERT in the TLSv1.3 server. ok beck@
c957d00c 2020-05-10 16:56:11 Provide alert defines for TLSv1.3 and use in the TLSv1.3 code. 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@
be03a99e 2020-05-10 14:22:51 Provide an easy way to get debug information from TLSv1.3 handshakes. This makes it easier to debug TLSv1.3 handshake failures. "Yes please!" tb@, ok beck@
d875fefd 2020-05-10 14:17:47 Use size_t for OCSP response length. The OCSP response length is currently an integer, which is overloaded with -1 meaning "unset". Use a size_t for the OCSP response length and infer unset from the OCSP response being NULL. This makes code more readable, simpler and less error prone. ok beck@
834e13ab 2020-05-10 14:07:01 Only reset TLS extension state when parsing client hello or server hello. With TLSv1.3 we end up parsing extensions from more than just these two messages. This can result in variables (like the selected alpn) being freed when things still need them. ok tb@
daf57a6e 2020-05-10 14:03:14 Correct tlsext_ocsp_resplen check. This variable is currently overloaded - a value of -1 means that it is "unset" and any other value is a length. ok tb@
673b36ad 2020-05-09 20:38:19 Back out server side CCS sending. It breaks TLSv1.3 client communication 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
c07686ce 2020-05-09 16:52:15 Forcibly ensure that only PSS may be used with RSA in TLS 1.3. This prevents us from incorrectly choosing a PKCS1 based signature if the client advertises support for them but also prefers them to PSS such as appears to be the case with gnuTLS. ok jsing@
ac4a6cd8 2020-05-09 16:43:05 Send dummy ChangeCipherSpec messages from the TLSv1.3 server 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
ef59065f 2020-05-09 15:47:11 Send dummy ChangeCipherSpec messages from the TLSv1.3 client. 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@
10aeffa3 2020-05-09 15:39:18 Correct return value check to handle TLS13_IO_EOF case.
0e548c8f 2020-05-09 15:30:21 Add a middlebox_compat flag and condition session ID randomisation on it. ok tb@
4770065f 2020-05-09 15:05:50 Add support for certificate status requests in TLS 1.3 client ok jsing@, tb@, inoguchi@
cccb618b 2020-05-09 14:02:24 Make the test for the legacy_compression_method vector in the ClientHello 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
9cf2d9d3 2020-05-09 13:54:19 Drop a redundant test. It's effectively doing the same test twice and if the two lengths differed, the later CBS_write_bytes() would correctly fail anyway. Discussed with jsing
380a8bef 2020-05-09 13:51:44 On receiving an overlong session ID terminate with an illegal_parameter alert. Found with tlsfuzzer. ok jsing
f62c22f4 2020-05-09 10:51:55 Add support for HelloRetryRequests in the TLSv1.3 server. ok inoguchi@ tb@
d1afb25a 2020-05-09 10:17:58 crazy whitespace on one line
549636aa 2020-05-09 08:39:44 Pull the sending of alerts up into tls13_handshake_perform(). This fixes the case where a send function signals that an alert should be sent, then returns failure. Previously the failure would be propagated up, without the alert being sent. Issued noted by tb@ ok tb@
7752f9fd 2020-05-09 08:26:16 Refactor tls13_server_hello_sent(). 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)
edb9ff5f 2020-05-07 18:56:09 On receiving a handshake or alert record with empty inner plaintext, terminate the connection with an unexpected_message alert. See RFC 8446 section 5.4. Found with tlsfuzzer hint/ok jsing
5fcf7458 2020-05-03 15:57:25 Accept two ChangeCipherSpec messages during a TLSv1.3 handshake. In compatibility mode, a TLSv1.3 server MUST send a dummy CCS message immediately after its first handshake message. This is normally after the ServerHello message, but it can be after the HelloRetryRequest message. As such we accept one CCS message from the server during the handshake. However, it turns out that in the HelloRetryRequest case, Facebook's fizz TLSv1.3 stack sends CCS messages after both the HelloRetryRequest message and the ServerHello message. This is unexpected and as far as I'm aware, no other TLSv1.3 implementation does this. Unfortunately the RFC is rather ambiguous here, which probably means it is not strictly an RFC violation. Relax the CCS message handling to allow two dummy CCS messages during a TLSv1.3. This makes our TLSv1.3 client work with Facebook Fizz when HRR is triggered. Issue discovered by inoguchi@ and investigated by tb@. ok deraadt@ tb@
60e65ff7 2020-05-02 00:31:54 Add const to TLS1.3 internal vectors ok tb@
e92a9438 2020-05-02 00:30:55 Add const to TLS1.3 internal vectors ok tb@
17b8aec1 2020-04-29 01:22:28 tls13_record_layer internal functions to static in libssl We might remove static again for further regress around record layer in the future. ok jsing@ tb@
1887072c 2020-04-29 01:16:49 tls13_handshake internal functions to static in libssl ok jsing@ tb@
8a834dad 2020-04-28 20:37:22 Move legacy stack interfacing functions into tls13_legacy.c. No functional change. ok inoguchi@ tb@
70bdc49b 2020-04-28 20:30:40 Rename tls13_client_synthetic_handshake_message() and move to tls13_lib.c. The server-side will need to use the same function. No functional change. ok inoguchi@ tb@
d0445389 2020-04-27 20:15:17 Shuffle some functions around. 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@
f113bc44 2020-04-25 18:06:28 Switch to NEGOTIATED when using WITHOUT_HRR. 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@