Question about thread safety and SSL_CTX* and its SSL*

[Thomas Bailleux]

> Perhaps you're freeing some objects that are owned by the library, or
> continuting to use objects that the library owned and freed.
I don't think so, I'm using the reference counter whenever I can (for instance with the trust store). Also, SSL_CTX is never destroyed.

> What you're doing should work, if implemented correctly, but my advice
> is to not use SSL_clear(), rather create a fresh (SSL *) handle for
> each connection.  These are cheap enough to not warrant recycling.
Using a fresh (SSL *) seems to work.

So I guess there is something wrong with SSL_clear() ?

> On 27 Sep 2022, at 18:42, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
> 
> On Tue, Sep 27, 2022 at 06:35:47PM +0200, Thomas Bailleux wrote:
> 
>> However, I am still facing issues when I use `SSL_CTX` and `SSL` objects.
>> 
>> I use `SSL_CTX` and `SSL` inside a threaded application. Threads are managed using pthread primitives.
>> 
>> Basically, I create a `SSL_CTX`, and I fill it depending on the TLS method.
>> At this point, the `SSL_CTX` is final. I never change it again.
>> 
>> Then, I create n `SSL`s from the `SSL_CTX`, and I spawn n pthreads.
>> Each pthread takes the ownership of a single `SSL`. Finally, each
>> pthread is going to use its `SSL` object for establishing some TLS
>> connections.  `SSL` objects never get destroyed, instead I use
>> `SSL_clear` for kind of recycling them.
> 
> Perhaps you're freeing some objects that are owned by the library, or
> continuting to use objects that the library owned and freed.
> 
>> My question is: Is my app thread safe ? I wonder, because I am facing
>> random null deref.  If I create a `SSL_CTX` for each thread,
>> everything is fine.
> 
> What you're doing should work, if implemented correctly, but my advice
> is to not use SSL_clear(), rather create a fresh (SSL *) handle for
> each connection.  These are cheap enough to not warrant recycling.
> 
> -- 
>    Viktor.