chrome/app/generated_resources.grd

Index: chrome/app/generated_resources.grd
diff --git a/chrome/app/generated_resources.grd b/chrome/app/generated_resources.grd
index b777e24da92bef4aa309ab5efd4bacaae1cde616..2f4c0f4044eb9823523bd45fe67e2891fe0fa171 100644
--- a/chrome/app/generated_resources.grd
+++ b/chrome/app/generated_resources.grd
@@ -9241,10 +9241,10 @@ I don't think this site should be blocked!
         This webpage is not available
       </message>
       <message name="IDS_ERRORPAGES_SUMMARY_SSL_VERSION_OR_CIPHER_MISMATCH" desc="Summary in the error page for SSL cipher and version errors.">
-        A secure connection cannot be established because this site uses an unsupported protocol.
+        A secure connection cannot be established because this site uses an unsupported protocol or cipher suite.
       </message>
       <message name="IDS_ERRORPAGES_DETAILS_SSL_VERSION_OR_CIPHER_MISMATCH" desc="The error message displayed for SSL cipher and version errors.">
-        The client and server don't support a common SSL protocol version or cipher suite. This is usually caused when the server needs SSLv3 support, which has been removed.
+        The client and server don't support a common SSL protocol version or cipher suite. This is usually caused when the server needs RC4 support, which has been removed.

[lgarron, 2015/10/27 21:53:14]

Given the trouble cause by ambiguous strings in the past (looking at you,
SHA-1), I think it would be much better if we could state unambiguously when RC4
caused the problem.
This would probably take a separate string and a way to test if the error was
RC4. Is that possible?

[davidben, 2015/10/27 22:30:22]

The server selects parameters, so it's not possible without complicating how
connections work. That said, we did do this for the SSL 3.0 fallback for a short
while until we raised the minimum completely. (And likewise with the rest of the
fallback legs, though we're not planning on raising the minimum anytime soon.)

Ryan, what do you think? If I had to give it a dedicated error code, I'd
probably do something like:

- In the deprecated cipher fallback, continue to advertise RC4 as before and not
just the AES-GCM IIS workaround.
- After the handshake, check the resulting cipher suite again and fail with a
dedicated error if rc4_enabled and the cipher is RC4.

In future, when the error code stops showing up much, remove that logic and roll
back to how we're doing now.

[lgarron, 2015/10/27 22:38:32]

Something like that would be great if we could do it for at least one or two
releases. :-D
(If it's a matter of taking time to code this, feel free to pull me in.)

       </message>
 
       <message name="IDS_ERRORPAGES_HEADING_PINNING_FAILURE" desc="Title of the error page for a certificate which doesn't match the built-in pins for that name">