Open janbrasna opened 2 years ago
What this might impact is things like verify
:
as this comes with *_CLIENT
constant etc.
Will be removed once #1531 is merged.
@Ousret Haven't checked the actual changes in parsing the constraints (e.g. re the "verify
" above), but I've raised the change in the param values in review: https://github.com/httpie/cli/pull/1531#pullrequestreview-2079044720
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