summaryrefslogtreecommitdiff
path: root/src/lib (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* A failure of tls13_handshake_msg_new() could lead to a NULL dereftb2020-05-211-11/+15
| | | | | | | | | 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
* 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@
* Revert 1.43 - this fix for PHH in blocking mode breaks SSL_accept andbeck2020-05-201-2/+2
| | | | | | | | | | | 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@
* new manual page for PKCS7_set_content(3) and PKCS7_content_new(3);schwarze2020-05-204-5/+127
| | | | OK beck@ tb@
* Replace SSL_PKEY_RSA_ENC/SSL_PKEY_RSA_SIGN with SSL_PKEY_RSA.jsing2020-05-198-46/+31
| | | | | | | | | | | | | | | | | 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@
* Only send ocsp staples if the client asked for ocsp certificate status.beck2020-05-191-1/+2
| | | | | | noticed by dlg@ on www.openbsd.org with curl. ok dlg@
* Add support for TLS 1.3 server to send certificate statusbeck2020-05-195-15/+38
| | | | | | messages with oscp staples. ok jsing@ tb@
* Send alerts back correctly when handling key shares, includingbeck2020-05-171-8/+19
| | | | | | | sending back illegal parameter if our phh key share request type is not 0 or 1. ok jsing@ tb@
* Free handshake message correctly, noticed by tb@beck2020-05-171-2/+2
| | | | ok tb@ jsing@
* As done everywhere else, use a local version of MINIMUM() and avoidderaadt2020-05-175-21/+21
| | | | conflict against a potential define min() from some other scope.
* 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...')
* Return TLS13_IO_WANT_POLLIN after processing post-handshake messages.jsing2020-05-161-2/+2
| | | | | | | | | | | | | 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@
* 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@
* Add TLS13_ERR_NO_CERTIFICATE.jsing2020-05-162-3/+7
| | | | | | This was missed in previous tls13_server.c commit. ok inoguchi@ 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@
* document PKCS7_set_type(3);schwarze2020-05-163-3/+123
| | | | OK beck@, who was amused by the "darkly comic value of reading" it
* Fix pesky whitespace.jsing2020-05-131-2/+2
|
* Remove a no longer relevant XXX comment.jsing2020-05-131-3/+1
|
* 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@
* 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@
* there should only be one i in gratuitoustb2020-05-121-3/+3
|
* Enable the TLSv1.3 server.jsing2020-05-111-1/+5
| | | | ok beck@ tb@
* Propagate record overflows to the record layer and alert.jsing2020-05-113-6/+8
| | | | ok beck@ tb@
* Add record version checks.jsing2020-05-113-18/+28
| | | | | | | | 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@
* 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@
* Provide an alert sent record layer callback.jsing2020-05-114-8/+29
| | | | | | | | 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@
* Move the record layer callbacks into a struct.jsing2020-05-113-35/+33
| | | | | | | | 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@
* 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-103-3/+41
| | | | | | | | | | | | | | | 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-103-8/+16
| | | | ok beck@
* Provide alert defines for TLSv1.3 and use in the TLSv1.3 code.jsing2020-05-107-65/+97
| | | | | | | | 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@
* Provide an easy way to get debug information from TLSv1.3 handshakes.jsing2020-05-102-3/+61
| | | | | | This makes it easier to debug TLSv1.3 handshake failures. "Yes please!" tb@, ok beck@
* Use size_t for OCSP response length.jsing2020-05-108-27/+35
| | | | | | | | | 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@
* Only reset TLS extension state when parsing client hello or server hello.jsing2020-05-101-5/+7
| | | | | | | | 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@
* Correct tlsext_ocsp_resplen check.jsing2020-05-101-2/+2
| | | | | | | This variable is currently overloaded - a value of -1 means that it is "unset" and any other value is a length. ok tb@
* Back out server side CCS sending. It breaks TLSv1.3 client communicationtb2020-05-093-34/+3
| | | | | | | | 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
* Forcibly ensure that only PSS may be used with RSA in TLS 1.3.beck2020-05-091-2/+8
| | | | | | | 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@
* Send dummy ChangeCipherSpec messages from the TLSv1.3 servertb2020-05-093-3/+34
| | | | | | | | | 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
* Send dummy ChangeCipherSpec messages from the TLSv1.3 client.jsing2020-05-094-6/+45
| | | | | | | | 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@
* Correct return value check to handle TLS13_IO_EOF case.jsing2020-05-091-2/+2
|
* Add a middlebox_compat flag and condition session ID randomisation on it.jsing2020-05-093-4/+7
| | | | ok tb@
* catch the other place this needs to changebeck2020-05-091-2/+2
|
* now that 3.1.1 is out the door as a stable release bump the developmentbeck2020-05-091-2/+2
| | | | version to 3.2.0
* Add support for certificate status requests in TLS 1.3 clientbeck2020-05-094-12/+81
| | | | ok jsing@, tb@, inoguchi@
* 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
* Drop a redundant test. It's effectively doing the same test twicetb2020-05-091-3/+2
| | | | | | | and if the two lengths differed, the later CBS_write_bytes() would correctly fail anyway. Discussed with jsing
* On receiving an overlong session ID terminate with an illegal_parametertb2020-05-091-1/+6
| | | | | | alert. Found with tlsfuzzer. ok jsing
* Add support for HelloRetryRequests in the TLSv1.3 server.jsing2020-05-092-10/+73
| | | | ok inoguchi@ tb@
* crazy whitespace on one linetb2020-05-091-2/+2
|
* Pull the sending of alerts up into tls13_handshake_perform().jsing2020-05-091-14/+11
| | | | | | | | | | 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@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-04-21 19:42:10 +0000