Add CBC and DHE to legacy ciphers (avoid cipher order)?

[Bernd]

Hello,

while researching some TLS hardening (of JAva Implementations) I was
wondering the following:

- not requiring the preferred server cipher order has advantages, because
it is easier to configure, is the OpenJDK default, allows clients some
freedom to chose performance over strength and it also reduces the UI
needed for actual specifying the order.

Given the assumption that all enabled ciphers are security acceptable this
should also not be a big deal.

However for some compatibility reasons I have some installations where
AES_CBC and 1024Bit DHE is still used. I wonder if it would make sense to
add those two cipher families to the "legacyAlgorithms" security policy, so
that they are not touched, unless absolutely necesary to make the
connection.

Did somebody here considered that and has some experiences with it. Can I
add AES_CBC and DHE as partial matches?

One reason why I hesitate is this: if an medium-old client which only knows
CBC connects it would then require to negotiate a cipher from the legacy
block, which opens it up for the other entries in there as well (like DES).
Granted, the other legacy ciphers are all not enabled by default, but what
if somebody had to enable EDE and was relying on it beeing only negotiated
for even-older (with no AES) clients. In that situation a AES client
suddenly could propose EDE as well...

Also: would be nice if the legacycipher could include DHE1024 but not
DHE2048,. This way the line does not need to be changed if minsize 2048 is
set and/or if size agreement is in place.

Gruss
Bernd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210819/4cbb7e86/attachment.htm>