Repository navigation
SSL issue starting from openssl 3.2 #128141
Description
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 returning SSL_ERROR_SYSCALL after successfully reading the HTTP response body. From my observations, errno is 0 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.
The SSL_ERROR_SYSCALL with errno value of 0 indicates unexpected EOF from the peer. This will be properly
reported as SSL_ERROR_SSL with reason code SSL_R_UNEXPECTED_EOF_WHILE_READING in the OpenSSL 3.0
release because it is truly a TLS protocol error to terminate the connection without a SSL_shutdown().
The issue is kept unfixed in OpenSSL 1.1.1 releases because many applications which choose to ignore this
protocol error depend on the existing way of reporting the error.
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:
import asyncio
import ssl
class HttpProxyClient:
def __init__(self, proxy_host, proxy_port, target_host, target_port):
self.proxy_host = proxy_host
self.proxy_port = proxy_port
self.target_host = target_host
self.target_port = target_port
async def connect(self):
reader, writer = await asyncio.open_connection(self.proxy_host, self.proxy_port)
connect_request = (
f"CONNECT {self.target_host}:{self.target_port} HTTP/1.1\r\n"
f"Host: {self.target_host}:{self.target_port}\r\n"
f"Proxy-Connection: keep-alive\r\n\r\n"
)
writer.write(connect_request.encode())
await writer.drain()
response = await reader.read(4096)
if b'200 Connection established' not in response:
writer.close()
await writer.wait_closed()
raise Exception("Failed to establish connection with the proxy.")
ctx = ssl.create_default_context(
purpose=ssl.Purpose.SERVER_AUTH
)
# Disable checks for docker test container
ctx.check_hostname = False
ctx.verify_mode = ssl.CERT_NONE
# Disable tls1.3: this fixes the issue with openssl 3.2+
# ctx.options |= ssl.OP_NO_TLSv1_3
# Disable everything except tls1.3: this causes a crash with openssl 3.2+
ctx.options |= ssl.OP_NO_TLSv1_2 | ssl.OP_NO_TLSv1_1 | ssl.OP_NO_TLSv1 | ssl.OP_NO_SSLv2 | ssl.OP_NO_SSLv3
await writer.start_tls(ctx)
print("Upgraded to SSL/TLS")
return reader, writer
async def run(self):
http_request = (
f"GET / HTTP/1.1\r\n"
f"Host: {self.target_host}\r\n"
f"Accept: */*\r\n"
f"Connection: close\r\n\r\n"
)
try:
reader, writer = await self.connect()
writer.write(http_request.encode())
await writer.drain()
while not reader.at_eof():
response = await reader.read(4096)
print(response.decode())
writer.close()
await writer.wait_closed()
except Exception as e:
raise
async def main():
proxy_host = "localhost"
proxy_port = 9001
target_host = "google.com"
target_port = 443
client = HttpProxyClient(proxy_host, proxy_port, target_host, target_port)
await client.run()
asyncio.run(main())CPython versions tested on:
3.10, 3.11, 3.12, 3.13, 3.14
Operating systems tested on:
Linux
Activity
keepworking commentedon Jan 14, 2025
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
This changes applied in python 3.13.1.
nurfed1 commentedon Jan 14, 2025
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.
keepworking commentedon Jan 14, 2025
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.
nurfed1 commentedon Jan 14, 2025
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.
encukou commentedon Jan 27, 2025
The reproducer requires a proxy running on port 9001, right? What would be the best way to get that running in a container?
encukou commentedon Jun 9, 2025
Without a good way to reproduce, I think it'd be best to close this.
picnixz commentedon Jun 29, 2025
I'll close this one until we have a better reproducer. Also, try to use the latest Python 3.13 (I don't think I've fixed anything in the SSL module but it's better to be in sync with the latest one). For that reason, I suggest compiling the latest Python 3.13 and OpenSSL from source.