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 christian.heimes
Recipients christian.heimes, ddddaaaa, seahoh
Date 2019-12-09.16:26:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1575908767.75.0.184499569809.issue37535@roundup.psfhosted.org>
In-reply-to
Content
The problem is caused by the way how TLS 1.3 works. Select considers a TLS 1.3 socket as readable after the handshake, because there is still data on the line. The server is sending session tickets (usually two) after the handshake has been performed. If you set "context.num_tickets = 0" in server.py or "context.maximum_version = ssl.TLSVersion.TLSv1_2" in either server.py or client.py, your script works. Ticket #37120 has more information on that.

Session tickets are low-level TLS protocol elements. Methods like SSLSocket.pending() and SSLSocket.recv() only act on high-level application protocol data. That's why pending() returns 0 and recv() is blocking. There is no application data available.

You have to take another approach and follow the guidelines in 
https://docs.python.org/3/library/ssl.html#notes-on-non-blocking-sockets . You also have to set the SSLSocket into non-blocking mode and handle SSLWantWriteError or SSLWantReadError.
History
Date User Action Args
2019-12-09 16:26:07christian.heimessetrecipients: + christian.heimes, ddddaaaa, seahoh
2019-12-09 16:26:07christian.heimessetmessageid: <1575908767.75.0.184499569809.issue37535@roundup.psfhosted.org>
2019-12-09 16:26:07christian.heimeslinkissue37535 messages
2019-12-09 16:26:07christian.heimescreate