On Tue, 22 Mar 2022 19:34:17 GMT, Xue-Lei Andrew Fan <xue...@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
