Debian:Unstable bin/openssl.Linux.x86_64 libssl_conf.so: cannot open shared object file

[shartge]

openssl-1.1.1-pre9 has reached Debian Unstable, bringing with it a new /etc/ssl/openssl.cnf.

When this new openssl.cnf file is present, openssl-1.0.2-chacha from testssl.sh no longer works and dies with:

user@host:~$ bin/openssl.Linux.x86_64 ciphers
Error configuring OpenSSL
37623872:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:187:filename(libssl_conf.so): libssl_conf.so: cannot open shared object file: No such file or directory
37623872:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:233:
37623872:error:0E07506E:configuration file routines:MODULE_LOAD_DSO:error loading dso:conf_mod.c:271:module=ssl_conf, path=ssl_conf
37623872:error:0E076071:configuration file routines:MODULE_RUN:unknown module name:conf_mod.c:212:module=ssl_conf

This is openssl/openssl#4788 "SSL conf module is added too late", fixed via openssl/openssl@0a90a68.

[drwetter]

Thx for the heads up.

See also #1098 . Looks to me in upstream this is fixed?

[shartge]

Yes, upstream fixed the libssl_conf.so loading order bug, the GOST engine bug from the first part of #1098 is something different though.

I don't know if the 3 line fix from openssl/openssl@0a90a68 can be applied to your special openssl fork.

[shartge]

Another idea: If the fix does not apply, maybe you need to provide your own openssl.cnf at a different path, so the supplied openssl binary does not get confused about the system one?

[shartge]

Scratch that, it is far simpler:

user@host:~/bin/etc$ export OPENSSL_CONF=~/bin/etc/openssl.cnf 
user@host:~/bin/etc$ cd ..
user@host:~/bin$ ./openssl.Linux.x86_64 ciphers
ECDHE-ECDSA-CHACHA20-POLY1305-OLD:ECDHE-RSA-CHACHA20-POLY1305-OLD:[...]

So testssl.sh just needs to set OPENSSL_CONF and, presto, problem solved.

[drwetter]

Thx!

We do set a OPENSSL_CONF, see initialize_engine().

[shartge]

Yes, but only to coax GOST support out of specially compiled openssl binaries, if I read the code correctly.

To be able to function properly when openssl-1.1.1+ is present, testssl.sh needs to provide an openssl.cnf in every case.

[drwetter]

Need to look closer into it. We are running aleady 1.1.1pre9 and previous versions too (see e.g. #1115 (comment)) and that didn't hiccup

[shartge]

The problem is not with using 1.1.1pre9 with testssl.sh but with using the supplied openssl-1.0.2 with the openssl.cnf from 1.1.1pre9.

1.0.2 gets confused with the new openssl.cnf and dies when testssl.sh tries to find out what ciphers are available, reporting "0 ciphers" and then obviously every test fails.

openssl-1.1.1pre9 is fine with its own openssl.cnf, of course.

[drwetter]

hmm,

works here

[shartge]

You shouldn't have CTRL+C'd the test, it breaks shortly after that:

 Testing vulnerabilities 

 Heartbleed (CVE-2014-0160)                not vulnerable (OK), no heartbeat extension
 CCS (CVE-2014-0224)                       not vulnerable (OK)
 Ticketbleed (CVE-2016-9244), experiment.  --   (applicable only for HTTPS)
 ROBOT                                     Local problem: Your /home/oweh/bin/openssl.Linux.x86_64 does not support the pkey utility.
 Secure Renegotiation (CVE-2009-3555)      
Fatal error: repeated openssl s_client connect problem, doesn't make sense to continue

[drwetter]

damned, I tossed the container this morning ;(

Yeah, can reproduce the odd behavior. It started soon after I pressed ^C

[drwetter]

Thx!