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

[Sean Mullan]

Hi Bernd,

On 8/19/21 6:43 AM, Bernd wrote:
> 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.

Actually, as of JDK 13, the server side suite order is preferred [1].
> 
> 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.

By default the CBC suites are already ordered lower in priority than 
other suites, so adding them to the legacy property probably would not 
have any benefit.

I don't think it is possible to order DHE such that it is lower in 
priority based on the key size. I will look into this more. However, by 
default ECDHE with GCM suites are preferred over DHE.

Also, see [1] for more information. These cipher suite reorderings were 
integrated into JDK 13, and have or are in the process of being 
backported to earlier JDK releases.

> 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). 

Suites that use DES are disabled by default, so I'm not sure I 
understand this concern.

> 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...

Well, that's a risk that one has to take into account before re-enabling 
these weaker suites.

> 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.

It's an interesting suggestion but we will need to look into it further 
to see if that type of configuration is possible.

--Sean

[1] https://bugs.openjdk.java.net/browse/JDK-8168261
[2] https://bugs.openjdk.java.net/browse/JDK-8163326