oqs-provider: Too many advertised sig algs cause TLS server hang-up
Describe the bug
Provider built from the main branch pulled after Fri Apr 12, 2024, somehow causes OpenSSL to hang and then time-out on requests over corporate firewall (to https://index.crates.io, in case it matters).
When I comment out oqs provider in openssl.cnf the problem disappears.
I must add that before Apr 12th everything worked just fine. So, it’s OpenSSL, or liboqs, or oqs-provider.
@levitte could you please take a look as well? I don’t know whether it’s the provider’s fault, or that of the OpenSSL itself.
To Reproduce A little complicated, but here’s what I have.
Steps to reproduce the behavior:
- Install Rust toolchain.
- Install
cargo-updateviacargo install cargo-update - Have OpenSSL-3.2.1 installed.
- Install current master of
liboqs. - Clone and install
oqs-provider(mainbranch). - Edit
openssl.cnfto addoqsprovider (some add it asoqsprovider, for me naming itoqssuffices). - Try
cargo install-update -l - See error
Expected behavior
Something like
$ cargo install-update -l
Polling registry 'https://index.crates.io/'.......................................
Package Installed Latest Needs update
asn1rs v0.3.1 v0.3.1 No
b3sum v1.5.1 v1.5.1 No
. . .
Actual behavior
$ cargo install-update -l
Polling registry 'https://index.crates.io/'
Failed to update index repository crates-io: package asn1rs: [35] SSL connect error (OpenSSL SSL_connect: SSL_ERROR_ZERO_RETURN in connection to index.crates.io:443 ).
$
$ OQSPROV=1 cargo install-update -l
OQS PROV: successfully registered dilithium2 with NID 1320
OQS PROV: successfully registered p256_dilithium2 with NID 1321
OQS PROV: successfully registered rsa3072_dilithium2 with NID 1322
OQS PROV: successfully registered dilithium3 with NID 1323
OQS PROV: successfully registered p384_dilithium3 with NID 1324
OQS PROV: successfully registered dilithium5 with NID 1325
OQS PROV: successfully registered p521_dilithium5 with NID 1326
OQS PROV: successfully registered mldsa44 with NID 1327
OQS PROV: successfully registered p256_mldsa44 with NID 1328
OQS PROV: successfully registered rsa3072_mldsa44 with NID 1329
OQS PROV: successfully registered mldsa44_pss2048 with NID 1330
OQS PROV: successfully registered mldsa44_rsa2048 with NID 1331
OQS PROV: successfully registered mldsa44_ed25519 with NID 1332
OQS PROV: successfully registered mldsa44_p256 with NID 1333
OQS PROV: successfully registered mldsa44_bp256 with NID 1334
OQS PROV: successfully registered mldsa65 with NID 1335
OQS PROV: successfully registered p384_mldsa65 with NID 1336
OQS PROV: successfully registered mldsa65_pss3072 with NID 1337
OQS PROV: successfully registered mldsa65_rsa3072 with NID 1338
OQS PROV: successfully registered mldsa65_p256 with NID 1339
OQS PROV: successfully registered mldsa65_bp256 with NID 1340
OQS PROV: successfully registered mldsa65_ed25519 with NID 1341
OQS PROV: successfully registered mldsa87 with NID 1342
OQS PROV: successfully registered p521_mldsa87 with NID 1343
OQS PROV: successfully registered mldsa87_p384 with NID 1344
OQS PROV: successfully registered mldsa87_bp384 with NID 1345
OQS PROV: successfully registered mldsa87_ed448 with NID 1346
OQS PROV: successfully registered falcon512 with NID 1347
OQS PROV: successfully registered p256_falcon512 with NID 1348
OQS PROV: successfully registered rsa3072_falcon512 with NID 1349
OQS PROV: successfully registered falconpadded512 with NID 1350
OQS PROV: successfully registered p256_falconpadded512 with NID 1351
OQS PROV: successfully registered rsa3072_falconpadded512 with NID 1352
OQS PROV: successfully registered falcon1024 with NID 1353
OQS PROV: successfully registered p521_falcon1024 with NID 1354
OQS PROV: successfully registered falconpadded1024 with NID 1355
OQS PROV: successfully registered p521_falconpadded1024 with NID 1356
OQS PROV: successfully registered sphincssha2128fsimple with NID 1357
OQS PROV: successfully registered p256_sphincssha2128fsimple with NID 1358
OQS PROV: successfully registered rsa3072_sphincssha2128fsimple with NID 1359
OQS PROV: successfully registered sphincssha2128ssimple with NID 1360
OQS PROV: successfully registered p256_sphincssha2128ssimple with NID 1361
OQS PROV: successfully registered rsa3072_sphincssha2128ssimple with NID 1362
OQS PROV: successfully registered sphincssha2192fsimple with NID 1363
OQS PROV: successfully registered p384_sphincssha2192fsimple with NID 1364
OQS PROV: successfully registered sphincsshake128fsimple with NID 1365
OQS PROV: successfully registered p256_sphincsshake128fsimple with NID 1366
OQS PROV: successfully registered rsa3072_sphincsshake128fsimple with NID 1367
OQS PROV: Default or FIPS provider available.
Polling registry 'https://index.crates.io/'Unknown operation 5 requested from OQS provider
Unknown operation 5 requested from OQS provider
Unknown operation 2 requested from OQS provider
Unknown operation 2 requested from OQS provider
Unknown operation 2 requested from OQS provider
Unknown operation 2 requested from OQS provider
Unknown operation 2 requested from OQS provider
Unknown operation 2 requested from OQS provider
Unknown operation 2 requested from OQS provider
Unknown operation 2 requested from OQS provider
Unknown operation 2 requested from OQS provider
Unknown operation 2 requested from OQS provider
Unknown operation 2 requested from OQS provider
Unknown operation 2 requested from OQS provider
Unknown operation 2 requested from OQS provider
Unknown operation 2 requested from OQS provider
Unknown operation 2 requested from OQS provider
Unknown operation 2 requested from OQS provider
Unknown operation 2 requested from OQS provider
Unknown operation 2 requested from OQS provider
Unknown operation 2 requested from OQS provider
Unknown operation 1 requested from OQS provider
Unknown operation 1 requested from OQS provider
Unknown operation 1 requested from OQS provider
Unknown operation 1 requested from OQS provider
Unknown operation 1 requested from OQS provider
Unknown operation 1 requested from OQS provider
Unknown operation 1 requested from OQS provider
Unknown operation 11 requested from OQS provider
Unknown operation 11 requested from OQS provider
Failed to update index repository crates-io: package asn1rs: [35] SSL connect error (OpenSSL SSL_connect: SSL_ERROR_ZERO_RETURN in connection to index.crates.io:443 ).
$
Environment (please complete the following information):
- OS: MacOS Sonoma 14.4.1
- OpenSSL version 3.2.1 (Macports-installed)
- oqsprovider version 0.6.0 (or whatever the current
mainis) - liboqs current master
Please run the following commands to obtain the version information:
- For OpenSSL:
openssl version - For oqsprovider:
openssl list -providers
$ openssl version
OpenSSL 3.2.1 30 Jan 2024 (Library: OpenSSL 3.2.1 30 Jan 2024)
$ openssl list -providers
Providers:
base
name: OpenSSL Base Provider
version: 3.2.1
status: active
default
name: OpenSSL Default Provider
version: 3.2.1
status: active
legacy
name: OpenSSL Legacy Provider
version: 3.2.1
status: active
oqs
name: OpenSSL OQS Provider
version: 0.6.0
status: active
pkcs11
name: PKCS#11 Provider
version: 3.2.1
status: active
$
About this issue
- Original URL
- State: open
- Created 2 months ago
- Comments: 78 (75 by maintainers)
Commits related to this issue
- Disable Dilithium and SPHINCS+ sig algs by default This fixes open-quantum-safe/oqs-provider#399 With the current default enabled sig algs, some servers may fail to complete the TLS handshake. This ... — committed to iyanmv/oqs-provider by iyanmv 2 months ago
- Disable Dilithium and SPHINCS+ sig algs by default This fixes open-quantum-safe/oqs-provider#399 With the current default enabled sig algs, some servers may fail to complete the TLS handshake. This ... — committed to iyanmv/oqs-provider by iyanmv 2 months ago
- upgpkg: oqsprovider 0.6.0-2 Enable less sig algs. See open-quantum-safe/oqs-provider#399 — committed to iyanmv/PKGBUILDs by iyanmv 2 months ago
- upgpkg: oqsprovider 0.6.0-2 Enable less sig algs. See open-quantum-safe/oqs-provider#399 — committed to archlinux/aur by iyanmv 2 months ago
Thanks for this confirmation: In this case, on OpenSSL fix (if necessary at all) would not buy us anything. Tagging @brian-jarvis-aws FYI (in case you have s2n contacts to chime in here).
I mean smth like
Thanks, Brian brought this to s2n-tls’s attention and we’re currently working on a fix. It looks like we have a hard-coded limit of 64 signature schemes. There are <40 standardized signature schemes with assigned IANA values as of today, so having a max of 64 probably seemed like a safe assumption at the time. We are working to increase the limit as a quick short term fix, and longer term we plan to remove the limit completely.
sedworked fine, but some other things did not. 😦After straightening out all of those, I’m getting successful TLS connections.
Note: I’m only enabling ML-DSA and Dilithium5 signatures. No others.
@baentsch I strongly suggest changing the defaults (at least for now) in
oqs-templates/generate.yml, and disabling all the signature algorithms except for ML-DSA.and
Also, not sure if it’s related - but with OpenSSL-3.4.0-dev master the tests report
Observe test #4: while normally all the tests take up to a few seconds each - this one is more than 3.5 minutes.
For comparison, with OpenSSL-3.2.1:
FWIW, I do: (PQ-)cert mgmt, CMS, etc all worked well before PQ-TLS-sig support. It’d be a pity to disable this by default just because of some weirdly behaving TLS servers.
Is this so? Do you know for fact that the servers rejecting these “high-count sigalg code point” handshakes are running OpenSSL?
That’d be a possible compromise indeed, but if memory serves,
opensslnow simply advertises all sig algs it finds providers to, well, provide. Admittedly, it was me adding this logic toopenssl, so I feel at liberty to also change it again 😃 @levitte: What’d be your take/recommendation in this regard? We could add a property “OSSL_CAPABILITY_TLS_SIGALG_ADVERTISE” or so to facilitate this.Alright, then maybe you can try to disable some of the enabled sig algs and see if it works again for you? By default 48 sig algs are enabled in the current
generate.yml, which triggers this issue in some servers (at least on my side with the experiments I did). For, example, you can do the following to modify the file:Then re-run the python script and compile oqsprovider. If it works for you as well, then I think a possible solution (even though the problem is not from openssl or oqsprovider) as suggested by @baentsch would be to reduce the list of default enabled sig algs.
Interesting. It worked for me both for the system
openssl(3.0.2) and the latest “master” build:–> What’s your
opensslversion?It isn’t clear to me if the servers that were tested against are using the oqsprovider or not. What I get out of that the outputs shown here is it may as well be that they respond in different (possibly faulty) ways when faced with cipher suites they do not know… but, TLS isn’t my area of expertise, so I can’t do much more than relay my impression
You could run s_client to connect to your server with a limited list of cipher suites, groups and sig algs? ./openssl s_client -connect <server_ip>:<port> -tls1_3 -groups kyber512 -provider oqsprovider
I was writing this for something else, but I leave it here in case it’s useful for anyone to reproduce the issue with my exact setup:
But I was able to reproduce using the
fullbuild.shscript, so I don’t think it’s an issue of how I’m buildingliboqsoroqs-provider.Since this only happens with certain servers, can it also be a “misconfiguration” on the server side? If the client offers PQC KEM, perhaps that triggers something on the server side that causes the handshake to fail.