-
-
Notifications
You must be signed in to change notification settings - Fork 6.4k
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
vtls: refuse setting any SSL version #6773
Conversation
... previously they were supported if a TLS library would (unexpectedly) still support them, but from this change they will be refused already in curl_easy_setopt(). SSLv2 and SSLv3 have been known to be insecure for many years now.
Against this. If users need SSLv3 and their SSL backend is built for it then let them use it. They are often at the mercy of old devices. SSLv3 was already removed from the defaults and I think that's good enough. |
Can you mention a single user or use case that actually needs SSLv3 ? It's been disabled by default in all modern TLS libraries for a long time. I think most users who still enable SSLv3 do it because they use very old and outdated TLS libraries by old habits or old scripts. Not because they actually need it. |
I'm okay with dropping both SSLv2 and SSLv3. SSLv2 has been deprecated for a very long time now, and isn't supported by most back-ends anymore anyway. And anyone still using SSLv3 has to be less than a fraction of a percent of users. If anyone still needs it, they can stay on an old version. |
No, just a guess because there are some companies that move for nothing to update their equipment.
I don't disagree but a fraction of a percent of curl users is still a lot. |
We've dropped support for entire TLS backends because they didn't live up to our expectations, which more or less would force users to upgrade to keep up. This is very much in the same vein I think... RFC 7568 is approaching six years now! |
Also: if people still need to connect to legacy devices they can also probably continue using legacy curl versions for that as well. |
They started to return CURLE_BAD_FUNCTION_ARGUMENT with curl-7.77.0: curl/curl#6773
This change broke pycurl's test-suite. I have submitted a pull request to fix it: pycurl/pycurl#689 |
... with curl-7.77.0, where they started to return CURLE_BAD_FUNCTION_ARGUMENT: curl/curl#6773
... with curl-7.77.0, where they started to return CURLE_BAD_FUNCTION_ARGUMENT: curl/curl#6773 Closes: pycurl#689
... previously they were supported if a TLS library would (unexpectedly)
still support them, but from this change they will be refused already in
curl_easy_setopt(). SSLv2 and SSLv3 have been known to be insecure for
many years now.