Regression in 1.1.1 against 1.1.0 in SSL_CTX_new

Harald Koch root at c-works.net
Thu Apr 16 19:41:23 UTC 2020


Am 16.04.2020 um 17:54 schrieb Tomas Mraz <tmraz at redhat.com>:
> 
> error queue of openSSL stays empty. The same code works with
>> openSSL with gzip support („./config enable-zlib ...“, for support of
>> compressed SMIME contents in other application).
>> Do you call the OPENSSL_init_ssl from the main thread or from the
>>> TLS
>>> server thread?
>> I call it from the TLS server thread (created by pthread_create):
>> 
>> if (!OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS, NULL))
>> 	return;
>> I tried to do it only once (instead of every started thread): no
>> difference.
> I do not see how this error could really happen unless
> OPENSSL_cleanup() is called.
> 
> Could you try to set a breakpoint on that function and see if it is
> somehow called inadvertently?
gdb is actually unavailable, so I added a big „printf“ at the beginning of crypto/init.c, recompiled (even without zlib support as I’ve seen there’s much functionality in there), function OPENSSL_cleanup: it’s not called. I’m very sure OPENSSL_cleanup is not called. 

> In addition, I load random data via /dev/urandom (also tested only
>> once or every time the server thread starts):
>> 	RAND_load_file("/dev/urandom", 256);
> That call should not be necessary.
I removed it just in case it may have an influence. No better result. :(


I have a workaround and possibly it’s the solution, I would like to have your valuable statement here: you asked where I call OPENSSL_init_ssl: it’s done in the thread for TLS server. When I initialize it earlier in the main thread, the subsequent generated (second) thread works as expected! Is this spooky or expected behaviour?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20200416/a39afdfd/attachment.html>


More information about the openssl-users mailing list