Thanks to visit codestin.com
Credit goes to github.com

Skip to content

SSLObject does not raise SSLEOFError on OpenSSL 3 #90471

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.

Sign up for GitHub

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

Jump to bottom
Closed
agronholm mannequin opened this issue Jan 9, 2022 · 9 comments
Closed

SSLObject does not raise SSLEOFError on OpenSSL 3 #90471

agronholm mannequin opened this issue Jan 9, 2022 · 9 comments
Labels
3.8 (EOL) end of life 3.9 only security fixes 3.10 only security fixes 3.11 only security fixes topic-SSL type-bug An unexpected behavior, bug, or error

Comments

@agronholm
Copy link
Mannequin

agronholm mannequin commented Jan 9, 2022

BPO 46313
Nosy @agronholm, @ambv

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2022-01-09.13:40:17.069>
labels = ['expert-SSL', 'type-bug', '3.8', '3.9', '3.10', '3.11']
title = 'SSLObject does not raise SSLEOFError on OpenSSL 3'
updated_at = <Date 2022-01-10.11:26:36.211>
user = 'https://github.com/agronholm'

bugs.python.org fields:

activity = <Date 2022-01-10.11:26:36.211>
actor = 'christian.heimes'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['SSL']
creation = <Date 2022-01-09.13:40:17.069>
creator = 'alex.gronholm'
dependencies = []
files = []
hgrepos = []
issue_num = 46313
keywords = []
message_count = 8.0
messages = ['410146', '410150', '410159', '410162', '410164', '410165', '410199', '410201']
nosy_count = 2.0
nosy_names = ['alex.gronholm', 'lukasz.langa']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue46313'
versions = ['Python 3.8', 'Python 3.9', 'Python 3.10', 'Python 3.11']
@agronholm
Copy link
Mannequin Author

agronholm mannequin commented Jan 9, 2022

PR bpo-25309 (#25309) changed OpenSSL behavior so that it ignores unexpected EOFs by default. This was detected by the test suites of both trio and AnyIO when running on OpenSSL 3.

We worked around the problem by explicitly unsetting the SSL_OP_IGNORE_UNEXPECTED_EOF flag and then checking if the "strerror" attribute of SSLError contains the text "UNEXPECTED_EOF_WHILE_READING".

The remedy in the standard library would be twofold:

  1. Revert the change of enabling SSL_OP_IGNORE_UNEXPECTED_EOF by default
  2. Handle the condition properly so that SSLEOFError is raised instead of the generic SSLError

As SSLSockets ignore SSLEOFError by default, this fix should work fine for those too.

@agronholm agronholm mannequin assigned tiran Jan 9, 2022
@agronholm agronholm mannequin added type-security A security issue 3.8 (EOL) end of life 3.9 only security fixes 3.10 only security fixes 3.11 only security fixes topic-SSL labels Jan 9, 2022
@agronholm agronholm mannequin assigned tiran Jan 9, 2022
@agronholm agronholm mannequin added type-security A security issue 3.8 (EOL) end of life labels Jan 9, 2022
@tiran tiran removed their assignment Jan 9, 2022
@tiran tiran added type-bug An unexpected behavior, bug, or error and removed type-security A security issue labels Jan 9, 2022
@agronholm
Copy link
Mannequin Author

agronholm mannequin commented Jan 9, 2022

This is a security issue because it exposes users to TLS truncation attacks that weren't possible before because such attempts would raise SSLEOFError.

@tiran
Copy link
Member

tiran commented Jan 9, 2022

This is not a security issue because OpenSSL 3.0.0 is not officially supported yet. OpenSSL 3.0.0 support is prelimiary, experimental, and provisional.

From https://docs.python.org/3/whatsnew/3.10.html#ssl

The ssl module has preliminary support for OpenSSL 3.0.0.

@agronholm
Copy link
Mannequin Author

agronholm mannequin commented Jan 9, 2022

I hope the Fedora maintainers/packagers know this because on Rawhide, Python is being compiled against OpenSSL 3 (which is how we discovered the problem). F36 is due out in a little over 3 months.

@tiran
Copy link
Member

tiran commented Jan 9, 2022

Petr and Charis are aware that there are issues with OpenSSL 3.0 support. RHEL 9 FIPS support is broken as well. It's also documented in the release notes and I just wrote an email to python-dev, too.

@agronholm
Copy link
Mannequin Author

agronholm mannequin commented Jan 9, 2022

Good to see that this is being handled. I could try to write a patch to do what I suggested above, if you're willing to review it.

@agronholm
Copy link
Mannequin Author

agronholm mannequin commented Jan 10, 2022

I just noticed that Ubuntu 22.04 LTS also uses OpenSSL 3 with their Python builds. I hope somebody has told them too about the state of affairs.

@tiran
Copy link
Member

tiran commented Jan 10, 2022

That's not how OSS work. Python core development does not have resources to provide proactive support for all Linux distros in the world. We provide documentation and guidance. I assume that paid package maintainers of a commercial Linux vendor perform their due diligence, read the release notes, and follow upstream development discussions.

PS: I'm unsubscribing from this bpo now.

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
@gpshead
Copy link
Member

gpshead commented Nov 3, 2022

duplicate of #95494

@gpshead gpshead closed this as not planned Won't fix, can't repro, duplicate, stale Nov 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
3.8 (EOL) end of life 3.9 only security fixes 3.10 only security fixes 3.11 only security fixes topic-SSL type-bug An unexpected behavior, bug, or error
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@gpshead @tiran