summaryrefslogtreecommitdiff
path: root/src/lib/libssl/ssl_tlsext.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Do not ignore SSL_TLSEXT_ERR_FATAL from the ALPN callbacktb2021-09-101-2/+18
| | | | | | | | | | | | | | | | | | | As reported by Jeremy Harris, we inherited a strange behavior from OpenSSL, in that we ignore the SSL_TLSEXT_ERR_FATAL return from the ALPN callback. RFC 7301, 3.2 states: 'In the event that the server supports no protocols that the client advertises, then the server SHALL respond with a fatal "no_application_protocol" alert.' Honor this requirement and succeed only on SSL_TLSEXT_ERR_{OK,NOACK} which is the current behavior of OpenSSL. The documentation change is taken from OpenSSL 1.1.1 as well. As pointed out by jsing, there is more to be fixed here: - ensure that the same protocol is selected on session resumption - should the callback be called even if no ALPN extension was sent? - ensure for TLSv1.2 and earlier that the SNI has already been processed ok beck jsing
* Correct the is_server flag in the call to the debug callback to be correct.beck2021-09-021-2/+2
| | | | ok tb@
* Use appropriate TLS version when building client sigalg extensions.jsing2021-06-291-2/+6
| | | | | | | | Only use the minimum TLS version to when building a signature algorithms extension for a ClientHello - in all other cases we should be using the negotiated TLS version. ok inoguchi@ tb@
* Change ssl_sigalgs_build() to perform sigalg list selection.jsing2021-06-271-21/+3
| | | | | | | | | Rather that doing sigalg list selection at every call site, pass in the appropriate TLS version and have ssl_sigalgs_build() perform the sigalg list selection itself. This reduces code duplication, simplifies the calling code and is the first step towards internalising the sigalg lists. ok tb@
* Only use SSL_AD_* internally.jsing2021-06-111-25/+25
| | | | | | | | | | | Due to hysterical raisins there are three different types of defines for alerts. SSL3_AD_* are from SSLv3, TLS1_AD_* are from TLSv1.0 onwards and SSL_AD_* currently map to either an SSL3_AD_* or TLS1_AD_* define. Currently, all three of these are used in various places - switch to using just SSL_AD_* values internally, as a first step in cleaning this up. ok tb@
* Simplify tlsext_ecpf_parse()tb2021-06-081-8/+4
| | | | | | | The default alert in the tlsext parsing code is a decode_error, so there's no need for an error path that only sets that alert. suggested by/ok jsing
* Adjust alert for ECPF without uncompressed point formattb2021-06-081-3/+4
| | | | | | | | | | According to RFC 8422, we must send an illegal_parameter alert on receiving an ECPF extension that doesn't include the uncompressed format, not a decode_error. Reported via GitHub issue #675. ok jsing
* Make local header inclusion consistent.jsing2021-05-161-3/+2
| | | | | Consistently include local headers in the same location, using the same grouping/sorting across all files.
* Explicitly include <openssl/opensslconf.h> in files using OPENSSL_NO_*jsing2021-05-161-1/+2
| | | | | | Where a file references to OPENSSL_NO_* conditions, ensure that we explicitly include <openssl/opensslconf.h> before any references, rather than relying on another header to pull this in.
* Only hash known CH extensionstb2021-04-221-5/+5
| | | | | | | | | | | | | RFC 4.1.2 specifies the ways in which the extensions in the first and the second ClientHello may differ. It basically says that extensions not known to a server must not change. This in turn makes it impossible to introduce new extensions that do change. It makes little sense to enforce that extensions we don't know and care about aren't modified, so make the hashing more lenient and restrict it to the extensions we do care about. Arguably, enforcing no change in an unknown extension is incompatible with the requirement that it be ignored. ok bcook jsing
* Move finished and peer finished to the handshake struct.jsing2021-03-291-2/+2
| | | | | | | | | This moves the finish_md and peer_finish_md from the 'tmp' struct to the handshake struct, renaming to finished and peer_finished in the process. This also allows the remaining S3I(s) references to be removed from the TLSv1.3 client and server. ok inoguchi@ tb@
* Move the TLSv1.3 handshake struct inside the shared handshake struct.jsing2021-03-211-30/+30
| | | | | | | | | | | | | | | | There are currently three different handshake structs that are in use - the SSL_HANDSHAKE struct (as S3I(s)->hs), the SSL_HANDSHAKE_TLS13 struct (as S3I(s)->hs_tls13 or ctx->hs in the TLSv1.3 code) and the infamous 'tmp' embedded in SSL3_STATE_INTERNAL (as S3I(s)->tmp)). This is the first step towards cleaning up the handshake structs so that shared data is in the SSL_HANDSHAKE struct, with sub-structs for TLSv1.2 and TLSv1.3 specific information. Place SSL_HANDSHAKE_TLS13 inside SSL_HANDSHAKE and change ctx->hs to refer to the SSL_HANDSHAKE struct instead of the SSL_HANDSHAKE_TLS13 struct. This allows the TLSv1.3 code to access the shared handshake data without needing the SSL struct. ok inoguchi@ tb@
* Improve internal version handling.jsing2021-03-101-77/+39
| | | | | | | | | | | | | | | | | | Add handshake fields for our minimum TLS version, our maximum TLS version and the TLS version negotiated during the handshake. Initialise our min/max versions at the start of the handshake and leave these unchanged. The negotiated TLS version is set in the client once we receive the ServerHello and in the server at the point we select the highest shared version. Provide an ssl_effective_version() function that returns the negotiated TLS version if known, otherwise our maximum TLS version - this is effectively what is stored in s->version currently. Convert most of the internal code to use one of these three version fields, which greatly simplifies code (especially in the TLS extension handling code). ok tb@
* Remove bogus DTLS checks to disable ECC and OCSP.jsing2021-02-081-7/+2
| | | | | | | ECC and OCSP can be used with DTLS, so remove bogus checks that currently prevent it. These are long lasting remnants from the original OpenSSL code. ok tb@
* Replace SSL_IS_DTLS with SSL_is_dtls().jsing2020-10-141-11/+11
| | | | | | Garbage collect the now unused SSL_IS_DTLS macro. ok tb@
* Constipate srtp_known_profiles, pushing it into .data.rel.roguenther2020-10-111-4/+4
| | | | ok tb@ jsing@
* Constipate ssl3_ciphers and tls1[23]_sigalgs*, pushing them intoguenther2020-10-111-11/+11
| | | | | | .data.rel.ro and .rodata respectively. ok tb@ jsing@
* 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@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-04-04 19:52:27 +0000