[3.11] gh-108310: Fix CVE-2023-40217: Check for & avoid the ssl pre-close flaw#108317
[3.11] gh-108310: Fix CVE-2023-40217: Check for & avoid the ssl pre-close flaw#108317ambv merged 1 commit into
Conversation
Sorry, something went wrong.
…ose flaw Instances of `ssl.SSLSocket` were vulnerable to a bypass of the TLS handshake and included protections (like certificate verification) and treating sent unencrypted data as if it were post-handshake TLS encrypted data. The vulnerability is caused when a socket is connected, data is sent by the malicious peer and stored in a buffer, and then the malicious peer closes the socket within a small timing window before the other peers’ TLS handshake can begin. After this sequence of events the closed socket will not immediately attempt a TLS handshake due to not being connected but will also allow the buffered data to be read as if a successful TLS handshake had occurred. Co-Authored-By: Gregory P. Smith [Google LLC] <greg@krypto.org>
ambv
changed the title
⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️Hi! The buildbot AMD64 Windows10 3.11 has failed when building commit 75a875e. What do you need to do:
You can take a look at the buildbot page here: https://buildbot.python.org/all/#builders/986/builds/1085 Summary of the results of the build (if available): == Tests result: ENV CHANGED == 402 tests OK. 10 slowest tests:
1 test altered the execution environment: 31 tests skipped: Total duration: 17 min 33 sec Click to see traceback logsTraceback (most recent call last):
File "D:\buildarea\3.11.bolen-windows10\build\Lib\threading.py", line 1038, in _bootstrap_inner
self.run()
File "D:\buildarea\3.11.bolen-windows10\build\Lib\test\test_ssl.py", line 4945, in run
conn, address = self.listener.accept()
^^^^^^^^^^^^^^^^^^^^^^
File "D:\buildarea\3.11.bolen-windows10\build\Lib\socket.py", line 294, in accept
fd, addr = self._accept()
^^^^^^^^^^^^^^
TimeoutError: timed out
k
|
Sorry, something went wrong.
2 participants
Instances of
ssl.SSLSocketwere vulnerable to a bypass of the TLS handshake and included protections (like certificate verification) and treating sent unencrypted data as if it were post-handshake TLS encrypted data.The vulnerability is caused when a socket is connected, data is sent by the malicious peer and stored in a buffer, and then the malicious peer closes the socket within a small timing window before the other peers’ TLS handshake can begin. After this sequence of events the closed socket will not immediately attempt a TLS handshake due to not being connected but will also allow the buffered data to be read as if a successful TLS handshake had occurred.