Hi,
I have read some postings on the mail-archive so far, but I could not find out
what goes wrong in my application. I have a client server architecture where
the server master waits for incoming connections from the client and then forks
a slave which will then start a TLS connection to the client and process all
further commands send through the now secured communication channel. This works
so far. Now it is possible that the client requests an operation that should be
performed in the background while the dedicated server slave remains responsive
to the client. Therefore a worker thread is created which runs asynchronously
to the main thread (the server slave). This worker thread should be able to
communicate over the same TLS-connection with the client, thus creating a
concurrency situation with respect to the SSL object that has been created
before for this connection.
I have implemented the functions required be CRYPTO_set_id_callback() and
CRYPTO_set_locking_callback() similar to the example shown in
crypto/threads/mttest.c. Now when the worker thread tries to perform a write on
the SSL object via SSL_write everything seems to go well (at least
SSL_get_error returns with SSL_ERROR_NONE). But the next time the main thread
(server slave) does a SSL_read an SSL_ERROR_SSL is returned with the associated
error text
SSL3_READ_BYTES:sslv3 alert bad record mac:s3_pkt.c:1061:SSL alert number 20
The debugging output of the locking-callback-function
fprintf(stderr,"thread=% ld mode=%s lock=%s %s:%d\n",
CRYPTO_thread_id(),
(mode&CRYPTO_LOCK)?"l":"u",
(type&CRYPTO_READ)?"r":"w",file,line);
indicates two remarkable things:
1. The thread id returned by CRYPTO_thread_id() is always the one of the main
thread.
2. There are a lot of lock/unlock-operations performed but none right before
the SSL_read or SSL_write call
which leads me to the impression that nothing is being done about protecting
these calls from concurrency
problems.
These two points make sense if the multi-thread locking mechanism actually does
not secure the SSL object from concurrent access. That's why I surrounded my
wrapper functions to SSL_read/SSL_write with a call to pthread_mutex_lock and
pthread_mutex_unlock respectively. However this does not solve the problem. As
I check the return values of SSL_read and SSL_write conscientiously I can tell,
that I have no SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE errors going on.
Is there something else that could lead to the above error message, which I
didn't take into account yet?
Any help would be greatly appreciated.
Regards,
Martin
