summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* 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@
* Add checks for SH downgrade sentinel and HRR hash in appstest.shinoguchi2020-05-291-1/+27
|
* more tests after getopt_long.c rev. 1.32;schwarze2020-05-271-10/+43
| | | | OK martijn@
* This patch fixes one bug and one instance of undesirable behaviour.schwarze2020-05-271-9/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bug, present since 4.4BSD, was that a trailing dash in an option group, when the dash is not permitted as an option letter, resulted in the whole option group being returned as an argument, even though the previous option in the group was already parsed as an option: OPTS=abc ./getopt-test -a- -c arg ===>> OPT(a)ARG(-a-)ARG(-c)ARG(arg). Instead, treat the dash as an invalid option and continue parsing options: ===>> OPT(a)ERR(?-)OPT(c)ARG(arg). The undesirable behaviour was that allowing the dash as an option letter only allowed isolated dashes ("-") and trailing dashes in groups ("-a-"), but neither middle dashes in groups ("-a-b"), even though that already partially worked in 4.4BSD, nor leading dashes in groups ("--a"), even though that works on all other BSDs and on glibc. Also, while POSIX does not require that the dash can be used as an option letter at all, arguably, it encourages that letters either be fully supported or not supported at all. It is dubious whether supporting an option letter in some positions but not in others can be considered conforming. This patch makes OpenBSD behaviour identical to FreeBSD and NetBSD, improves compatibility with glibc (except that glibc does not support isolated "-"), improves compatibility with DragonFly (except that DragonFly is buggy when the dash option letter can take an optional argument but that argument is not present), improves compatibility with Illumos and Solaris 11 (except those do not support "-" and mishandle "--a"), and restores 4.4BSD behaviour for "-a-b". In no respect i'm aware of is compatibility with any other systems reduced. For the full rationale, see my mail to tech@ on 30 Mar 2020 14:26:41 +0200. Part of the problem was originally reported by an anonymous coward on tech@ on 12 Mar 2020 03:40:24 +0200, additional analysis was contributed by martijn@, and then the OP sent the final version of the patch i'm now committing on 17 Mar 2020 19:17:56 +0200. No licensing problem here because after the commit, the file does not contain a single word written by the OP. Also, the OP told me in private mail that he intends to publish the patch under the ISC license already contained in the file and that he wishes to be known by the pseudonym "0xef967c36". OK martijn@, and no objection when shown on tech@, but commit delayed to stay clear of the release.
* document PKCS7_dataFinal(3);schwarze2020-05-273-3/+162
| | | | tweak and OK 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@
* Previous commit caught a few errx() cases by accident. undo them.tb2020-05-241-25/+25
|
* Fix some stylistic nits from jsing.tb2020-05-241-8/+11
| | | | ok jsing
* Clear SSL_MODE_AUTO_RETRY in libtls, since we handle WANT_POLLIN correctly.jsing2020-05-241-1/+3
|
* include newlines in FAIL messagestb2020-05-241-108/+108
|
* address some nits from jsingtb2020-05-241-7/+11
|
* Minimally document PKCS7_dataInit(3).schwarze2020-05-244-5/+215
| | | | | | | | | No comment when shown around among LibreSSL devs except "very very strange function" from beck@ and "cannot say much about it" from tb@. If needed, this can be further polished in the tree, review is still welcome.
* Briefly mention the obsolete function OPENSSL_init(3).schwarze2020-05-241-7/+23
| | | | Suggested by bluhm@, OK beck@ tb@.
* The version detection doesn't work on bluhm's test machine, causingtb2020-05-241-3/+3
| | | | | | | the test to fail. Neuter it for now and just assume we do TLSv1.3. I have been intending to purge this version detection hack once I'm sure we can leave the 1.3 server enabled but I'll leave it here for now.
* Define REGRESS_TARGETS explicitly.tb2020-05-231-2/+4
|
* Enforce that SNI hostnames be correct as per rfc 6066 and 5980.beck2020-05-233-18/+159
| | | | | | | Correct SNI alerts to differentiate between illegal parameter and an unknown name. ok tb@`
* While the second SSL_CTX in this code is only used on servernametb2020-05-231-1/+2
| | | | | | | | callback, so its mode is not used to update the ssl's mode, it seems more appropriate to clear the SSL_MODE_AUTO_RETRY flag on it as well. ok jsing
* In ssl_lib.c revision 1.217, jsing enabled SSL_MODE_AUTO_RETRY bytb2020-05-232-2/+7
| | | | | | | default. To avoid hanging on a blocking read, we need to clear the SSL_MODE_AUTO_RETRY flag in the s_client and the s_server. ok beck inoguchi jsing
* 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
|
* Avoid an out-of-bounds array access in the s_server.tb2020-05-231-1/+3
| | | | | | | | | It can be triggered by sending a line to stdin while no connection is open and then connecting a client. The first SSL_write() fails, sends SSL_ERROR_WANT_* and then causes a segfault deep down in the tls stack when accessing &(buf[-1]). ok beck inoguchi
* 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
* sockaddr should be sockaddr_storage, otherwise "openssl s_client -6 -dtls1"deraadt2020-05-221-3/+4
| | | | | | (gurn) copies getsockname() retrieves a truncated result and 14 bytes of stack garbage get copied onwards. ok tb
* 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
* beck fixed most of the keyupdate tests. update annotationtb2020-05-211-3/+8
|
* 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@
* hook tlsfuzzer to regresstb2020-05-211-1/+2
|
* Add a harness that runs tests from tlsfuzzertb2020-05-212-0/+781
| | | | | | | | | | | | | This currently runs 54 tests from the tlsfuzzer suite against the TLSv1.3 server which exercise a large portion of the code. They already found a number of bugs and misbehaviors and also inspired a few diffs currently in the pipeline. This regress requires the py3-tlsfuzzer package to be installed, otherwise the tests are skipped. Many thanks to kmos for helping with the ports side and to beck for his positive feedback. ok beck
* 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@
* Add -status and -servername test for s_server and s_client in appstest.shinoguchi2020-05-191-1/+3
|
* Add -groups test for s_server and s_client in appstest.shinoguchi2020-05-191-3/+17
|
* 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@
* Add client certificate test in appstest.shinoguchi2020-05-181-2/+89
|
* Rename variables for key, csr, pass, certinoguchi2020-05-181-85/+85
|
* 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...')
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-04-01 19:48:06 +0000