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.

Author Dima.Tisnek
Recipients Dima.Tisnek, asvetlov, christian.heimes, fantix, yselivanov
Date 2021-02-05.08:29:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1612513763.24.0.586921297535.issue39951@roundup.psfhosted.org>
In-reply-to
Content
Thank you, Christian, for removing 3.7 target, I was not up to date on Python support schedule.

Regarding protocol violation, let me explain what I've dug up so far... I am not an expert, please feel free to correct me.

TLS up to 1.2
Closing a connection (sending close notifies) closes both directions at once.
However, something like a data race is possible:
Let's say "our" side sent close notify at t0, which arrives at "their" side at t1, and the packet that "their" sent at "t1" arrives back to "us"
 at t2.
"Their" side can legitimately continue to send data during t0..t1, as it has not received the close notify yet.
This data can arrive at "our" side anywhere within t0...t2 period.
Current implementation treats this data as protocol violation.
I don't believe it should, because the data was legitimate at the time it was sent. It should most likely be discarded though.


TLS 1.3 and later
Closing a connection only closes one half of the connection, the other half is closed after the round trip. (I'm not clear whether that's always the case, or if that's an option).
Current implementation is simply unprepared for half-closed connections (I think) and thus in a way, unprepared for TLS 1.3
History
Date User Action Args
2021-02-05 08:29:23Dima.Tisneksetrecipients: + Dima.Tisnek, christian.heimes, fantix, asvetlov, yselivanov
2021-02-05 08:29:23Dima.Tisneksetmessageid: <1612513763.24.0.586921297535.issue39951@roundup.psfhosted.org>
2021-02-05 08:29:23Dima.Tisneklinkissue39951 messages
2021-02-05 08:29:23Dima.Tisnekcreate