-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Deprecate PROTOCOL_SSLv23 #1400
Labels
Comments
janbrasna
added
enhancement
New feature or enhancement
new
Needs triage. Comments are welcome!
labels
May 10, 2022
What this might impact is things like as this comes with |
Will be removed once #1531 is merged. |
@Ousret Haven't checked the actual changes in parsing the constraints (e.g. re the " |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Enhancement request
Move away from
PROTOCOL_SSLv23
as it now defaults toPROTOCOL_TLS
… and we should (probably?) usePROTOCOL_TLS_CLIENT
explicitly.Problem it solves
Deprecated since 3.6, might be needed for going ahead with features like #722 where a range of
SSLContext.*
is needed etc.Additional information, screenshots, or code examples
The backstory is I was originally quite puzzled by the docs:
-ssl=ssl2.3
/docs/README.md#L1510
like "WTF is this SSL v2.3 you speak of" as there's nothing like that in the world… until I figured out through the actual source this comes from Python's
PROTOCOL_SSLv23
constant, that itself comes from OpenSSL valueSSLv23
— which is nonetheless not meant as an arbitrary SSL version, but rather a "magic value" used by OpenSSL to mean “all supported versions”.So there's really no "SSL v2.3", and it also means neither SSL2 nor SSL3 as in "SSL v2-3" as those are not available in Python today anymore yet this constant still enables current TLS versions.
That value has been luckily deprecated and is today the equivalent of
PROTOCOL_TLS
, and thehttps
command defaults +params should reflect this.So I propose the new default to be something more understandable like
-ssl=tls
forPROTOCOL_TLS
or maybe evenPROTOCOL_TLS_CLIENT
i. e. "negotiate the highest protocol version for me ktxbye", for future compatibility.Since this might be a breaking change not sure if that means a major version bump, or better getting away with backward compatibility by cheating like:
-ssl=ssl2.3
to keep resolving toPROTOCOL_SSLv23
therefore actually toPROTOCOL_TLS
-ssl=tls
picking the newPROTOCOL_TLS_CLIENT
The text was updated successfully, but these errors were encountered: