-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
curl: ignore options asking for SSLv2 or SSLv3 #6772
Conversation
Instead output a warning about it and continue with the defaults. These SSL versions are typically not supported by the TLS libraries since a long time back already since they are inherently insecure and broken. Asking for them to be used will just cause an error to be returned slightly later. In the unlikely event that a user's TLS library actually still supports these protocol versions, this change might make the request a little less insecure.
@bagder I see the removal of the command line option for SSLv3 which is the right decision. I traced it back to this PR this commit: eff614f which seems to show up in 7.77.0. I use curl + openssl libs in my iOS Build-OpenSSL-cURL Script project and iCurlHTTP iOS app for negative testing (to prove a server will not answer to SSLv3). With the changes, I'm no longer able to use libcurl OpenSSL SSLv3 for this negative test using: curl_easy_setopt(_curl, CURLOPT_SSLVERSION, CURL_SSLVERSION_SSLv3); This appears to be caused by changes in # for library patch setopt.c and openssl.c
sed -i '' '/version == CURL_SSLVERSION_SSLv3/d' "${CURL_VERSION}/lib/setopt.c"
patch "${CURL_VERSION}/lib/vtls/openssl.c" sslv3.patch
# for command line patch tool_getparam.c
sed -i '' -e 's/warnf(global, \"Ignores instruction to use SSLv3\\n\");/config->ssl_version = CURL_SSLVERSION_SSLv3;/g' "${CURL_VERSION}/src/tool_getparam.c" sslv3.patch --- openssl.c 2022-05-30 01:05:13.000000000 -0700
+++ openssl.c.2 2022-05-30 01:25:52.000000000 -0700
@@ -2709,8 +2709,9 @@
failf(data, "No SSLv2 support");
return CURLE_NOT_BUILT_IN;
case CURL_SSLVERSION_SSLv3:
- failf(data, "No SSLv3 support");
- return CURLE_NOT_BUILT_IN;
+ req_method = SSLv3_client_method();
+ use_sni(FALSE);
+ break;
default:
failf(data, "Unrecognized parameter passed via CURLOPT_SSLVERSION");
return CURLE_SSL_CONNECT_ERROR;
@@ -2798,9 +2799,18 @@
switch(ssl_version) {
case CURL_SSLVERSION_SSLv2:
- case CURL_SSLVERSION_SSLv3:
return CURLE_NOT_BUILT_IN;
+ case CURL_SSLVERSION_SSLv3:
+ SSL_CTX_set_min_proto_version(backend->ctx, SSL3_VERSION);
+ SSL_CTX_set_max_proto_version(backend->ctx, SSL3_VERSION);
+ ctx_options |= SSL_OP_NO_SSLv2;
+ ctx_options |= SSL_OP_NO_TLSv1;
+ ctx_options |= SSL_OP_NO_TLSv1_1;
+ ctx_options |= SSL_OP_NO_TLSv1_2;
+ ctx_options |= SSL_OP_NO_TLSv1_3;
+ break;
+
/* "--tlsv<x.y>" options mean TLS >= version <x.y> */
case CURL_SSLVERSION_DEFAULT:
case CURL_SSLVERSION_TLSv1: /* TLS >= version 1.0 */ Also, and I'm sure this never gets said enough, THANK YOU for curl! ❤️ |
Last Sunday (2022-08-21) i had to interact with a
SSLv2 and SSLv3 is still supported by OpenSSL, but they're opt-in at compile-time in the form of
|
Today (2022-08-27) i had to deal with that damn SSLv3 HP iLO server again, fwiw. |
Instead output a warning about it and continue with the defaults.
These SSL versions are typically not supported by the TLS libraries since a
long time back already since they are inherently insecure and broken. Asking
for them to be used will just cause an error to be returned slightly later.
In the unlikely event that a user's TLS library actually still supports these
protocol versions, this change might make the request a little less insecure.