[issue27815] Make SSL suppress_ragged_eofs default more secure

Change by Joshua Bronson : -- nosy: +jab ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue27815] Make SSL suppress_ragged_eofs default more secure

Christian Heimes added the comment: For example an invalid host name should invalidate the session until #31399 is resolved. Any TLS protocol violation should also invalidate the session. If somebody messes with the connection or the TLS protocol encounters a problem during

[issue27815] Make SSL suppress_ragged_eofs default more secure

Nathaniel Smith added the comment: Why would an exception inside 'with ssl_sock' have anything to do with the validity of the session shared secret? I mean, maybe it does, but I *really* don't think we should be waving our hands and guessing about this stuff. --

[issue27815] Make SSL suppress_ragged_eofs default more secure

Christian Heimes added the comment: Perhaps a hard close is the right thing when SSLSocket.__exit__ encounters an exception? -- ___ Python tracker

[issue27815] Make SSL suppress_ragged_eofs default more secure

STINNER Victor added the comment: I don't know well, Cheryl's PR wasn't added to this issue: https://github.com/python/cpython/pull/5266 -- pull_requests: +5113 stage: -> patch review ___ Python tracker

[issue27815] Make SSL suppress_ragged_eofs default more secure

Nathaniel Smith added the comment: It doesn't help that Python spells SSL_shutdown as "unwrap". I think in practice basically the only two things you want are unidirectional shutdown, or "soft" shutdown. Bidirectional shutdown has some extremely theoretical uses, and we have

[issue27815] Make SSL suppress_ragged_eofs default more secure

Christian Heimes added the comment: You have to tell OpenSSL that a hard-close is expected and fine. If you just SSL_free() the SSL connection, then OpenSSL removes the session from the SSL_CTX's session cache. It assumes that something went wrong and defaults to secure

[issue27815] Make SSL suppress_ragged_eofs default more secure

Nathaniel Smith added the comment: @Christian: I'm surprised and somewhat dismayed to hear that OpenSSL invalidates sessions on hard close -- that hasn't been part of the spec since 2006 when TLS 1.1 came out. I'm not a cryptographer, but the spec explicitly allows keeping

[issue27815] Make SSL suppress_ragged_eofs default more secure

Christian Heimes added the comment: Before we can disable ragged EOF handling, we first have to fix ssl.SSLSocket()'s shutdown behavior. It should support at least a proper unidirectional shutdown besides the slow bidirectional shutdown. It might even be a good idea to

[issue27815] Make SSL suppress_ragged_eofs default more secure

Nathaniel Smith added the comment: The current default is hard to defend -- it's a clear violation of the TLS specs. But I suspect that changing it will be pretty disruptive, because suppress_ragged_eof=True is the de facto standard for HTTP-over-TLS (generally justified on

[issue27815] Make SSL suppress_ragged_eofs default more secure

Cheryl Sabella added the comment: I converted the patch to a PR. It wouldn't merge which means I did it manually, so please check it for errors. Some issues I ran into: 1. The patch had a change to __slots__, but that line no longer existed and I didn't know if I needed

[issue27815] Make SSL suppress_ragged_eofs default more secure

Martin Panter added the comment: Even if some use cases depend on suppress_ragged_eofs=True, I think it is best to avoid that as the default. There could be a deprecation period if necessary. I tested some HTTP clients I had handy. In summary, most seemed to handle a truncation attack on the

[issue27815] Make SSL suppress_ragged_eofs default more secure

Alex Gaynor added the comment: Mmmm, my understanding is that ignoring TCP-FIN/RST-without-TLS-closenotify is pretty common for a lot of different clients. We should probably survey the landscape, see what both browsers and non-browse clients (e.g. curl) do before making a decision.

[issue27815] Make SSL suppress_ragged_eofs default more secure

STINNER Victor added the comment: Martin: can you please create a pull request? It would be easier to review your change. -- ___ Python tracker ___

[issue27815] Make SSL suppress_ragged_eofs default more secure

Christian Heimes added the comment: I don't consider myself qualified enough to make a decision. Alex, Victor, what do you think? -- assignee: christian.heimes -> nosy: +alex, haypo ___ Python tracker

[issue27815] Make SSL suppress_ragged_eofs default more secure

Martin Panter added the comment: Patch v2 also adds a new attribute to context objects. With this I can work around my Google server bug: context = ssl.create_default_context(ssl.Purpose.SERVER_AUTH) context.suppress_ragged_eofs = True handler = urllib.request.HTTPSHandler(context=context)

[issue27815] Make SSL suppress_ragged_eofs default more secure

Martin Panter added the comment: I have been experimenting with a patch that changes the default to suppress_ragged_eofs=False. One disadvantage of this change is it could make servers less robust. E.g. in the tests, I explicitly enabled suppress_ragged_eofs=True in a server, because

[issue27815] Make SSL suppress_ragged_eofs default more secure

Changes by Christian Heimes : -- assignee: -> christian.heimes components: +SSL nosy: +christian.heimes ___ Python tracker ___

[issue27815] Make SSL suppress_ragged_eofs default more secure

New submission from Martin Panter: In the SSL module, the wrap_socket() function (and corresponding SSLContext method) take a flag called “suppress_ragged_eofs”. It defaults to True, which makes me uncomfortable. The documentation says: ''' The parameter “suppress_ragged_eofs” specifies how