When a RC4 server page is broken we use the default net:error message. We should provide messaging and actions specific to this use case. It seems like ideally, our behavior here would have the following properties: 0. Have a special warning specifically for RC4 1. "This server requires the use of a bad encryption technology (RC4)" 2. "... If you go here, your information is at risk" 3. "... If you really want to go here, security.tls.unrestricted_rc4_fallback"
We need to implement a scanner to detect RC4-only server specifically. See bug 1145261 for details. We will have to add a way to make a secure connection with RC4 enabled regardless of pref values to implement the scanner.
(In reply to agrigas from comment #0) > 3. "... If you really want to go here, > security.tls.unrestricted_rc4_fallback" Instead, there should be a way to enable RC4 for just that one website, instead of every site, and the user should be suggested to use the more specific mechanism. And, we should make sure that the SSL error reporting mechanism is working so that the user can report the website to Mozilla (like cert errors).
Another take on the problem: By default, display a non-click-through-able error message explaining the error. The error page can be made click-through-able by setting a pref in about:config (security.tls.enable_insecure_rc4_option). (3.) should probably reference it. Remember the decision only for the current browser session (only in-memory), so that a website has to be re-confirmed to be allowed to use RC4 after each browser restart.
(In reply to agrigas from comment #2) > Created attachment 8597379 [details] > current messaging Not all RC4-only servers will fail with this error. Moreover, this error can happen even when the site is not RC4-only. You cannot assume this error indicates that the server is RC4-only. Otherwise bug 1113780 will be repeated.
(In reply to Masatoshi Kimura [:emk] from comment #5) > (In reply to agrigas from comment #2) > > Created attachment 8597379 [details] > > current messaging > > Not all RC4-only servers will fail with this error. Moreover, this error can > happen even when the site is not RC4-only. You cannot assume this error > indicates that the server is RC4-only. Otherwise bug 1113780 will be > repeated. I spoke to Richard about this, and the plan would be to make a unique error state for RC4-only servers distinct from what we use now as a generic error.
Assignee: nobody → agrigas
Status: NEW → ASSIGNED
Iteration: --- → 40.3 - 11 May
Points: --- → 5
please add feedback. Technical details copy/instructions TBD.
It was suggested that I crosspost from bug 1145261, since they are both soliciting similar feedback. You can see my reasoning more over there, but here is my suggested wording: This Connection is Insecure This website's server uses an obsolete encryption technology that makes information you submit, such as passwords and credit card numbers, accessible to eavesdroppers. What should I do? Please contact the website owners to let them know their site is not secure. It is not recommended to continue should this site contain or receive any sensitive information. Technical Details rc4.badssl.com has chosen to use a cipher (RC4) that is known to have cryptographic weaknesses, and its continued use is prohibited. I Understand the Risks If you understand the risks, you can tell Firefox to continue onward to this site. *Even if you trust the website, this error means that someone may be able to impersonate you or steal your information.* Add Exception // Get me out of here! -- Continuing to send RC4 amongst our supported ciphers is problematic on its own, and may cause these errors to appear when they didn't need to, e.g. when a server selects RC4 even though they may actually support a stronger cipher. I have seen this happen in situations where a server was configured to choose RC4 as their primary cipher in response to the BEAST attack. Instead of bombarding systems with scans for RC4 (such as through ssl-enum-ciphers in nmap), how about this: Step 1) Firefox attempts to handshake with the following cipher suites, which I believe is the standard in nightly: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) If those fail (ssl_error_no_cypher_overlap), we attempt to do another handshake with RC4 behind the scenes: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007) TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) TLS_RSA_WITH_RC4_128_SHA (0x0005) TLS_RSA_WITH_RC4_128_MD5 (0x0004) If that succeeds, we tear down the session without making any HTTP requests, present the error page and give them the option to continue onward, should they accept the risks. We would still present the gray triangle (or whatever) in such a case.
I'm sorry now I have to tell you that I didn't take a look at the ticket you linked :( This thread is very similar to the other one, I just assumed that you were talking about https://bugzilla.mozilla.org/show_bug.cgi?id=999544 in my previous post :/
two options will be attached, pending feedback
Attachment #8605269 - Flags: ui-review?(philipp)
Comment on attachment 8605269 [details] rc4v2a.png The final sentence is a bit of an awkward run-on. Maybe: If you understand the risks, you may proceed. However, even if you trust the website, this error means that someone may be able to steal your information.
(In reply to April King from comment #12) > Comment on attachment 8605269 [details] > rc4v2a.png > > The final sentence is a bit of an awkward run-on. Maybe: > > If you understand the risks, you may proceed. However, even if you trust > the website, this error means that someone may be able to steal your > information. Lets get consensus on the general approach and headline and I can have the Firefox team copywriter review the writing.
Need OK from security folks.
Comment on attachment 8605268 [details] rc4v2b.png I think this version works better, especially as long as the »Technical Details« section is collapsed. It might make sense to reverse the first sentence (put the part about information being viewable to others in front and the Why in the back. There are some styling issues here, but if I'm not mistaken this isn't a final style anyway, so we don't have to go down that rabbit hole now :)
Attachment #8605268 - Flags: ui-review?(philipp) → ui-review+
4 years ago
Attachment #8605269 - Flags: ui-review?(philipp) → ui-review-
Looking good, maybe you could add that the use of RC4 is prohibited by the IEEE now (as a technical detail) including the URL of the RFC 7465: http://tools.ietf.org/html/rfc7465
Comment on attachment 8605268 [details] rc4v2b.png This design looks great.
updated based on ui-review feedback and bug suggestions. Creating a visual design ticket to clean up the UI to meet our style standards.
(In reply to Masatoshi Kimura [:emk] from comment #19) > Comment on attachment 8610553 [details] > rc4 final.png > > > use is prohibited by IEEE. > IEEE != IETF fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
URL should be https://tools.ietf.org/html/rfc7465 not http://
Could we make "prohibited by the IETF" a hyperlink to https://tools.ietf.org/html/rfc7465 instead of having Learn more: https://tools.ietf.org/html/rfc7465? Seems like it would be a lot cleaner that way.
You need to log in before you can comment on or make changes to this bug.