Is Python SSL API thread-safe?

[Grant Edwards]

Is the Python SSL API thread-safe with respect to recv() and send()?

IOW, can I have one thread doing blocking recv() calls on an SSL
connection object while "simultaneously" a second thread is calling
send() on that same connection object?

I assumed that was allowed, but I can't find anything in the
documentation that actually says it is.

--
Grant

[Jon Ribbens]

On 2017-01-22, Grant Edwards <grant.b...@gmail.com> wrote:
> Is the Python SSL API thread-safe with respect to recv() and send()?
>
> IOW, can I have one thread doing blocking recv() calls on an SSL
> connection object while "simultaneously" a second thread is calling
> send() on that same connection object?

I think this question is equivalent to asking "is OpenSSL thread-safe",
the answer to which would appear to be "yes":
https://www.openssl.org/docs/man1.0.2/crypto/threads.html
(the necessary functions mentioned on that page, threadid_func and
locking_function are indeed set by Python).

[Christian Heimes]

On 2017-01-22 21:18, Grant Edwards wrote:
> Is the Python SSL API thread-safe with respect to recv() and send()?
>
> IOW, can I have one thread doing blocking recv() calls on an SSL
> connection object while "simultaneously" a second thread is calling
> send() on that same connection object?
>

> I assumed that was allowed, but I can't find anything in the
> documentation that actually says it is.

OpenSSL and Python's ssl module are thread-safe. However IO is not safe
concerning reentrancy. You cannot safely share a SSLSocket between
threads without a mutex. Certain aspects of the TLS protocol can cause
interesting side effects. A recv() call can send data across a wire and
a send() call can receive data from the wire, e.g. during re-keying.

In order to archive reentrancy, you have to do all IO yourself by
operating the SSL connection in non-blocking mode or with a Memorio-BIO
https://docs.python.org/3/library/ssl.html#ssl-nonblocking

[Grant Edwards]

IOW, what I'm doing is not safe. Rats.

--
Grant

[Grant Edwards]

On 2017-01-22, Christian Heimes <chri...@python.org> wrote:

> OpenSSL and Python's ssl module are thread-safe. However IO is not
> safe concerning reentrancy. You cannot safely share a SSLSocket
> between threads without a mutex. Certain aspects of the TLS protocol
> can cause interesting side effects. A recv() call can send data
> across a wire and a send() call can receive data from the wire,
> e.g. during re-keying.

And it looks to me like the Python SSL module does all of that. It
provides mutexes and thread ID and locking callbacks as described in
the page below:

https://www.openssl.org/docs/man1.0.2/crypto/threads.html

According to that page above it's safe to share the socket between
threads:

OpenSSL can safely be used in multi-threaded applications provided
that at least two callback functions are set, locking_function and
threadid_func.

They python ssl module code does that, so python ssl sockets should be
thread safe.

Can you explain why you disagree?

Can you provide example code that demonstrates a failure?

> In order to archive reentrancy, you have to do all IO yourself by
> operating the SSL connection in non-blocking mode or with a
> Memorio-BIO https://docs.python.org/3/library/ssl.html#ssl-nonblocking

That section is about how to work with non-blocking sockets. I'm not
using non-blocking sockets.

--
Grant Edwards grant.b.edwards Yow! Now I'm concentrating
at on a specific tank battle
gmail.com toward the end of World
War II!