SSL read and SSL write simultaneously

Question

I have two threads, mainThread and recvThread.

On recvThread, I call SSL_read(ssl, readBuffer, sizeof(readBuffer)). This blocks the thread until data is received.

Then, on mainThread I get told that some data needs to be sent. So, I call SSL_write(ssl, someData, sizeof(someData)).

Sometimes, this works fine. Other times, this fails with wierd internal error messages. My guess is that I can't call SSL_write whilst an SSL_read is occurring on the same ssl context. This makes total sense to me, but how do I fix it?

Do I make recvThread do something like:

SSL * ssl;
std::string data;
boost::mutex dataMutex;

while (recvThreadShouldBeRunning) {
    char readBuffer[100];
    auto nRead = SSL_read(ssl, readBuffer, sizeof(readBuffer)); //Non-blocking call to SSL_read.

    // Do something with nRead (handle errors, use data)

    {
        auto dataLock = boost::unique_lock<boost::mutex>(dataMutex);
        if (data.length() > 0)
        {
            SSL_write(ssl, data.c_str(), data.length());
        }
    }
    sleep(50);
}

and then when I need to send something...

{
    auto dataLock = boost::unique_lock<boost::mutex>(dataMutex);
    data = "some data";
}

This seems like it will work, but I think it is a rather ugly solution to my problem. Is there a way to somehow SSL_lock() SSL_wait_on_data() SSL_unlock()? Or is this the best way to go about it?

What is the standard way to go about this sort of problem?

Thanks for your time.

Note that socket providers do not guarantee two different threads can read and write on the same socket at the same time. But it seems to work. — brian beuning, Feb 03 '14 at 12:59
@brianbeuning TCP guarantees that. It's a full-duplex connection. — user207421, Feb 03 '14 at 22:15
Have you looked at ? [OpenSSL threads](http://www.openssl.org/docs/crypto/threads.html) — brian beuning, Feb 03 '14 at 12:57
@EJP I'm afraid that no matter what TCP guarantees, SSL does not guarantee it... As I said, I'm getting strange internal errors only some of the time, really good indication of thread problems. So normally with winsock, you'd just do what I'm doing now right? And that would be fine? — AStupidNoob, Feb 04 '14 at 06:18
Related question: [Using OpenSSL (C++ on Ubuntu) in a multi-threaded (pthreads) manner](http://stackoverflow.com/q/11251859). — Sergey Vyacheslavovich Brunov, Jul 01 '15 at 00:04
Related question: [C++ call back function](http://stackoverflow.com/q/17280301). — Sergey Vyacheslavovich Brunov, Jul 01 '15 at 00:05
Related question: [OpenSSL and multi-threads](http://stackoverflow.com/q/3417706). — Sergey Vyacheslavovich Brunov, Jul 01 '15 at 00:07
@AStupidNoob I was specifically replying to a specific statement about 'socket providers'. SSL libraries are not socket providers. — user207421, Jul 01 '15 at 01:34

score 1 · Answer 1 · answered Jun 30 '15 at 23:53

The quote from the documentation seems to contain the answer:

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

locking_function(int mode, int n, const char *file, int line) is needed to perform locking on shared data structures. (Note that OpenSSL uses a number of global data structures that will be implicitly shared whenever multiple threads use OpenSSL.) Multi-threaded applications will crash at random if it is not set.

locking_function() must be able to handle up to CRYPTO_num_locks() different mutex locks. It sets the n-th lock if mode & CRYPTO_LOCK, and releases it otherwise.

file and line are the file number of the function setting the lock. They can be useful for debugging.

-- threads - OpenSSL.

The example of using the locking-related functions (github):

crypto/threads/mttest.c shows examples of the callback functions on Solaris, Irix and Win32.

-- threads - OpenSSL.

This does not mean you can read/write to the same SSL handle at the same time. — zapstar, Feb 01 '18 at 09:15

SSL read and SSL write simultaneously

1 Answers1

Linked