openssl provider hangs curl

[baentsch]

I built curl using a current openssl (3.x/master) and activated a (third-party) openssl provider by adding to openssl.cnf as follows:

oqsprovider = oqsprovider_sect

[oqsprovider_sect]
activate = 1

I expected simple commands like curl https://www.google.com to keep working.

What happened instead was a silent hang. Even adding -vvv didn't reveal anything.

When looking into the problem I admit to have not heeded the explicit warning in the openssl.cnf file:

# If no providers are activated explicitly, the default one is activated implicitly.
# See man 7 OSSL_PROVIDER-default for more details.
#
# If you add a section explicitly activating any other provider(s), you most
# probably need to explicitly activate the default provider, otherwise it
# becomes unavailable in openssl.  As a consequence applications depending on
# OpenSSL may not work correctly which could lead to significant system
# problems including inability to remotely access the system."

So, when activating the default provider via

[default_sect]
activate = 1

everything worked OK.

I consider this silent hang a bug -- but am unsure as to whether it is a curl or openssl bug. When testing the same config file using openssl s_client, though, a tell-tale error message was output and the command terminated:

> openssl s_client -connect www.google.com:443
C021F46C7F7F0000:error:0A0000A1:SSL routines:SSL_CTX_new_ex:library has no ciphers:ssl/ssl_lib.c:3251:

-> Thus the issue is created here: curl in my eyes should issue a similar error message and not hang.

I did this on master:

curl 7.80.0-DEV (x86_64-pc-linux-gnu) libcurl/7.80.0-DEV OpenSSL/3.1.0 zlib/1.2.11
Release-Date: [unreleased]
Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS HSTS HTTPS-proxy IPv6 Largefile libz NTLM NTLM_WB SSL TLS-SRP UnixSockets

on
Linux T430s 5.4.0-87-generic #98~18.04.1-Ubuntu SMP Wed Sep 22 10:45:04 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

[bagder]

If it can be detected that easily, then it seems like something OpenSSL should do by itself rather than to force every openssl-application out there to implement the same check. OpenSSL allows openssl-users to shoot themselves in the foot. Is that our job to warn said users maybe shooting feet is bad?

[baentsch]

Good point. Will try to reproduce the problem surfacing independently of curl and then open an issue in OpenSSL.

[baentsch]

@bagder After failing to reproduce in OpenSSL alone the issue, I built a debug-curl and found the problem to be this: curl hangs in ossl_seed after a call to OpenSSL's RAND_status returned 0. The latter is permissible and happens in OpenSSL3 if no default provider (also delivering randomness) is present. I'd thus think this is something that curl needs to address. One idea would be to issue a warning that randomness cannot be obtained: That message alone would alert users of a missing (randomness) provider. A silent hang is misleading, I'd argue. Accordingly, reopening the issue. I'd be glad to create a PR adding such warning if you'd agree with this assessment.

[bagder]

curl hangs in ossl_seed after a call to OpenSSL's RAND_status returned 0

Why does it hang because of that?

[baentsch]

curl hangs in ossl_seed after a call to OpenSSL's RAND_status returned 0

Why does it hang because of that?

Because this is an endless loop in that case:

curl/lib/vtls/openssl.c

Line 508 in d36fded

} while(!rand_enough());

[bagder]

#7856 should avoid the hang and return an error for this case. Can you verify?

[baentsch]

#7856 should avoid the hang and return an error for this case. Can you verify?

It does. Thanks!