-
-
Notifications
You must be signed in to change notification settings - Fork 6.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Forcing TLS version fails with OpenSSL 1.1.1 in Debian Buster? #4097
Comments
This works as expected on the previous major release, Debian Stretch, which has the following curl version, although that one does not support the
It also works as expected with the current Apple-supplied version in Mojave (10.14.5), with and without the
Oh, and this fails against something like the following;
So it seems unlikely it's a server-side configuration issue? |
OK, testing with the latest curl version available from MacPorts, it looks like at least the 'no protocols available' error is fixed, but I'm not sure the behaviour is as it should be. Version info;
The following negotiates TLSv1.3;
While this behaves as expected;
As does this;
So it would seem that something changed between 7.64 and 7.65.1, or that the way OpenSSL gets built on both platforms is somehow different? Disabling ALPN/HTTP 2.0 with |
This sounds like #2918 can you confirm |
No, not the same thing. |
--tlsv1.0 means use TLS 1.0 or later. The negotiated version depends on what your SSL library and the server support. In older versions the option meant negotiate only TLS 1.0, as discussed in #2918.
Can you explain how this is different from #2918 |
Because, even if used as you said it should be used, it fails in unpredictable ways, and it is not clear from the documentation when and where that changed. The fact that you have multiple tickets for a similar issue shows that we're not the only ones running into this, either. Even between 7.64 and 7.65 the behaviour seems inconsistent. |
What multiple tickets? If the packaged build of curl in Debian can't connect to cloudflare when you request only TLS 1.0 then I don't see how that's curl's fault. You can use Wireshark and capture |
Before filing this ticket we of course took care to test this against multiple endpoints. Cloudflare is mentioned as an example because it is a stable, public target that has support for TLSv1 with multiple ciphers, something which can be, and was, verified before this ticket was created. The rest of the information supplied also makes it pretty clear that we tested against these endpoints with multiple versions of curl, from multiple platforms, and the change of behaviour most definitely originates with curl. We even provided an example with a freshly compiled version of a recent build, so I'm not sure what else there is to prove. I guess it's still useful for the next person who comes along confused by the unpredictable change in behaviour. |
Since 7.54 --tlsv1. options use the specified version or later, however older versions of curl documented it as using just the specified version which may or may not have happened depending on the TLS library. Document this discrepancy to allay confusion for users familiar with the old documentation that expect just the specified version. Fixes curl#4097 Closes #xxxx
I've submitted #4119 to update the documentation. Your examples using the latest version of curl show it's working as expected. If it wasn't I'd suspect how the SSL library is built or the server. TLS 1.0 is being phased out by some so it's possible either of those have dropped support. You can investigate further by using Wireshark. |
Since I just ran into the same issue and couldn't find anything on the internet why this is failing, I tried tracking it down and found the cause (combination of debian and openssl):
Step 1 is important here, since it loads the openssl default configuration (on debian from
-> Step 1 sets the general minimum tls/ssl version to TLSv1.2, Step 2 disallows TLSv1_2 and TLSv1_3; Step 3 now basically has no viable TLS options left causing the error (this fails a bit late for my taste since the TCP connection was already established at this point...) So I'd say everything works as intended - but the error message is a bit confusing... Solutions:
Maybe a pointer in the documentation would help here. |
Awesome detective work there @notti! The question left is then only what to say where in the docs... 😁 |
Hmm maybe something like the following to the tls min/max options (I'm not sure about the ciphers part):
Maybe handle SSL_R_NO_PROTOCOLS_AVAILABLE somewhere around Line 2839 in a93b43c
I think the same can happen with the other libraries. I can try to come up with a pull request (can't promise any timelines), if you think this looks good. The same can probably happen with the other ssl libs - but I don't have any experience with those (actually neither with openssl - just read code/documentation and used a debugger/strace/ltrace to track that down). |
Yes, thanks. Please do! |
Thanks everyone for your interesting comments. |
I tried something... root@kali:~/curl/curl# curl -V
curl 7.64.0 (x86_64-pc-linux-gnu) libcurl/7.64.0 OpenSSL/1.1.1a zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) libssh2/1.8.0 nghttp2/1.36.0 librtmp/2.3
Release-Date: 2019-02-06
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL
root@kali:~/curl/curl# curl --tlsv1 https://tls-v1-0.badssl.com:1010/
curl: (35) error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol I added the following code (I know it's not correct for many reasons, just a quick dirty test): diff --git a/lib/vtls/openssl.c b/lib/vtls/openssl.c
index 20eae6c9e..a0d362d13 100644
--- a/lib/vtls/openssl.c
+++ b/lib/vtls/openssl.c
@@ -2511,6 +2511,9 @@ static CURLcode ossl_connect_step1(struct connectdata *conn, int sockindex)
}
SSL_CTX_set_options(BACKEND->ctx, ctx_options);
+#if (OPENSSL_VERSION_NUMBER >= 0x10100000L)
+ SSL_CTX_set_min_proto_version(BACKEND->ctx, TLS1_VERSION);
+#endif
#ifdef HAS_NPN
if(conn->bits.tls_enable_npn) And it works :) root@kali:~/curl/curl# make -sj && ./src/curl --tlsv1 https://tls-v1-0.badssl.com:1010/
Making all in lib
[...]
<!DOCTYPE html>
<html>
<head>
[...] This was just a PoC to confirm that we can use So, to have a proper patch, this code must be adapted for all TLS versions. It should also move inside Line 2182 in 0690b33
What do you think? You know the code better than me :) |
You can find some inspiration in OpenSSL/Ruby. Otherwise they implement it themselves: |
I did this
This negotiates TLSv1.3 if the endpoint supports it. Adding
--tls-max 1.0
has the request fail altogether with 'no protocols available'.I expected the following
Use TLSv1 to negotiate the connection, do not use higher versions.
curl/libcurl version
operating system
Debian 10.0 'Buster'
The text was updated successfully, but these errors were encountered: