Repository navigation
crypto: setting --tls-max-v1.2 and --tls-cipher-list seems to ignore --tls-min-* setting #43406
Description
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
Activity
bnoordhuis commentedon Jun 14, 2022
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'sSSL_CIPHER_get_version()reports the cipher's minimum SSL/TLS protocol version, not the protocol version of the current session.AdamMajer commentedon Jun 14, 2022
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 commentedon Jun 14, 2022
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.
doc: clarify tls.tlsSocket.getCipher().version
doc: clarify tls.tlsSocket.getCipher().version
doc: clarify tls.tlsSocket.getCipher().version
doc: clarify tls.tlsSocket.getCipher().version
doc: clarify tls.tlsSocket.getCipher().version
doc: clarify tls.tlsSocket.getCipher().version