RFR: 8163327: Remove 3DES from the default enabled cipher suites list [v2]

[Sean Mullan]

On Tue, 22 Mar 2022 19:34:17 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> I see. That makes sense. However, I will note that the current order does not reflect the preference rules defined in lines 336-348 (copied below):
>> 
>> 
>>     // Definition of the CipherSuites that are supported but not enabled
>>     // by default.
>>     // They are listed in preference order, preferred first, using the
>>     // following criteria:
>>     // 1. If a cipher suite has been obsoleted, we put it at the end of
>>     //    the list.
>>     // 2. Prefer the stronger bulk cipher, in the order of AES_256,
>>     //    AES_128, 3DES-EDE, RC-4, DES, DES40, RC4_40, NULL.
>>     // 3. Prefer the stronger MAC algorithm, in the order of SHA384,
>>     //    SHA256, SHA, MD5.
>>     // 4. Prefer the better performance of key exchange and digital
>>     //    signature algorithm, in the order of ECDHE-ECDSA, ECDHE-RSA,
>>     //    RSA, ECDH-ECDSA, ECDH-RSA, DHE-RSA, DHE-DSS, anonymous.
>> 
>> In particular, some of the RC4 suites support forward secrecy but are ordered after the anon suites. The rules above say nothing about anon suites. They seem to be ordered as higher priority than others mainly because they use stronger ciphers. But 3DES and RC4 are obsolete suites, so maybe it is correct that they should be where they are.
>> 
>> Thus, it isn't clear to me if the current order does or does not accurately reflect these rules. I put the 3DES suites where they were because to me they are probably/maybe stronger than the RC4 suites, but do not use strong ciphers that the anon suites do, and are obsolete. So we either need to clarify the rules and put anon suites lower, and change the obsolete rule. Otherwise, I'm reluctant to make a change that seems inconsistent with the rules.
>> 
>> Having said all that, I also don't want to over-rotate on this and try to decide what suite is more weaker than others, since you really shouldn't be using any of them.
>
>> So we either need to clarify the rules and put anon suites lower, and change the obsolete rule.
> 
> It makes sense to me.  It might be better to update the rules firstly (or just leave it alone as the priority is pretty low), but which is out of the scope of this update.  I will approve this update.

Ok, let me think about whether this is worth improving as a separate issue. I did make one change to the order however, and that is to move the TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA and SSL_DH_anon_WITH_3DES_EDE_CBC_SHA suites lower in priority after other 3DES suites as these clearly should be lower in priority because they are using 3DES and anonymous authn.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7894