AnsweredAssumed Answered

[Suggestion] Penalize more for servers that support RC4 cipher suites

Question asked by hellotls on Oct 4, 2014
Latest reply on Oct 6, 2014 by hellotls

Today I found that draft-ietf-tls-prohibiting-rc4 had been submitted to IESG for publication.[1] The basic idea of the document is that 1) clients must not offer RC4 cipher suites, and 2) if clients do offer RC4 cipher suites, servers must not select RC4. So far the consensus of the TLS Working Group is "to keep the document as is with respect to prohibiting the negotiation of RC4".[2]

 

Given that, I have some suggestions for SSL Labs:
1. If a server supports RC4, and RC4 is not used with any browsers, set the grade to A-.
2. If a server supports RC4, and uses it with some browsers, set the grade to B. (example)
3. If a server only supports RC4, set the grade to F. (example 1, example 2)
4. In the "Cipher Suites" list, mark RC4 ciphers as WEAK.

 

The third suggestion is what I really want. If browsers decide to disable RC4 totally (without fallback), these RC4 only websites would be inaccessible for users with modern browsers. But if browsers keep supporting RC4, there are more than 20% of servers prefer to use RC4, but also offer non-RC4 ciphers, but browsers cannot take the advantage of that. Therefore, it is very important that there should be no RC4-only servers.

 

The rationale for abandoning RC4 is that BEAST has been mitigated on most clients by using 1/n-1 for years, and even Apple enabled 1/n-1 one year ago. So there is no longer any need for servers to mitigate BEAST. Also, even IE6 on XP supports 3DES, so there is also no need to support RC4 for compatibility reason.

 

[1] https://tools.ietf.org/html/draft-ietf-tls-prohibiting-rc4-01
[2] https://www.ietf.org/mail-archive/web/tls/current/msg13692.html

Outcomes