Groups configuration is silently ignored for TLS versions prior to 1.3

[fwh-dc]

Describe the bug An s_server ignores the -groups option when configured with -no_tls1_3

To Reproduce

LD_LIBRARY_PATH=.local/lib64 .local/bin/openssl s_server -cert rsa_srv.crt -key rsa_srv.key -www -no_tls1_3 -groups kyber768 -provider-path oqs-provider/_build/lib  -provider default -provider oqsprovider

Expected behavior I would expect a no_tls1_3 s_server to fail or give a warning if it is configured with one of the groups in this repository.

Environment (please complete the following information): OpenSSL 3.1.1 30 May 2023 (Library: OpenSSL 3.1.1 30 May 2023) MacOS Ventura

Additional context Similarly I am able to successfully connect a client to the server using:

LD_LIBRARY_PATH=.local/lib64 .local/bin/openssl s_client -curves frodo640shake -provider-path oqs-provider/_build/lib  -provider default -provider oqsprovider -CAfile rsa_CA.crt -no_tls1_3

It might be related to https://github.com/openssl/openssl/issues/21081

[baentsch]

An s_server ignores the -groups option when configured with -no_tls1_3

No oqsprovider code at all should be executed if openssl is configured with -no_tls1_3 (see https://github.com/open-quantum-safe/oqs-provider#status). This very clearly is an openssl issue.

Similarly I am able to successfully connect a client to the server using: LD_LIBRARY_PATH=.local/lib64 .local/bin/openssl s_client -curves frodo640shake -provider-path oqs-provider/_build/lib -provider default -provider oqsprovider -CAfile rsa_CA.crt -no_tls1_3

This command is incomplete (what are you connecting to?). When I test this with the interop server, it fails as expected:

./.local/bin/openssl s_client --connect test.openquantumsafe.org:6006 -groups frodo640aes -provider-path=_build/lib -provider oqsprovider -provider default -no_tls1_3
Connecting to 158.177.128.14
CONNECTED(00000003)
C041D8905B7F0000:error:0A00042E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:ssl/record/rec_layer_s3.c:855:SSL alert number 70

and passes when leaving away -no_tls1_3.

[fwh-dc]

No oqsprovider code at all should be executed if openssl is configured with -no_tls1_3 (see https://github.com/open-quantum-safe/oqs-provider#status). This very clearly is an openssl issue.

Ok then I'll raise that issue with openssl. We agree that the relevant implementation in this context is the implementation in oqsprov_capabilities.c? Namely the use of OSSL_CAPABILITY_TLS_GROUP_MIN_TLS?

This command is incomplete (what are you connecting to?).

The client was meant to connect to the s_server instance posted at the top. What I wanted to highlight was that they are able to communicate even though the -groups config should be unsupported + that their groups do not match.

#Server:
LD_LIBRARY_PATH=.local/lib64 .local/bin/openssl s_server -cert rsa_srv.crt -key rsa_srv.key -www -no_tls1_3 -groups kyber768 -provider-path oqs-provider/_build/lib  -provider default -provider oqsprovider
#Client:
LD_LIBRARY_PATH=.local/lib64 .local/bin/openssl s_client -curves frodo640shake -provider-path oqs-provider/_build/lib -provider default -provider oqsprovider -CAfile rsa_CA.crt -no_tls1_3

When I test this with the interop server, it fails as expected:

Looks like it fails on the protocol version negotiation, which should be expected even without the oqs-provider?

Thanks for the swift replies. It is really helpful!

[baentsch]

which should be expected even without the oqs-provider

Exactly. Hence my statement that this has nothing to do with oqsprovider.

Now, reading your initial statement again

An s_server ignores the -groups option

I wonder what you expect a server to do with this client side option?

[baentsch]

I wonder what you expect a server to do with this client side option?

(Apologies for having to answer myself): Looks like I only had 1.1.1 semantics in the back of my mind when writing this. Since 3.0, indeed this should set groups server-side, too.

But then again, the problem you describe is very similar (arguably identical when looking at the command lines there) to https://github.com/openssl/openssl/issues/21081 so I really suggest to close the issue here.

[fwh-dc]

Ahh okay so what you are saying is that previously it only configured the client side? That might explain the following question I raised with openssl: https://github.com/openssl/openssl/issues/21256

I'll close this issue then and await more info from openssl.

[baentsch]

is that previously it only configured the client side?

That is what I recall (and what https://www.openssl.org/docs/man1.0.2/man1/openssl-s_server.html (doesn't) document(s)). But then again, when 1.0.2 was "current", it was all still "curves" and TLS1.3 didn't exist. So let's wait and see what the response is to https://github.com/openssl/openssl/issues/21256.