crypto: setting --tls-max-v1.2 and --tls-cipher-list seems to ignore --tls-min-* setting

[AdamMajer]

Version

18.2.0, master

Platform

Linux localhost 5.17.7-1-default #1 SMP PREEMPT Thu May 12 12:38:04 UTC 2022 (c9a5fa1) x86_64 x86_64 x86_64 GNU/Linux

Subsystem

No response

What steps will reproduce the bug?

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

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

No response

What is the expected behavior?

TLSv1.2 connection or failure thereof

What do you see instead?

statusCode: 301 {
  name: 'AES256-SHA',
  standardName: 'TLS_RSA_WITH_AES_256_CBC_SHA',
  version: 'SSLv3'
}

Additional information

No response

[bnoordhuis]

TLS_RSA_WITH_AES_256_CBC_SHA is still around in TLSv1.2: https://ciphersuite.info/cs/TLS_RSA_WITH_AES_256_CBC_SHA/

Is your report about the version: 'SSLv3' line in the output? OpenSSL's SSL_CIPHER_get_version() reports the cipher's minimum SSL/TLS protocol version, not the protocol version of the current session.

[AdamMajer]

Yes, indeed, I was indeed confused about the SSLv3 in the getCiphers() line. I've found getProtocol() and life makes sense again. Thanks for the clarification.

[bnoordhuis]

If you're up for it, I think a documentation update to tlsSocket.getCipher() can help clarify the difference between the cipher and the session protocol version.

It is mentioned but the example uses a TLSv1.2-only cipher, making it an easy-to-miss nuance.