Instances of ssl.SSLSocket are 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 if the socket is closed before initiating its own handshake.

This vulnerability is of severity: HIGH.

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.

Affected usages

This vulnerability primarily affects HTTPS servers and other server-side protocols using TLS client authentication (such as mTLS) due to requiring reading data immediately after the handshake to be vulnerable. Operations which would fail on a closed socket (like sending data) immediately after the handshake are not affected by this vulnerability.

Because disconnecting the socket is a necessary step to trigger the vulnerability there is no risk of data exfiltration or data leakage directly from the malicious TLS connection, however the vulnerability does carry risk for modifying or deleting resources which are authenticated using only TLS client certificates.

This vulnerability affects clients who are reading and processing data from the server after a TLS handshake without sending any data first. Our team is unaware of a protocol that uses TLS that fits this usage pattern.

This vulnerability does not affect client-side HTTPS connections like pip or requests as an HTTP request must be sent before an HTTP response is read meaning the connection would already be closed by the time the client is sending an HTTP request, leading to an error.

This vulnerability affects, but has no impact on servers that aren’t using TLS client certificate authentication as traffic to a non-authenticating TLS server loses nothing from a bypassed handshake to inject a query and close the connection as the same action could be taken by a peer using a TLS connection with a proper handshake.

Affected versions