➜
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2021-04-09 14:13 by christian.heimes, last changed 2022-04-11 14:59 by admin. This issue is now closed.
| Pull Requests | |||
|---|---|---|---|
| URL | Status | Linked | Edit |
| PR 25309 | merged | christian.heimes, 2021-04-09 14:44 | |
| PR 25313 | merged | miss-islington, 2021-04-09 15:59 | |
| PR 25314 | merged | miss-islington, 2021-04-09 15:59 | |
| Messages (6) | |||
|---|---|---|---|
| msg390632 - (view) | Author: Christian Heimes (christian.heimes) *  |
Date: 2021-04-09 14:13 | |
OpenSSL 3.0.0 state machine handles unexpected EOFs more strict and requires peers to properly shut down connections. The old OpenSSL 1.1.1 behavior can be get back with SSL_OP_IGNORE_UNEXPECTED_EOF. I propose to add the option by default until Python's ssl module has better ways to perform one-way shutdown of connections. https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_options.html > Some TLS implementations do not send the mandatory close_notify alert on shutdown. If the application tries to wait for the close_notify alert but the peer closes the connection without sending it, an error is generated. When this option is enabled the peer does not need to send the close_notify alert and a closed connection will be treated as if the close_notify alert was received. > You should only enable this option if the protocol running over TLS can detect a truncation attack itself, and that the application is checking for that truncation attack. |
|||
| msg390640 - (view) | Author: Christian Heimes (christian.heimes) * |
Date: 2021-04-09 15:59 | |
New changeset 6f37ebc61e9e0d13bcb1a2ddb7fc9723c04b6372 by Christian Heimes in branch 'master': bpo-43794: OpenSSL 3.0.0: set OP_IGNORE_UNEXPECTED_EOF by default (GH-25309) https://github.com/python/cpython/commit/6f37ebc61e9e0d13bcb1a2ddb7fc9723c04b6372 |
|||
| msg390642 - (view) | Author: miss-islington (miss-islington) | Date: 2021-04-09 16:21 | |
New changeset e18ebd9ec546a3647a57c282735350f60a26d66d by Miss Islington (bot) in branch '3.8': bpo-43794: OpenSSL 3.0.0: set OP_IGNORE_UNEXPECTED_EOF by default (GH-25309) https://github.com/python/cpython/commit/e18ebd9ec546a3647a57c282735350f60a26d66d |
|||
| msg390643 - (view) | Author: miss-islington (miss-islington) | Date: 2021-04-09 16:21 | |
New changeset 54d89a33e0d1b854fd5a72889d6554aeeb4170f0 by Miss Islington (bot) in branch '3.9': bpo-43794: OpenSSL 3.0.0: set OP_IGNORE_UNEXPECTED_EOF by default (GH-25309) https://github.com/python/cpython/commit/54d89a33e0d1b854fd5a72889d6554aeeb4170f0 |
|||
| msg392699 - (view) | Author: Christian Heimes (christian.heimes) * |
Date: 2021-05-02 14:07 | |
I have updated whatsnew in GH-25817. |
|||
| msg408350 - (view) | Author: Alex Grönholm (alex.gronholm) * | Date: 2021-12-11 23:41 | |
OpenSSL 1.1.1 also handled EOFs strictly, but this behavior was generally suppressed in the ssl module through the default setting of suppress_ragged_eofs=True (thus enabling truncation attacks by default). The PR changes the behavior of existing applications in such a way that previously detectable unexpected EOFs are now no longer detectable by default. To make matters worse, EOF errors are not translated to SSLEOFError anymore, and instead I have to match the strerror attribute in SSLError to detect this condition. |
|||