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 njs
Recipients alex, christian.heimes, dstufft, janssen, njs
Date 2019-06-01.05:05:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Maybe we should expose the SSL_CTX_set_num_tickets function:

This is a new function added in OpenSSL 1.1.1, that lets you control the number of tickets issued by a TLS 1.3 connection.

It turns out that by default, openssl 1.1.1 issues 2 tickets at the end of the server handshake. In principle this can cause deadlocks and data corruption:

And my problem specifically is that this pretty much kills all of Trio's fancy protocol testing helpers, because any protocol that's built on top of TLS is automatically broken as far as the helpers are concerned. And they're right. Right now I have to disable TLS 1.3 entirely to get Trio's test suite to avoid deadlocking.

Hopefully the openssl devs will fix this, but so far their latest comment is that they consider this a feature and so they think it has to stay broken for at least RHEL 8's lifetime.

Currently the only workaround is to either disable TLS 1.3, or disable tickets. But the 'ssl' module doesn't expose any way to control tickets. This issue proposes to add that.

Fortunately, exposing SSL_CTX_set_num_tickets should be pretty trivial, at least in theory.


Do we have a preferred convention for how to expose these kinds of settings at the Python level? Attribute on SSLContext?

There's both an SSL* and a SSL_CTX* – I guess the CTX version is sufficient, or is there another convention?

As a bonus complication, openssl sometimes ignores the configured number of tickets, and uses a completely different mechanism:

> The default number of tickets is 2; the default number of tickets sent following a resumption handshake is 1 but this cannot be changed using these functions. The number of tickets following a resumption handshake can be reduced to 0 using custom session ticket callbacks (see

Do we want to open the can-of-worms involved in wrapping this too? I think if we only wrapped SSL_CTX_set_num_tickets then that would be enough to let me kluge my tests into passing and pretend that things are just fine, so long as we don't test session resumption...
Date User Action Args
2019-06-01 05:05:29njssetrecipients: + njs, janssen, christian.heimes, alex, dstufft
2019-06-01 05:05:29njssetmessageid: <>
2019-06-01 05:05:29njslinkissue37120 messages
2019-06-01 05:05:28njscreate