-
-
Notifications
You must be signed in to change notification settings - Fork 32.1k
SSL issue starting from openssl 3.2 #128141
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
Comments
Hello nurfed1, I tried to run provided test code and it works on python v3.13.1
And I Cannot find same Issue on another version of python (v3.10, v3.9)
Here is my openssl version.
In my Opinion, It may already fiexed in this follows issue. #115627 |
Hi keepworking, While this issue seems potentially related, I don’t believe it resolves the problem. I just ran a simple test case:
In the test, I used Burp as an HTTP proxy on 172.17.0.1:9001. From my review of the Python 3.13.1 source used by Arch Linux, this version already contains the gh-115627 fix mentioned in #115627. Therefore, I don't believe the issue is fully resolved. |
Thanks to your test. I want to request more test to you. The Provided log shows an ssl version to v3.4.0, can you test by ssl v3.2 ? I will test it with burp later. |
Yes, Arch Linux is currently using OpenSSL 3.4, but I recall conducting tests with various Python versions (3.10, 3.11, 3.12, 3.13, and 3.14) in combination with different OpenSSL versions (3.0.9, 3.1.4, 3.2.0, and 3.4.0). I noticed the issues started with OpenSSL 3.2.0, specifically with TLS 1.3, which seems to have become the default as of that version. Testing was a bit of a hassle, having to compile various OpenSSL and Python versions. |
The reproducer requires a proxy running on port 9001, right? What would be the best way to get that running in a container? |
Uh oh!
There was an error while loading. Please reload this page.
Bug report
Bug description:
Hi,
There appears to be an issue either in the asyncio SSL code when upgrading a connection with
start_tls
or in the function _ssl__SSLSocket_read_impl, starting from OpenSSL 3.2.The following code works fine with OpenSSL 3.1.4 but fails with OpenSSL 3.2.0 when TLS 1.3 is used. I’ve tested multiple combinations of OpenSSL and Python versions, and the issue seems to lie either in OpenSSL or Python. I’m unsure whether to report this here or on the OpenSSL GitHub, but it does appear to be a bug.
Starting with OpenSSL 3.2, the following exception is raised:
ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:2576)
This issue is caused by
SSL_read_ex
returningSSL_ERROR_SYSCALL
after successfully reading the HTTP response body. From my observations,errno
is0
at the time of the error.The OpenSSL 1.1.1 documentation (SSL_get_error) suggests this behavior should not occur in modern versions of OpenSSL. If I understand correctly, this could also be a regression introduced in OpenSSL 3.2.
I’m not sure if this is a bug in Python or OpenSSL, but it seems likely to become a problem once more systems upgrade to OpenSSL 3.2.
Here's the minimal reproducible sample code:
CPython versions tested on:
3.10, 3.11, 3.12, 3.13, 3.14
Operating systems tested on:
Linux
The text was updated successfully, but these errors were encountered: