Skip to content
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

Closed
wants to merge 1 commit into from
Closed

Conversation

@bagder
Copy link
Member

@bagder bagder commented Mar 22, 2021

... 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.

... 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.
@jay
Copy link
Member

@jay jay commented Mar 22, 2021

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.

Loading

@bagder
Copy link
Member Author

@bagder bagder commented Mar 22, 2021

They are often at the mercy of old devices.

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.

Loading

@nickzman
Copy link
Collaborator

@nickzman nickzman commented Mar 22, 2021

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.

Loading

@jay
Copy link
Member

@jay jay commented Mar 22, 2021

They are often at the mercy of old devices.

Can you mention a single user or use case that actually needs SSLv3 ?

No, just a guess because there are some companies that move for nothing to update their equipment.

And anyone still using SSLv3 has to be less than a fraction of a percent of users.

I don't disagree but a fraction of a percent of curl users is still a lot.

Loading

@bagder
Copy link
Member Author

@bagder bagder commented Mar 22, 2021

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!

Loading

@mback2k
Copy link
Member

@mback2k mback2k commented Mar 29, 2021

Also: if people still need to connect to legacy devices they can also probably continue using legacy curl versions for that as well.

Loading

@bagder bagder closed this in eff614f Apr 19, 2021
@bagder bagder deleted the bagder/refuse-sslversions branch Apr 19, 2021
kdudka added a commit to kdudka/pycurl that referenced this issue May 27, 2021
They started to return CURLE_BAD_FUNCTION_ARGUMENT with curl-7.77.0:

    curl/curl#6773
@kdudka
Copy link
Collaborator

@kdudka kdudka commented May 27, 2021

This change broke pycurl's test-suite. I have submitted a pull request to fix it: pycurl/pycurl#689

Loading

kdudka added a commit to kdudka/pycurl that referenced this issue May 31, 2021
... with curl-7.77.0, where they started to return
CURLE_BAD_FUNCTION_ARGUMENT:

    curl/curl#6773
kdudka added a commit to kdudka/pycurl that referenced this issue Jun 1, 2021
... with curl-7.77.0, where they started to return
CURLE_BAD_FUNCTION_ARGUMENT:

    curl/curl#6773

Closes: pycurl#689
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants