summaryrefslogtreecommitdiff
path: root/lib/libssl/ssl_tlsext.c
AgeCommit message (Collapse)Author
2021-11-01Improve SNI hostname validation.Joel Sing
For some time now we've validated the hostname provided to the server in the SNI extension. Per RFC 6066, an IP literal is invalid as a hostname - the current code rejects IPv6 literals, but allows IPv4 literals through. Improve this check to explicitly detect both IPv4 and IPv6 literals. Some software has been historically known to include IP literals in SNI, so rather than rejecting this outright (and failing with a decode error), pretend that the SNI extension does not exist (such that we do not break some older clients). ok inoguchi@ tb@
2021-10-25Fold SSL_SESSION_INTERNAL back into SSL_SESSION.Joel Sing
ok beck@ tb@
2021-09-10Do not ignore SSL_TLSEXT_ERR_FATAL from the ALPN callbackTheo Buehler
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
2021-09-02Correct the is_server flag in the call to the debug callback to be correct.Bob Beck
ok tb@
2021-06-29Use appropriate TLS version when building client sigalg extensions.Joel Sing
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@
2021-06-27Change ssl_sigalgs_build() to perform sigalg list selection.Joel Sing
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@
2021-06-11Only use SSL_AD_* internally.Joel Sing
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@
2021-06-08Simplify tlsext_ecpf_parse()Theo Buehler
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
2021-06-08Adjust alert for ECPF without uncompressed point formatTheo Buehler
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
2021-05-16Make local header inclusion consistent.Joel Sing
Consistently include local headers in the same location, using the same grouping/sorting across all files.
2021-05-16Explicitly include <openssl/opensslconf.h> in files using OPENSSL_NO_*Joel Sing
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.
2021-04-22Only hash known CH extensionsTheo Buehler
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
2021-03-29Move finished and peer finished to the handshake struct.Joel Sing
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@
2021-03-21Move the TLSv1.3 handshake struct inside the shared handshake struct.Joel Sing
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@
2021-03-10Improve internal version handling.Joel Sing
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@
2021-02-08Remove bogus DTLS checks to disable ECC and OCSP.Joel Sing
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@
2020-10-14Replace SSL_IS_DTLS with SSL_is_dtls().Joel Sing
Garbage collect the now unused SSL_IS_DTLS macro. ok tb@
2020-10-11Constipate srtp_known_profiles, pushing it into .data.rel.roPhilip Guenther
ok tb@ jsing@
2020-10-11Constipate ssl3_ciphers and tls1[23]_sigalgs*, pushing them intoPhilip Guenther
.data.rel.ro and .rodata respectively. ok tb@ jsing@
2020-09-09Set alpn_selected_len = 0 when alpn_selected is NULLKinichiro Inoguchi
ok jsing@ tb@
2020-08-03Only parse a client's status_request in the CHTheo Buehler
A client should only send a status_request as part of the CH. Pointed out by Michael Forney ok inoguchi jsing
2020-08-03Ensure clients only send a status_request in the CHTheo Buehler
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
2020-08-03Correctly handle server requests for an OCSP responseTheo Buehler
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
2020-07-03zap trailing whitespace on one lineTheo Buehler
2020-07-03Make the message type available to the extension functionsTheo Buehler
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
2020-07-03Improve argument order for the internal tlsext APITheo Buehler
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
2020-06-06Implement a rolling hash of the ClientHello message, Enforce RFC 8446Bob Beck
section 4.1.2 to ensure subsequent ClientHello messages after a HelloRetryRequest messages must be unchanged from the initial ClientHello. ok tb@ jsing@
2020-05-29Mop up servername_done, which is unused.Joel Sing
ok beck@ inoguchi@ tb@
2020-05-24Fix some stylistic nits from jsing.Theo Buehler
ok jsing
2020-05-23Enforce that SNI hostnames be correct as per rfc 6066 and 5980.Bob Beck
Correct SNI alerts to differentiate between illegal parameter and an unknown name. ok tb@`
2020-05-23Do not assume that server_group != 0 or tlsext_supportedgroups != NULLTheo Buehler
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
2020-05-19Only send ocsp staples if the client asked for ocsp certificate status.Bob Beck
noticed by dlg@ on www.openbsd.org with curl. ok dlg@
2020-05-19Add support for TLS 1.3 server to send certificate statusBob Beck
messages with oscp staples. ok jsing@ tb@
2020-05-13Fix pesky whitespace.Joel Sing
2020-05-10Use size_t for OCSP response length.Joel Sing
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@
2020-05-10Only reset TLS extension state when parsing client hello or server hello.Joel Sing
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@
2020-05-09Add support for certificate status requests in TLS 1.3 clientBob Beck
ok jsing@, tb@, inoguchi@
2020-05-09Add support for HelloRetryRequests in the TLSv1.3 server.Joel Sing
ok inoguchi@ tb@
2020-04-21Handle TLSv1.3 key shares other than X25519 on the server side.Joel Sing
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@
2020-02-18drop unused include <openssl/curve25519.h>Theo Buehler
ok inoguchi jsing
2020-02-16Avoid potential NULL dereference when parsing a server keyshare extension.Joel Sing
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@
2020-02-06Correctly handle key share extensions in a hello retry request.Joel Sing
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@
2020-02-01Correctly unpack client key shares.Joel Sing
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@
2020-01-30Provide struct/functions for handling TLSv1.3 key shares.Joel Sing
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@
2020-01-26Add sigalgs for server side to enable client certificate processingBob Beck
in tls 1.3 Will be used in a follow on commit to enable tls1.3 client certificates ok jsing@
2020-01-25Only discard the extension block for client hello and server helloJoel Sing
messages. TLSv1.3 messages that include extensions need a length prefixed field with zero bytes, rather than no data at all. ok beck@ tb@
2020-01-25Only send an RI extension for pre-TLSv1.3 versions.Joel Sing
ok beck@
2020-01-22Rename failure into alert_desc in tlsext_ocsp_server_parse().Theo Buehler
2020-01-22fix previous: alert_desc needs to be an int.Theo Buehler
2020-01-22Avoid modifying alert in the success path.Theo Buehler
ok beck jsing
generated by cgit v1.2.3 (git 2.25.1) at 2025-01-06 12:24:28 +0000