search

open-quantum-safe / oqs-provider

OpenSSL 3 provider containing post-quantum algorithms
https://openquantumsafe.org
MIT License
207 stars 87 forks source link

Usage of oqsprovider with OpenSSL 3.0.2 and nginx 1.18.0 on Ubuntu 22.04 #247

Closed Avamander closed 1 year ago

Avamander commented 1 year ago

Describe the bug I've successfully built oqsprovider (https://github.com/open-quantum-safe/oqs-provider/commit/cc3895f208730abfe1efc15f7c3ff4358ac6e4c0) from source, it seems to work properly when used with openssl (s_client).

To Reproduce Steps to reproduce the behavior:

  1. Install oqsprovider on stock Ubuntu 22.04
  2. Add ssl_ecdh_curve x25519_kyber768:p384_kyber768; to nginx's config.
  3. Run openssl s_client -tls1_3 -groups x25519_kyber768:p384_kyber768 example.com:443
  4. No errors, successful connection 4.5. If ssl_ecdh_curve does not contain x25519_kyber768 and p384_kyber768 neither, then s_client errors out.
  5. Try the same with a browser (Edge with p384_kyber768 enabled or Chrome with x25519_kyber768 enabled). X25519 is used instead. (https://pq.cloudflareresearch.com/ shows working support for Chrome)

This would indicate that the provider works when requested but Chrome/Edge just don't?

Maybe this is a trivial caveat I've missed reading through other issues, if so please do let me know.

Expected behavior Completing oqsprovider installation and allowing the KeXs will make it possible for latest Edge and Chrome to utilize those KeXs.

Environment (please complete the following information):

baentsch commented 1 year ago

Chrome & Edge do not use OpenSSL for their crypto, hence (their) failure to utilize oqsprovider is to be expected.

Avamander commented 1 year ago

@baentsch There's a miscommunication, they're just two pieces of test software that connect to the nginx server described (they ship their own implementations of those algorithms). But for some reason nginx with the provider doesn't seem compatible with the two.

baentsch commented 1 year ago

@baentsch There's a miscommunication, they're just two pieces of test software that connect to the nginx server described (they ship their own implementations of those algorithms). But for some reason nginx with the provider doesn't seem compatible with the two.

Ah, apologies, I didn't see that you are using PQ-enabled browsers -- and I didn't know that Edge has that support already.

To be sure nothing silly has happened during the build of the software stack, can you please confirm that Chrome can successfully display this when connecting to https://test.openquantumsafe.org:6041: image

This site is running the exact same software (nginx+oqsprovider+liboqs) -- so if you can connect there you should be able to connect to your own build.

Avamander commented 1 year ago

can you please confirm that Chrome can successfully display this when connecting to https://test.openquantumsafe.org:6041/

Yes. Visiting that page with Chrome I get "Client-side KEM algorithm(s) indicated: 0xbaba:x25519_kyber768:x25519:secp256r1:secp384r1". Developer Tools -> Security tab also confirms that x25519kyber768draft00 is used.

To be sure nothing silly has happened during the build of the software stack

This is also my suspicion. But it's weird that OpenSSL s_client connection works if x25519_kyber768 is enabled and does not work if x25519_kyber768 is disabled.

This site is running the exact same software (nginx+oqsprovider+liboqs)

The same versions? If there's a know working set of versions I can switch to those and see if that changes anything.

baentsch commented 1 year ago

But it's weird that OpenSSL s_client connection works if x25519_kyber768 is enabled and does not work if x25519_kyber768 is disabled.

Indeed. How does your build behave when connecting to the test server?

The same versions? If there's a know working set of versions I can switch to those and see if that changes anything.

The server states

This corresponds to the OQS release version 0.8.0 and oqs-provider version 0.5.1.

Avamander commented 1 year ago

Indeed. How does your build behave when connecting to the test server?

Also successful.

<!DOCTYPE html>
<html>
<head>
<title>Open Quantum Safe interop test server for quantum-safe cryptography</title>
</head>
<body>
<h1 align=center>
Successfully connected using
ecdsap256-x25519_kyber768!
</h1>

Client-side KEM algorithm(s) indicated:
x25519_kyber768:p384_kyber768
</body>
</html>
Avamander commented 1 year ago

I can see from a Wireshark dump that Chrome is nicely sending ClientHello with group 25497 (I assume this is x25519_kyber768) and 29 (x25519). The server responds with Key Share Extension -> Key Share Entry -> Group: x25519. Resulting connection uses x25519.

Making a connection using OpenSSL (with the provider), it's sending ClientHello with group 25497. The server responds with Key Share Extension -> Key Share Entry -> Group: 0x6399 (25497). Resulting connection uses x25519_kyber768.

My nginx configuration contains ssl_ecdh_curve x25519_kyber768:x448_kyber768:p256_kyber768:x25519:secp256r1:x448:secp384r1:secp521r1; There's some kind of server-preferred KeX thing going on that ssl_ecdh_curve doesn't override?

baentsch commented 1 year ago

There's some kind of server-preferred KeX thing going on that ssl_ecdh_curve doesn't override?

That could well be: OpenSSL has the final word. Do you have some system-wide "Group" configured in "openssl.cnf"?

Avamander commented 1 year ago

Hah! Figured it out. Thank you for your patience!

If there are two server blocks that bind to the same IP and if one of those is default_server then its ssl_ecdh_curve overrides the ssl_ecdh_curve set by correct SNI server block.

OpenSSL worked great because it went over IPv6 that didn't have a default_server on the same IP, but my browsers hit the regular ssl_ecdh_curve default_server. Annoyingly both saw the same content, certificate, use the same ciphers, but only the available KeX-s differ in the end.

It is weird that nginx lets one define ssl_ecdh_curve when it has 0 effect in some scenarios. I should probably open a ticket about this (paper)cut.

Avamander commented 1 year ago

I can also confirm that both browsers now work as expected, Chrome uses x25519_kyber768 and Edge p384_kyber768. :+1:

baentsch commented 1 year ago

I can also confirm that both browsers now work as expected, Chrome uses x25519_kyber768 and Edge p384_kyber768. 👍

Very cool. Thanks for checking this out! For my personal curiosity: Do you have a link announcing this feature for Edge?

Avamander commented 1 year ago

Do you have a link announcing this feature for Edge?

I haven't seen it publicly announced, but it is available under edge://flags#edge-post-quantum-kyber on current stable Edge.

baentsch commented 1 year ago

@christianpaquin Do you have background on this?