[UX] Improve error messaging when RC4 server pages break

RESOLVED FIXED

Status

()

defect
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: agrigas, Assigned: agrigas)

Tracking

Trunk
Points:
5
Dependency tree / graph
Bug Flags:
firefox-backlog +
qe-verify -

Firefox Tracking Flags

(firefox40 affected)

Details

(Whiteboard: [ux])

Attachments

(2 attachments, 4 obsolete attachments)

Assignee

Description

4 years ago
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"
Flags: firefox-backlog?
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.
Assignee

Comment 2

4 years ago
Posted image current messaging
(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.
Assignee

Comment 6

4 years ago
(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.
Flags: qe-verify-
Flags: firefox-backlog?
Flags: firefox-backlog+
Whiteboard: [ux]
Assignee: nobody → agrigas
Status: NEW → ASSIGNED
Iteration: --- → 40.3 - 11 May
Points: --- → 5
Assignee

Comment 7

4 years ago
Posted image Draft 1 or Redesigned Error Screen (obsolete) —
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.

Comment 9

4 years ago
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 :/
Iteration: 40.3 - 11 May → 41.1 - May 25
Assignee

Comment 10

4 years ago
Posted image rc4v2b.png (obsolete) —
two options will be attached, pending feedback
Attachment #8600904 - Attachment is obsolete: true
Attachment #8605268 - Flags: ui-review?(philipp)
Assignee

Comment 11

4 years ago
Posted image rc4v2a.png (obsolete) —
option 2
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.
Assignee

Comment 13

4 years ago
(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.
Flags: needinfo?(rlb)
Flags: needinfo?(dkeeler)
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+

Comment 16

4 years ago
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.
Flags: needinfo?(dkeeler)

Updated

4 years ago
Blocks: RC4
Assignee

Comment 18

4 years ago
Posted image rc4 final.png (obsolete) —
updated based on ui-review feedback and bug suggestions. Creating a visual design ticket to clean up the UI to meet our style standards.
Attachment #8605268 - Attachment is obsolete: true
Attachment #8605269 - Attachment is obsolete: true
Assignee

Updated

4 years ago
Blocks: 1168382
Comment on attachment 8610553 [details]
rc4 final.png

> use is prohibited by IEEE.
IEEE != IETF
Assignee

Comment 20

4 years ago
Posted image rc4 final.png
Attachment #8610553 - Attachment is obsolete: true
Assignee

Comment 21

4 years ago
(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
Assignee

Updated

4 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED

Comment 22

4 years ago
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.
Depends on: 1168635
Flags: needinfo?(rlb)
You need to log in before you can comment on or make changes to this bug.