<div dir="ltr"><div dir="ltr">Hello,<div><br></div><div>while researching some TLS hardening (of JAva Implementations) I was wondering the following:</div><div><br></div><div>- 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.</div><div><br></div><div>Given the assumption that all enabled ciphers are security acceptable this should also not be a big deal.</div><div><br></div><div>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 "<span style="color:rgb(26,24,22);font-family:"Courier New",Courier,monospace;font-size:14px">legacyAlgorithms</span>" security policy, so that they are not touched, unless absolutely necesary to make the connection.</div><div><br></div><div>Did somebody here considered that and has some experiences with it. Can I add AES_CBC and DHE as partial matches?</div><div><br></div><div>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...</div><div><br></div><div>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.</div><div><br></div><div>Gruss</div><div>Bernd</div></div></div>