summaryrefslogtreecommitdiff
path: root/src/lib/libssl/ssl_tlsext.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Set alpn_selected_len = 0 when alpn_selected is NULLinoguchi2020-09-091-1/+4
| | | | ok jsing@ tb@
* 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
* zap trailing whitespace on one linetb2020-07-031-2/+2
|
* Make the message type available to the extension functionstb2020-07-031-85/+89
| | | | | | | | | | | | | | 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-031-11/+11
| | | | | | | | 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
* Implement a rolling hash of the ClientHello message, Enforce RFC 8446beck2020-06-061-1/+35
| | | | | | | | section 4.1.2 to ensure subsequent ClientHello messages after a HelloRetryRequest messages must be unchanged from the initial ClientHello. ok tb@ jsing@
* Mop up servername_done, which is unused.jsing2020-05-291-2/+1
| | | | ok beck@ inoguchi@ tb@
* 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-231-16/+78
| | | | | | | Correct SNI alerts to differentiate between illegal parameter and an unknown name. ok tb@`
* Do not assume that server_group != 0 or tlsext_supportedgroups != NULLtb2020-05-231-8/+12
| | | | | | | | | | | | | | | | 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
* 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-191-1/+23
| | | | | | messages with oscp staples. ok jsing@ tb@
* Fix pesky whitespace.jsing2020-05-131-2/+2
|
* Use size_t for OCSP response length.jsing2020-05-101-5/+2
| | | | | | | | | 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@
* Add support for certificate status requests in TLS 1.3 clientbeck2020-05-091-6/+37
| | | | ok jsing@, tb@, inoguchi@
* Add support for HelloRetryRequests in the TLSv1.3 server.jsing2020-05-091-2/+32
| | | | ok inoguchi@ tb@
* Handle TLSv1.3 key shares other than X25519 on the server side.jsing2020-04-211-5/+19
| | | | | | | | Previously we would only select an X25519 key share from the client, ignoring any others. Change this so that we will select the first of the key shares that matches one of our supported groups. ok beck@ inoguchi@ tb@
* drop unused include <openssl/curve25519.h>tb2020-02-181-2/+1
| | | | ok inoguchi jsing
* Avoid potential NULL dereference when parsing a server keyshare extension.jsing2020-02-161-1/+4
| | | | | | | | | | | | It is currently possible for key_share to be NULL when a TLS client receives a keyshare extension. However, for this to occur the client has to be doing TLS 1.2 or earlier, which means that it was invalid for the server to send the extension. As such, check for NULL and treat it as an invalid extension. Found by oss-fuzz (#20741 and #20745). ok inoguchi@ tb@
* Correctly handle key share extensions in a hello retry request.jsing2020-02-061-3/+9
| | | | | | | | In a hello retry request the server will only send the selected group and not actually provide a key exchange. In this case we need to store the server selected group for further processing. ok tb@
* Correctly unpack client key shares.jsing2020-02-011-4/+9
| | | | | | | | Even if we're not processing/using the peer public key from the key share, we still need to unpack it in order to parse the TLS extension correctly. Resolves issues with TLSv1.3 clients talking to TLSv1.2 server. ok tb@
* Provide struct/functions for handling TLSv1.3 key shares.jsing2020-01-301-92/+17
| | | | | | | Pull out the key share handling code and provide a clean/self contained interface. This will make it easier to support groups other than X25519. ok beck@ inoguchi@ tb@
* Add sigalgs for server side to enable client certificate processingbeck2020-01-261-5/+34
| | | | | | | | in tls 1.3 Will be used in a follow on commit to enable tls1.3 client certificates ok jsing@
* Only discard the extension block for client hello and server hellojsing2020-01-251-2/+3
| | | | | | | | | messages. TLSv1.3 messages that include extensions need a length prefixed field with zero bytes, rather than no data at all. ok beck@ tb@
* Only send an RI extension for pre-TLSv1.3 versions.jsing2020-01-251-2/+2
| | | | ok beck@
* Rename failure into alert_desc in tlsext_ocsp_server_parse().tb2020-01-221-5/+5
|
* fix previous: alert_desc needs to be an int.tb2020-01-221-2/+2
|
* Avoid modifying alert in the success path.tb2020-01-221-11/+17
| | | | ok beck jsing
* Revert previous deduplication diff, I broke portable in a strange way.beck2019-11-161-47/+58
| | | | | I'll figure it out a bit later. Found and diagnosed by inoguchi@
* Deduplicate some extension processing code.beck2019-11-151-58/+47
| | | | ok tb@ inoguchi@
* Relax parsing of TLS key share extensions on the server.jsing2019-05-291-5/+2
| | | | | | | | | | | The RFC does not require X25519 and it also allows clients to send an empty key share when the want the server to select a group. The current behaviour results in handshake failures where the client supports TLS 1.3 and sends a TLS key share extension that does not contain X25519. Issue reported by Hubert Kario via github. ok tb@
* Do not send an SNI extension when resuming a session that contains a serverjsing2019-05-291-1/+4
| | | | | | | | name (which means the client sent SNI during the initial handshake). Issue reported by Renaud Allard. ok tb@
* Fix typo and label indent.jsing2019-05-281-3/+3
|
* Tidy up some names/structures following the renaming of TLS extensionjsing2019-05-281-35/+35
| | | | | | | | | functions based on message type (clienthello/serverhello), to which side is handling the processing. No intended functional change. ok beck@
* In DTLS, use_srtp is part of the extended server hello while in TLSv1.3,tb2019-05-081-2/+3
| | | | | | | | | | it is an encrypted extension. Include it in the server hello for now. This will have to be revisited once TLSv1.3 gets there. Fixes SRTP negotiation. Problem found by two rust-openssl regress failures reported by mikeb. with & ok beck
* Defer sigalgs selection until the certificate is known.jsing2019-03-251-9/+6
| | | | | | | | | | | | | Previously the signature algorithm was selected when the TLS extension was parsed (or the client received a certificate request), however the actual certificate to be used is not known at this stage. This leads to various problems, including the selection of a signature algorithm that cannot be used with the certificate key size (as found by jeremy@ via ruby regress). Instead, store the signature algorithms list and only select a signature algorithm when we're ready to do signature generation. Joint work with beck@.
* Revert TLS1_get{,_client}_version simplification because DTLS.jsing2019-03-191-5/+5
|
* Partially clean up the TLS1_get_{,client}_version macros.jsing2019-03-171-5/+5
| | | | | | | | | LibreSSL only supports TLSv1.0 and above, hence the checks the macros are performing are useless. Simplify them to their effective code. Also place both under #ifndef LIBRESSL_INTERNAL and use the variables directly in our code, which improves readability. ok tb@
* Revert r1.38 as it introduces use of a stack value post function return.jsing2019-02-031-50/+86
| | | | | The deduplication is also not quite right - this will be revisited in due course.
* unwrap a line introduced in previous.tb2019-01-311-3/+2
|
* Correct handling of TLS sigalgs extension for TLSv1.0/TLSv1.1.jsing2019-01-301-33/+19
| | | | | | | | | | | | | When operating as a TLSv1.0 or TLSv1.1 server, we still have to parse the TLS sigalgs extension if presented by the client (which might be TLSv1.2 capable), rather than treating its presence as an error. While here, remove future version dependence issues by avoiding explicit version equality checks. Issue reported by bluhm@. ok bluhm@ tb@
* Deduplicate a bunch of replicated code in the extension handlingbeck2019-01-281-86/+50
| | | | ok tb@
* Add tls_extension_seen(), a utility to know if a particular extensionbeck2019-01-281-8/+13
| | | | | has been seen in the handshake so far. Use it for keyshare. ok tb@
* Add server side of versions, keyshare, and client and server of cookiebeck2019-01-241-19/+289
| | | | | | | | extensions for tls1.3. versions is currently defanged to ignore its result until tls13 server side wired in full, so that server side code still works today when we only support tls 1.2 ok bcook@ tb@ jsing@
* move the extensions_seen into the handshake structbeck2019-01-241-4/+5
| | | | ok jsing@
* Modify sigalgs extension processing to accomodate TLS 1.3.beck2019-01-231-3/+33
| | | | | | | | | | - Make a separate sigalgs list for TLS 1.3 including only modern algorithm choices which we use when the handshake will not negotiate TLS 1.2. - Modify the legacy sigalgs for TLS 1.2 to include the RSA PSS algorithms as mandated by RFC8446 when the handshake will permit negotiation of TLS 1.2 from a 1.3 handshake. ok jsing@ tb@
* revert previous, accidentally contained another diff in additionbeck2019-01-231-326/+22
| | | | to the one I intended to commit
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-24 17:20:58 +0000