Maybe we should expose the SSL_CTX_set_num_tickets function:

https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_num_tickets.html

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:

  https://github.com/openssl/openssl/issues/7967
  https://github.com/openssl/openssl/issues/7948

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.

Questions:

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 https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_session_ticket_cb.html)

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...

+1 for the idea

Yes, for simple flags and settings, an attribute on the SSLContext is prefer. The SSLContext object is the configuration space for its connections. I would prefer to keep the setting only on the context and not clutter SSLSocket and SSLObject with additional attributes. PR 13719 goes one step further and restricts the setter to a PROTOCOL_TLS_SERVER, too.

Let's look in the callback another time. I won't be able to come up with a wrapper for that in the next three days.

New changeset 78c7d527799dacca91b9ed67057cb996efe526b0 by Christian Heimes in branch 'master':
bpo-37120: Add SSLContext.num_tickets (GH-13719)
https://github.com/python/cpython/commit/78c7d527799dacca91b9ed67057cb996efe526b0

I have merged the PR to land the feature in time for the feature freeze.

Regarding your comment on client_context.num_ticket getter: IMHO it's not a good idea to raise an exception on attribute access. It may break introspection.

> Regarding your comment on client_context.num_ticket getter: IMHO it's not a good idea to raise an exception on attribute access. It may break introspection.

Hmm, I see what you mean.

Basically my intuition is: it's a bit weird to make the attribute's existence "sort of" depend on whether it's a client or server context. It would make sense to me to have it entirely disappear on client contexts (from __dir__, read-access, and write-access), and it would make sense to me to have it always be present, just a no-op. But having it present, and almost the same as on server contexts, except that assigning to it fails... that feels a little weird.

New changeset 78c7d527799dacca91b9ed67057cb996efe526b0 by Christian Heimes in branch 'master':
bpo-37120: Add SSLContext.num_tickets (GH-13719)
https://github.com/python/cpython/commit/78c7d527799dacca91b9ed67057cb996efe526b0


This change introduced this warning on Windows:

c:\vstinner\python\master\modules\_ssl.c(3624): warning C4267: 'function': conv 
ersion from 'size_t' to 'long', possible loss of data [C:\vstinner\python\maste 
r\PCbuild\_ssl.vcxproj]


SSL_CTX_get_num_tickets() return type is size_t. I suggest this change:


diff --git a/Modules/_ssl.c b/Modules/_ssl.c
index 2331c58ad7..3ffb6380d3 100644
--- a/Modules/_ssl.c
+++ b/Modules/_ssl.c
@@ -3621,7 +3621,7 @@ set_maximum_version(PySSLContext *self, PyObject *arg, void *c)
 static PyObject *
 get_num_tickets(PySSLContext *self, void *c)
 {
-    return PyLong_FromLong(SSL_CTX_get_num_tickets(self->ctx));
+    return PyLong_FromSize_t(SSL_CTX_get_num_tickets(self->ctx));
 }
 
 static int

New changeset 76611c7c0af6b2f4d0d98a5db827d34cff54ce25 by Miss Islington (bot) (Victor Stinner) in branch 'master':
bpo-37120: Fix _ssl get_num_tickets() (GH-14668)
https://github.com/python/cpython/commit/76611c7c0af6b2f4d0d98a5db827d34cff54ce25

New changeset bbad695e7890513be7a9bc662e2d8ae13bfcd313 by Miss Islington (bot) in branch '3.8':
bpo-37120: Fix _ssl get_num_tickets() (GH-14668)
https://github.com/python/cpython/commit/bbad695e7890513be7a9bc662e2d8ae13bfcd313