--tls-cipher-list=DEFAULT@SECLEVEL=0 doesn't compatible with tls1.3

[benzhuo]

Version

v18.2.0

Platform

Microsoft Windows NT 10.0.19042.0 x64

Subsystem

No response

What steps will reproduce the bug?

I try to set --tls-cipher-list=DEFAULT@SECLEVEL=0, which can connect with tls1.0 , but can not connect with tls1.3.
but, if I use the openssl3.0, and set the SECLEVEL=0, it works well both connect 1.0 and 1.3.

How often does it reproduce? Is there a required condition?

No response

What is the expected behavior?

how to set the option that make it can work same as openssl, that can connect both 1.0 and 1.3. I knows 1.0 and 1.1 has been deprecated.

openssl 3.0.3 connect snip
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_128_GCM_SHA256
Session-ID: 539B67CDF41CD89F10161EA93683556D9D300B46280FAB64A8EC819467EC914F
Session-ID-ctx:
Resumption PSK: 603B795602CA3D5EAD2882C86BAE29663B3955FD667D6EA1F83CD6DE3C704EAE

What do you see instead?

error:0A0000B5:SSL routines:ssl_cipher_list_to_bytes:no ciphers available:c:\ws\deps\openssl\openssl\ssl\statem\statem_clnt.c:3749:No ciphers enabled for max supported SSL/TLS version

Additional information

No response

[AdamMajer]

Another test case is using crypto-policies ciphers,

node --tls-min-v1.3 --tls-cipher-list='PROFILE=SYSTEM' -e "https.get('https://google.com/', (res) => {console.log('statusCode:', res.statusCode, res.client.getCipher()); }).on('error', (e) => console.error(e));"

The root cause is we seem to assume that there are no default cipher suites

[benzhuo]

@AdamMajer Thanks very much. when the fix will be released ?
Now, I am using a workaround that set --openssl-config=openssl.cnf

[AdamMajer]

This will have to be merged first and then released in 18.x. It will appear in the changes and also in the pull request when it gets merged for next 18.x release or possibly backported to older versions. I guess a week or two at least before 18.x