Understand OpenSSL 3.0 failures
See original GitHub issueOpenSSL 3 is supported by Python, we should try running urllib3’s test suite against Python using OpenSSL 3.
Easiest route might be to use Docker in GitHub Actions with Fedora’s “rawhide” image:
- https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#runs-for-docker-actions
- https://hub.docker.com/_/fedora
Minimum requirements
💵 You can get paid to complete this issue! Please read the docs for more information.
- Add to the
ci
GitHub Action in themain
branch to test against a platform with access to OpenSSL 3. - Create a pytest marker
@requires_openssl_lt_3
which addspytest.mark.xfail
to tests when Python is compiled with OpenSSL >= 3.0.0 - For each failing test on CI figure out why the failure is occurring, document each failure with a comment and add the above pytest marker to the test.
- Create a GitHub issue which summarizes all the problems that are currently failing tests
Issue Analytics
- State:
- Created 2 years ago
- Reactions:1
- Comments:7 (7 by maintainers)
Top Results From Across the Web
New OpenSSL 3.0 vulnerabilities: What you need to ... - GitLab
The OpenSSL Project announced two vulnerabilities found in OpenSSL 3.0-3.0.6 (first released in September 2021).
Read more >Everything you need to know about the OpenSSL 3.0.7 Patch ...
The vulnerability is a buffer overflow in the X.509 certificate verification, which is the code used to validate TLS certificates. The ...
Read more >OpenSSL vulnerabilities: Everything you need to know - Wiz
These vulnerabilities affect OpenSSL versions 3.0.0 and above, as well as any application with an embedded impacted OpenSSL library in the ...
Read more >Qualys Research Alert: OpenSSL 3.0.7 - What You Need To ...
An attacker can craft a malicious email address in a certificate to overflow an arbitrary number of bytes containing the `.' character (decimal ......
Read more >OpenSSL 3.0 - OpenSSLWiki
These functions are being deprecated in OpenSSL 3.0, and users of these APIs should know that their use can likely bypass provider selection ......
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
No, it’s not a compile-time option. It’s actually more complicated and depends on several things like downstream patches and system-wide settings.
SSL_CTX_ctrl(ctx, SSL_CTRL_GET_MAX_PROTO_VERSION, 0, NULL)
returns0
, which Python maps toTLSVersion.MAXIMUM_SUPPORTED
SSL_CTX_ctrl(ctx, SSL_CTRL_GET_MAX_PROTO_VERSION, 0, NULL)
returns the settings based on/etc/crypto-policies/back-ends/opensslcnf.config
.The
DEFAULT
crypto policy sets TLS 1.2 as minimum and TLS 1.3 as maximum:You can override the settings by setting
OPENSSL_CONF
to an invalid path before you load any OpenSSL libraries:#2626 makes tests run on Ubuntu 22.04, tests succeed on Python 3.9–3.11.
I ran tests on Fedora 36 (Python 3.10.4 compiled with OpenSSL 3.0.3) locally too, and found timeouts similar to https://github.com/urllib3/urllib3/issues/2477#issuecomment-966975130 there, but increasing
LONG_TIMEOUT
to 0.05 fixed them. https://github.com/urllib3/urllib3/blob/9fbab29644bfc8068eb2082d0f25726c91813337/test/__init__.py#L80Also, three other failures happened in Fedora 36 because the test method assumes that
ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT).maximum_version
will always be equal tossl.TLSVersion.MAXIMUM_SUPPORTED
.https://github.com/urllib3/urllib3/blob/622aa69a1f65459232cadf7ff09f9a847d4c89b4/test/with_dummyserver/test_https.py#L947-L950
The assumption is not always true, and it’s actually false for Fedora 36. This is a related code in CPython. And
SSL_CTX_ctrl
can return different values depending on how OpenSSL has been compiled probably. I do not think this is related to OpenSSL 3.0 specifically.