Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

openssl provider hangs curl #7840

Closed
baentsch opened this issue Oct 11, 2021 · 7 comments
Closed

openssl provider hangs curl #7840

baentsch opened this issue Oct 11, 2021 · 7 comments

Comments

@baentsch
Copy link
Contributor

@baentsch baentsch commented Oct 11, 2021

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
Copy link
Member

@bagder bagder commented Oct 12, 2021

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?

Loading

@baentsch
Copy link
Contributor Author

@baentsch baentsch commented Oct 12, 2021

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

Loading

@baentsch
Copy link
Contributor Author

@baentsch baentsch commented Oct 14, 2021

@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.

Loading

@baentsch baentsch reopened this Oct 14, 2021
@bagder
Copy link
Member

@bagder bagder commented Oct 14, 2021

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

Why does it hang because of that?

Loading

@baentsch
Copy link
Contributor Author

@baentsch baentsch commented Oct 14, 2021

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:

} while(!rand_enough());

Loading

bagder added a commit that referenced this issue Oct 14, 2021
One reason we know it can fail is if a provider is used that doesn't do
a proper job.

Reported-by: Michael Baentsch
Fixes #7840
@bagder
Copy link
Member

@bagder bagder commented Oct 14, 2021

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

Loading

@baentsch
Copy link
Contributor Author

@baentsch baentsch commented Oct 14, 2021

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

It does. Thanks!

Loading

@bagder bagder closed this in f3c215e Oct 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

2 participants