James,
On 12/27/24 11:35 AM, James H. H. Lampert wrote:
On 12/27/24 8:14 AM, Christopher Schultz wrote:
When you got Chrome working again, which cipher suite did it
successfully negotiate? If you try in this configuration with Firefox,
which cipher suite is successfully negotiated?
Dear Christopher:
At this time, switching them back to the "no keyAlias clause"
configuration is a non-starter (maybe sometime Sunday).
Understood. Maybe in a private testing environment? You don't even need
an application deployed; just use default ROOT or even nothing. All you
care about are TLS handshakes.
But with the working configuration, Firefox reports
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 128 bit keys, TLS 1.2" and
Chrome reports "TLS 1.2, ECDHE_RSA with P-256 and AES_128_GCM." (which
*sounds* like a dumbed-down restatement of the same thing).
When in doubt, look up the cipher suite to get the details:
https://ciphersuite.info/cs/TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256/
(for sure, from the cipher suite's name above)
vs
https://ciphersuite.info/cs/TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256/
(a guess, given that the P-256 is thrown in there).
The difference is that one of them uses RSA for authentication
(certificate signature) while the other one uses an Elliptic Curve
(curve P-256, the so-called 256-bit "NIST curve" that basically
everybody uses).
The other elements of the two cipher suites are indeed the same (ECDHE
for key exchange, 128-bit AES in GCM mode for bulk encryption, SHA-256
for message signatures).
Hmm. "ECDHE_RSA with P-256" is a little confusing to me. Google (search)
says that it means P-256 is being used for the ECDHE key exchange before
authentication. So P-256 was a red herring as far as I'm concerned
because typically you are more interested in how the authentication is
being done (RSA vs EC).
Again, with the working configuration, SSLLabs reports:
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 2048 bits FS WEAK 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp521r1 (eq.
15360 bits RSA) FS WEAK 128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67) DH 2048 bits FS
WEAK 128
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 2048 bits FS 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp521r1 (eq.
15360 bits RSA) FS WEAK 128
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH secp521r1 (eq.
15360 bits RSA) FS 128
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 2048 bits FS WEAK 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp521r1 (eq.
15360 bits RSA) FS WEAK 256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) DH 2048 bits FS
WEAK 256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 2048 bits FS 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp521r1 (eq.
15360 bits RSA) FS WEAK 256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp521r1 (eq.
15360 bits RSA) FS 256
That all looks pretty standard, though I see secp521r1 in there which is
NIST P-521 and not NIST P-256.
If you are curious about why some of those are listed as "weak", it's
because AES in CBC mode is vulnerable to certain types of attacks, so
every suite containing "CBC" will be marked as "weak" by Qualys. You can
read more about it here [1].
In spite of that warning, I would say that leaving the CBC-based cipher
suites enabled in your server is reasonable for a "standard paranoia
level" web site/service. If you are absolutely sure that all of your
clients are using modern software to access your site, you can dump the
CBC cipher suites entirely.
I've saved a PDF of the relevant part of the SSLLabs report, so that I
can compare it if I'm able to try the other configuration on Sunday.
Sounds good to me.
I'm assuming in both cases, you are using an RSA key with the same bit-count
-chris
[1]
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher_block_chaining_(CBC)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
