Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork33.7k
[3.11] GH-95494: Fix transport EOF handling in OpenSSL 3.0 (GH-95495)#103006
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Merged
Uh oh!
There was an error while loading.Please reload this page.
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
…5495)pythonGH-25309 enabled SSL_OP_IGNORE_UNEXPECTED_EOF by default, with a commentthat it restores OpenSSL 1.1.1 behavior, but this wasn't quite right.That option causes OpenSSL to treat transport EOF as the same asclose_notify (i.e. SSL_ERROR_ZERO_RETURN), whereas Python actually hasdistinct SSLEOFError and SSLZeroReturnError exceptions. (The latter isusually mapped to a zero return from read.) In OpenSSL 1.1.1, the sslmodule would raise them for transport EOF and close_notify,respectively. In OpenSSL 3.0, both act like close_notify.Fix this by, instead, just detecting SSL_R_UNEXPECTED_EOF_WHILE_READINGand mapping that to the other exception type.There doesn't seem to have been any unit test of this error, so fill inthe missing one. This had to be done with the BIO path because it'sactually slightly tricky to simulate a transport EOF with Python's fdbased APIs. (If you instruct the server to close the socket, it getsconfused, probably because the server's SSL object is still referencingthe now dead fd?)(cherry picked from commit420bbb7)Co-authored-by: David Benjamin <davidben@google.com>
This was referencedMar 24, 2023
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading.Please reload this page.
GH-25309 enabled SSL_OP_IGNORE_UNEXPECTED_EOF by default, with a comment
that it restores OpenSSL 1.1.1 behavior, but this wasn't quite right.
That option causes OpenSSL to treat transport EOF as the same as
close_notify (i.e. SSL_ERROR_ZERO_RETURN), whereas Python actually has
distinct SSLEOFError and SSLZeroReturnError exceptions. (The latter is
usually mapped to a zero return from read.) In OpenSSL 1.1.1, the ssl
module would raise them for transport EOF and close_notify,
respectively. In OpenSSL 3.0, both act like close_notify.
Fix this by, instead, just detecting SSL_R_UNEXPECTED_EOF_WHILE_READING
and mapping that to the other exception type.
There doesn't seem to have been any unit test of this error, so fill in
the missing one. This had to be done with the BIO path because it's
actually slightly tricky to simulate a transport EOF with Python's fd
based APIs. (If you instruct the server to close the socket, it gets
confused, probably because the server's SSL object is still referencing
the now dead fd?)
(cherry picked from commit420bbb7)
Co-authored-by: David Benjamindavidben@google.com