SSL_read & SSL_write at the same time

[mickae1]

Could you make calling SSL_read and SSL_write at the same time possible ? ( SSL_read is blocking in a thread, and SSL_write is called in another thread)

Because it's difficult to make it happen in windows/linux environment with the non blocking mode.

Openssl has everything inside to make it happen. Why not make it possible inside of openssl lib ?

[mattcaswell]

This is non-trivial to achieve because it essentially means that the SSL object would have to be thread safe. That has major implications to OpenSSL internally.

[mickae1]

@mattcaswell I understand but openssl ( the ssl parts ) should be thread safe. Maybe with openssl 3, this should be doable ?

[mattcaswell]

I understand but openssl ( the ssl parts ) should be thread safe.

OpenSSL is thread safe as long as you obey the rules. You cannot share (most) OpenSSL objects between threads. As long as you are calling them on different objects it is perfectly possible to call SSL_read() and SSL_write() at the same time from different threads.

What you are asking for has significant implications. Most notably it would require us to implement locking at the object level for all function calls. This is likely to be very expensive from a performance perspective. So, while its technically feasible to do that, it is far from clear that the advantages outweigh the disadvantages.

Maybe with openssl 3, this should be doable ?

It would be a major refactor - which probably would rule it out for OpenSSL 3.x. Given the issue I describe above I doubt we will ever do this. Conceivably, you could think of some sort of optional locking scheme that you could configure to "on" for those applications that want to take the performance hit. But I doubt it is worth it.

[mickae1]

OK, I get it. I found that wolfssl has a feature that can be enabled with the build option `HAVE_WRITE_DUP` It allow to duplicate the ssl handle. One handle for the read and one handle for the write. Do you think it's possible to do the same thing with openssl. https://www.wolfssl.com/forums/topic1562-thread-safety.html

[mattcaswell]

One handle for the read and one handle for the write.

Hmm. That's an interesting idea. That may be possible (although again its non-trivial to implement). It's actually not too far removed from QUICs concept of multiple streams which we are planning to add to the master branch soon (i.e. for OpenSSL 3.2). That gives you a different SSL object for each stream associated with a single connection (where a stream can be uni-directional or bi-directional). That's for QUIC though, not TLS. You could imagine the same concept being applied to TLS where, by default you get a single bi-directional SSL object - but optionally you instead get two uni-directional ones.

I wonder if @hlandau has any thoughts on that.

[hlandau]

The plan for QUIC is basically to allow different streams to be used from different threads concurrently. Of course those are separate SSL objects, but associated with the same QUIC connection. But it's not really any harder to allow SSL_write and SSL_read to be called concurrently on the same stream of a QUIC connection. That would be for QUIC only and not TLS.

It seems to me like for TLS, the record layer after a handshake is completed isn't much of a problem, but there are post-handshake handshake-layer messages which might need processing and this raises questions. Though we are having to deal with similar things with QUIC's CRYPTO frames internally.

[mattcaswell]

Handling at the record layer for TLS is actually quite straight forward in the master branch. We already have a separate read and write record layer object internally with separate state. The problems would occur above the record layer...i.e. like you said what happens if we receive a non-app data record that requires some subsequent writing (e.g key update message with "update requested" set).

[mickae1]

So it's doable 👍😉

[mattcaswell]

So it's doable

It would be quite tricky to get right and may require some significant refactoring. But doable. Whether it will become a priority any time soon is another question!

[mickae1]

I understand,

but a lot of people rely on openssl to do TLS in their application, and because openssl doesn't support SSL_Read & SSL_Write at the same time, they have to use non blocking mode for the socket.

Therefore it puts a lot of efforts to do it with the openssl lib.
This imply errors if not correctly implemented.
It's a hard work.

If one day the developer of openssl put efforts on this feature, this would improve a lot the implementation of openssl in project.

( I tried SSL_read & SSL_write in different thread, I got disconnect errors some time .... :( )

[mickae1]

@mattcaswell can you add it to the roadmap please :)