I could resolve the problem. It was not caused by a not correctly implemented
locking of the SSL object so that multiple threads would have been able to
operate concurrently on it. The problem was that I forked another process from
within one thread, that also used the SSL connection. When the p
Martin Domke wrote:
> Do I have to protect the SSL object on my own from concurrent access?
Yes, you do. If you didn't that's your problem. Both SSL_read and SSL_write
are logically modification operations on the SSL object (because they can
change its state). You cannot perform a modification o
For all interested this is the output of the ssldump. As you can see at the end
the connection abruptly aborts with the error "Length missmatch".
> SSL3_READ_BYTES:sslv3 alert bad record mac:s3_pkt.c:1061:SSL alert number 20
> sudo /usr/sbin/ssldump -dA -i lo port 9111
New TCP connection #1: loc
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 c
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 c
