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
