summaryrefslogtreecommitdiff
path: root/src/lib/libssl (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Only parse a client's status_request in the CHtb2020-08-031-1/+4
| | | | | | | | A client should only send a status_request as part of the CH. Pointed out by Michael Forney ok inoguchi jsing
* Ensure clients only send a status_request in the CHtb2020-08-031-3/+7
| | | | | | | | | | The current code might cause a client to send a status_request containing a CertificateStatusRequest with its certificate. This makes no sense. Pointed out by Michael Forney ok inoguchi jsing
* Correctly handle server requests for an OCSP responsetb2020-08-031-1/+12
| | | | | | | | | | | | | | | | | According to RFC 8446, 4.4.2.1, a server may request that a client present an OCSP response with its certificate by sending an empty status_request extension as part of the certificate request. The current code expects a full CertificateStatus structure, which is only sent if the server sends an OCSP response with its certificate. This causes interoperability issues with Go's TLS server and with newer GnuTLS where we would abort the handshake with a decode_error alert and length mismatch error. Issue reported and diagnosed by Michael Forney Problem also found by Mikolaj Kucharski and inoguchi. ok inoguchi jsing
* Check the return value of tls1_enc() in the write path.jsing2020-08-022-6/+6
| | | | | | | | | The write path can return a failure in the AEAD path and there is no reason not to check a return value. Spotted by tb@ during another review. ok tb@
* Clean up/simplify more of the dtls1/ssl3 record writing code:jsing2020-08-012-73/+34
| | | | | | | | | | | | - Make the DTLS code much more consistent with the ssl3 code. - Avoid assigning wr->input and wr->length just so they can be used as arguments to memcpy(). - Remove the arc4random_buf() call for the explicit IV, since tls1_enc() already does this for us. ok tb@
* Pull record version selection code up and pass it as an argument tojsing2020-08-011-15/+15
| | | | | | ssl3_create_record(). ok tb@
* Have ssl_init_wbio_buffer() push the buffering BIO rather than doing itjsing2020-07-301-5/+2
| | | | | | ourselves. Spotted by tb@ during a previous review.
* Clean up and simplify some of the SSL3/DTLS1 record writing code.jsing2020-07-302-76/+72
| | | | | | | | | | | This will allow for further changes to be made with less complexity and easier review. In particular, decide if we need an empty fragment early on and only do the alignment calculation once (rather than in two separate parts of the function. ok tb@ inoguchi@
* Add minimal info callback support for TLSv1.3tb2020-07-303-3/+32
| | | | | | | | | | | | | | As abieber@ found the hard way, some python frameworks (twisted, synapse) thought it a great idea to use the info callback mechanism (designed to get state information about SSL objects) to modify state information such as setting and verifying the SNI. The switch of TLS_method() to default to TLSv1.3 broke these contraptions. Further bits of the info callback mechanism will likely metastasize throughout the TLSv1.3 stack if we need them, so we only do what's really necessary now. Lots of debugging, crucial hint and testing by abieber input & ok jsing
* Handle SSL_MODE_AUTO_RETRY being changed during a TLSv1.3 session.jsing2020-07-251-1/+4
| | | | | | | | | | | | | | | Both Perl's HTTP::Tiny and IO::Socket::SSL know about SSL_MODE_AUTO_RETRY and try to work around the fact that OpenSSL enabled it by default. However, this can lead to the mode being disabled prior to the TLSv1.3 handshake and then enabled after the handshake has completed. In order to handle this correctly we have to check the mode and inform the record layer prior to every read. Issue reported and test case provided by Nathanael Rensen <nathanael@polymorpheus.com>. ok inoguchi@ tb@
* Dedup the use legacy stack code.jsing2020-07-141-56/+25
| | | | ok inoguchi@ tb@
* Revert the TLSv1.3 version switching fix/hack.jsing2020-07-141-10/+1
| | | | | | | | This is no longer necessary since the TLS_method() now supports TLSv1.3. Reverts r1.211 of ssl_lib.c. ok beck@ inoguchi@ tb@
* Remove some unnecessary function pointers from SSL_METHOD_INTERNAL.jsing2020-07-075-64/+17
| | | | | | ssl_version is completely unused and get_timeout is the same everywhere. ok beck@ inoguchi@ tb@
* Enable TLSv1.3 for the generic TLS_method().jsing2020-07-072-5/+52
| | | | | | This can be done now that we have both TLSv1.3 client and server. ok beck@ inoguchi@ tb@
* zap trailing whitespace on one linetb2020-07-031-2/+2
|
* Make the message type available to the extension functionstb2020-07-032-167/+181
| | | | | | | | | | | | | | 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
* Improve argument order for the internal tlsext APItb2020-07-038-39/+39
| | | | | | | | 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
* Switch the order of the two tests in tls13_client_hello_required_extensionstb2020-06-251-9/+9
| | | | to match the order they are listed in the RFC. No functional change.
* Make tls13_legacy_shutdown() match ssl3_shutdown() semantics.jsing2020-06-241-21/+22
| | | | | | | | | | | | | 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@
* 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
* We inherited the constant time CBC padding removal from BoringSSL, buttb2020-06-191-4/+4
| | | | | | | | | | | 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
* The check_includes step is incorrect dependency management model forderaadt2020-06-091-11/+1
| | | | | | 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.
* Implement a rolling hash of the ClientHello message, Enforce RFC 8446beck2020-06-066-7/+179
| | | | | | | | section 4.1.2 to ensure subsequent ClientHello messages after a HelloRetryRequest messages must be unchanged from the initial ClientHello. ok tb@ jsing@
* Use IANA allocated GOST ClientCertificateTypes.jsing2020-06-053-9/+15
| | | | | | | | | | | 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@
* 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
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-08-25 01:17:36 +0000