summaryrefslogtreecommitdiff
path: root/src/lib/libssl (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Stop sending GOST R 34.10-94 as a CertificateType.jsing2020-06-051-3/+1
| | | | | | | | | | | | 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@
* Handle GOST in ssl_cert_dup().jsing2020-06-051-1/+5
| | | | | | | | | | Add missing case entry for SSL_PKEY_GOST01. Diff from Dmitry Baryshkov <dbaryshkov@gmail.com> Sponsored by ROSA Linux ok inoguchi@ tb@
* Enable GOST_SIG_FORMAT_RS_LE when verifying certificate signatures.jsing2020-06-052-2/+15
| | | | | | | | | | | | | | 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@
* Align tls13_server_select_certificate() withtb2020-06-041-3/+7
| | | | | | tls13_client_select_certificate(). ok inoguchi
* Improve client certificate selection for TLSv1.3tb2020-06-041-16/+80
| | | | | | This allows clients to use EC certificates. ok inoguchi, jsing
* mention that TLS_method(3) also supports TLSv1.3;schwarze2020-06-041-3/+3
| | | | tb@ OKed this part of a larger diff from inoguchi@
* Remove const modifier in return type of tls13_handshake_active_state()tb2020-06-021-3/+3
| | | | | | which make no sense as pointed out by gcc on sparc64. ok jsing
* distracting whitespacetb2020-06-021-5/+5
|
* Split the handling of post handshake handshake messages into itstb2020-06-011-55/+44
| | | | | | | | 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
* Send an illegal_parameter alert if a client sends us invalid DH keytb2020-06-011-3/+15
| | | | | | | | | 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
* Add a mechanism to set an alert in those parts of the read half oftb2020-06-011-3/+21
| | | | | | | | | | 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
* Replace ssl_max_server_version() with ssl_downgrade_max_version()jsing2020-05-313-30/+6
| | | | | | | 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@
* Correct downgrade sentinels when a version pinned method is in use.jsing2020-05-314-7/+40
| | | | | | | | | 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@
* Improve server certificate selection for TLSv1.3.jsing2020-05-292-23/+94
| | | | | | | | | This allows an EC certificate to be selected and used, if the client sigalgs would allow it. With feedback from tb@ ok inoguchi@ tb@
* Handle the case where we receive a valid 0 byte application data record.jsing2020-05-291-1/+10
| | | | | | | | 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@
* Wire up the servername callback in the TLSv1.3 server.jsing2020-05-293-3/+45
| | | | | | | | This makes SNI work correctly with TLSv1.3. Found the hard way by danj@, gonzalo@ and others. ok beck@ inoguchi@ tb@
* Mop up servername_done, which is unused.jsing2020-05-293-14/+3
| | | | ok beck@ inoguchi@ tb@
* minor cleanup ahead of the following work:schwarze2020-05-261-12/+14
| | | | | remove references to the SSL protocol which is no longer supported and use .Xr rather than .Fn for functions documented elsewhere
* Add additional length checks for TLSv1.3 plaintext and inner plaintext.jsing2020-05-261-1/+6
| | | | Reminded by and ok beck@
* Fix some stylistic nits from jsing.tb2020-05-241-8/+11
| | | | ok jsing
* Enforce that SNI hostnames be correct as per rfc 6066 and 5980.beck2020-05-232-17/+80
| | | | | | | Correct SNI alerts to differentiate between illegal parameter and an unknown name. ok tb@`
* Enable SSL_MODE_AUTO_RETRY by default.jsing2020-05-231-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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@
* Wire up SSL_MODE_AUTO_RETRY mode to retrying after PHH messages.jsing2020-05-232-2/+8
| | | | ok beck@ inoguchi@ tb@
* Provide the option to retry or return after post-handshake messages.jsing2020-05-232-4/+16
| | | | | | | | | | | 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@
* fix a confusingly wrapped linetb2020-05-231-3/+3
|
* Do not assume that server_group != 0 or tlsext_supportedgroups != NULLtb2020-05-232-9/+15
| | | | | | | | | | | | | | | | 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-222-5/+16
| | | | | | | | | | | | 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@
* Simplify: transform a dangling else into an early return andtb2020-05-211-20/+20
| | | | | | unindent a bunch of code. Suggested by jsing
* Make ssl_set_cert_masks() more consistent and closer to readable.jsing2020-05-211-44/+27
| | | | | | Prompted by tb@ ok tb@
* Avoid a shadowing issue by renaming cbs and cbb to cbb_hs and cbb_hs,tb2020-05-211-8/+7
| | | | | | respectively. Discussed with jsing
* 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@
* 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@
* 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@
* 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@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-20 07:47:57 +0000