1207137 - Provide an affordance to override cert errors like weak crypto

Status: VERIFIED FIXED

(Firefox :: General, defect, P1)

Description

[Panos Astithas (he/him) [:past] (please ni?)]

When the user comes across a site that uses weak crypto, like RC4, the error page should provide a link to temporarily override the error and visit the page. See the UI prototype here:

http://brampitoyo.github.io/fx-untrusted-connection/rc4.xhtml

After clicking the Advanced button, the use can see a link at the bottom with the copy "(Not secure) Try loading expired.badssl.com using outdated security". Clicking that link should navigate to the original page, temporarily suspending the error check. Then, a popup notification would be overlaid on the content page, with the message "Firefox recommends that you don't enter your password, credit card and other personal information on this website." (clicking the mockup link will display mockups of the notification).

Comment 1

[Panos Astithas (he/him) [:past] (please ni?)]

The same affordance should be present in the case of an untrusted connection, but in that case the copy would be:

(Not secure) Go to expired.badssl.com

See http://brampitoyo.github.io/fx-untrusted-connection/

In the case of a severe error, no such affordance should be provided, but only an explanation of why the user cannot visit the site:

---------------------
Why can’t I go to expired.badssl.com?
The website owner has asked Firefox to stop this page from loading. It’s not your fault, and it’s not Firefox’s fault.

How do I fix it?
Try visiting this page a little bit later, or visit it using another network.
---------------------

The above is from the mockup here:

http://brampitoyo.github.io/fx-untrusted-connection/severe.xhtml

Comment 2

[Justin Dolske [:Dolske]]

This seems surprising -- we've already announced RC4 support is being removed in January '16 (https://blog.mozilla.org/security/2015/09/11/deprecating-the-rc4-cipher/), which is Firefox 44 (aka the current Nightly train). Why would we be adding UI for this? (And in general we've avoided adding simple one-click-overrides for TLS errors, because it's an easy footgun.)

Comment 3

[Panos Astithas (he/him) [:past] (please ni?)]

(In reply to Justin Dolske [:Dolske] from comment #2)
> This seems surprising -- we've already announced RC4 support is being
> removed in January '16
> (https://blog.mozilla.org/security/2015/09/11/deprecating-the-rc4-cipher/),
> which is Firefox 44 (aka the current Nightly train). Why would we be adding
> UI for this?

Javaun, was the plan to ship this before we stop supporting RC4? Should we explicitly put RC4 into the same bucket as the severe error case that can't be overridden?

http://brampitoyo.github.io/fx-untrusted-connection/severe.xhtml

> (And in general we've avoided adding simple one-click-overrides
> for TLS errors, because it's an easy footgun.)

Technically it's still two clicks (click on "Advanced" -> click on link), although a temporary override avoids the need to interact with the certificate import dialog afterwards.

Comment 4

[Javaun Moradi [:javaun]]

This is intended to coincide with the RC4 deprecation and the direction here comes from April, Bram, and Richard Barnes. I'm going to NI'ing April and Richard to answer your question Justin.

Two questions from Justin:

1. How this cert error works with the timing of RC4 deprecation.

2. Are overrides a foot-gun we should accept

Comment 5

[Steve Workman [:sworkman] (INACTIVE)]

Richard and April can chime in with exact stats if need be, but the tl;dr is that there is a small, but not insignificant amount of sites that still depend on RC4; at this time we have to provide an override for backwards compatibility with the outdated security.

(Bug 1201024, which disables the whitelist on Nightly and Aurora depends on this UI being present).

Comment 6

[Steve Workman [:sworkman] (INACTIVE)]

Re the UI prototype (http://brampitoyo.github.io/fx-untrusted-connection/rc4.xhtml), can we have the override link be underlined or something to look like it's clickable? ni?bram

Comment 7

[Bram Pitoyo [:bram]]

In previous iterations, we’ve tried using a button shape (which made it look clickable) or a red button (which made it look dangerous but also attractive). We decided to go with a link that looks grey and disabled, because we want to discourage users to click it.

Is there a specific reason why we want the proceed link to be more attractive?

Comment 8

[Steve Workman [:sworkman] (INACTIVE)]

Thanks Bram - there was a concern that this would make it too buried to be usable. The use case that has come up frequently is school websites and their users - the rest of the page is great, and the Advanced button should be warning enough. What do you think?

Comment 9

[Bram Pitoyo [:bram]]

Attachment: error cert page - link colour

Too buried to be usable is a good reason. At the same time, it may not be smart to revert back to a button shape.

Instead, we can have the proceed link coloured blue and the error code link coloured gray, as shown.

And to make the behaviour consistent, we will apply the same font style to every error cert page.

What do you think?

Comment 10

[April King [:April]]

@sworkman: RC4-only is at about only .07% of TLS connections.  With the Mozilla, Google, and Microsoft announcements, I think it will likely continue to fall before FF44. It's rather insignificant by this point.

That said, I believe the plan is to NOT allow it to be overridden anywhere outside of about:config; that is what we announced, at least. Given that people won't be able to connect to these pages with any web browser if they miss the deadline, I would expect them to be fixed rather quickly.

As such, I don't think it's worthwhile to put in the significant engineering effort needed to have easy fallback.

Comment 11

[Steve Workman [:sworkman] (INACTIVE)]

(In reply to Bram Pitoyo [:bram] from comment #9)
> What do you think?

LGTM. Agreed, a button would not be good. Your new mockup looks more like something that could be clicked, but still hidden behind the advanced button.

(In reply to April King from comment #10)
> @sworkman: RC4-only is at about only .07% of TLS connections.  With the
> Mozilla, Google, and Microsoft announcements, I think it will likely
> continue to fall before FF44. It's rather insignificant by this point.

Insignificant for the overall number of TLS connections for all Firefox users, but not necessarily for individual users. But that's anecdotal ;) and we could argue "significant" for a long time. The point is that there is a long tail of sites and users that could benefit for a somewhat buried fallback UX, specifically users that aren't going to go to about:config.

> That said, I believe the plan is to NOT allow it to be overridden anywhere
> outside of about:config; that is what we announced, at least. Given that
> people won't be able to connect to these pages with any web browser if they
> miss the deadline, I would expect them to be fixed rather quickly.

The blog post doesn't mention it, but the dev-platform piece does - https://lists.mozilla.org/pipermail/dev-platform/2015-September/011541.html ...

"The security and UX teams are discussing possibilities for UI that would automate whitelisting of sites for users."

> As such, I don't think it's worthwhile to put in the significant engineering
> effort needed to have easy fallback.

Not "easy", just easier than about:config. I understand all your rationale here, but I think for now we have to provide some kind of fallback UX. This is still a big step forward in deprecating RC4, and eventually we'll disable the fallback UX too.

Comment 12

[Bram Pitoyo [:bram]]

Great. I’ve tweaked the example page to suit the new link colour.

Comment 13

[Masatoshi Kimura [:emk]]

[Tracking Requested - why for this release]:
We already promised to disable RC4 since Firefox 44 [1]. Keeler requested an override UX before disabling RC4 [2].

This deadline is critical because we have to keep the schedule in sync with other browser vendors.

[1] https://blog.mozilla.org/security/2015/09/11/deprecating-the-rc4-cipher/
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1201025#c2

Comment 14

[Bram Pitoyo [:bram]]

Hi Masatoshi, are we blocked on UX design, or UX coding and implementation? I think my design has covered everything mentioned in Keeler’s post, but I might be wrong. If so, I can fix this design quickly – either today or tomorrow.

Comment 15

[Masatoshi Kimura [:emk]]

Blocked on the implementation. I'm writing a patch to implement this.

Comment 16

[Masatoshi Kimura [:emk]]

Attachment: PSM change

Comment 17

[Masatoshi Kimura [:emk]]

Attachment: docshell change

Comment 18

[Masatoshi Kimura [:emk]]

Attachment: Implement weak crypto override UI

This patch is based on the current styling because we need this for Fx44. (I assume visual update will be done all at once.)

Comment 19

[:Gijs (he/him)]

Comment on attachment 8674205 [details] [diff] [review]
Implement weak crypto override UI

Review of attachment 8674205 [details] [diff] [review]:
-----------------------------------------------------------------

I haven't looked at the styling/css yet, but I have a number of remarks about the JS/approach below.

It probably makes sense to request the next review from :ttaubert instead.

::: browser/base/content/aboutNetError.xhtml
@@ +131,5 @@
> +        // Display weak crypto advanced UI
> +        document.getElementById('weakCryptoAdvanced').style.display = 'block';
> +
> +        // Get the hostname and add it to the panel
> +        for (span of document.querySelectorAll('span.hostname')) {

You should declare span. Also, please qsA from a relevant container (like the weakCryptoAdvanced(Panel) node) as right now you're also affecting undisplayed error strings... You may want to stick that container in a temp.

Also, please use double quotes in JS (all through your patch).

@@ +132,5 @@
> +        document.getElementById('weakCryptoAdvanced').style.display = 'block';
> +
> +        // Get the hostname and add it to the panel
> +        for (span of document.querySelectorAll('span.hostname')) {
> +          span.textContent = document.location.hostname;

Are we intentionally omitting port here (for the non-443 case) ?

@@ +138,5 @@
> +
> +        // Register click handler for the weakCryptoAdvancedPanel
> +        document.getElementById('showWeakCryptoAdvancedPanel')
> +                .addEventListener('click', function togglePanelVisibility() {
> +          var panel = document.getElementById('weakCryptoAdvancedPanel');

If you move this temp out of the function, you can get away with just:

.addEventListener('click', toggleDisplay.bind(null, panel));

@@ +274,5 @@
>            }
> +          if (getErrorCode() == "weakCryptoUsed") {
> +            showWeakCryptoAdvanced();
> +            var overrideLink = document.getElementById('overrideWeakCrypto');
> +            overrideLink.addEventListener('click', doOverride.bind(overrideLink), false);

It seems like this is only useful/necessary once the advanced panel is shown, right? In which case, please do it there instead? :-)

@@ +536,5 @@
>  
> +      <!-- UI for option to override weak crypto errors. Removed on
> +           init for other error types .-->
> +      <div id="weakCryptoAdvanced">
> +        <a id="showWeakCryptoAdvancedPanel" href="#">&weakCryptoAdvanced.title;<span class="downArrow"> ▼</span></a>

Nit: please use an html entity for the arrow.

::: browser/base/content/browser.js
@@ +2810,5 @@
> +      case "Browser:OverrideWeakCrypto":
> +        let weakCryptoOverride = Cc["@mozilla.org/security/weakcryptooverride;1"]
> +                                   .getService(Ci.nsIWeakCryptoOverride);
> +        weakCryptoOverride.addWeakCryptoOverride(
> +          msg.data.location.hostname,

Why doesn't this use the port? That seems wrong.

::: browser/base/content/content.js
@@ +342,5 @@
> +
> +    sendAsyncMessage("Browser:OverrideWeakCrypto", {
> +        documentURI: contentDoc.documentURI,
> +        location: {hostname: location.hostname, port: location.port}
> +      });

Nit: indentation.

::: browser/locales/en-US/chrome/overrides/netError.dtd
@@ +218,5 @@
> +
> +<!ENTITY weakCryptoUsed.title "Your connection is not secure">
> +<!-- LOCALIZATION NOTE (weakCryptoUsed.longDesc) - Do not translate
> +     "ssl_error_no_cypher_overlap". -->
> +<!ENTITY weakCryptoUsed.longDesc "Advanced info: ssl_error_no_cypher_overlap">

Do we always use this ("weak crypto") error when no cipher overlap is available? That seems misleading, because we have had bugreported cases of websites that use modern ciphers that work in Chrome and don't work in Firefox. This will make it harder to diagnose these cases, punishes people for using modern crypto, and misleads users.

If we don't always use this error page for that error code, then I think we should just omit the error code (or use a different one that we make up here even if it has no nss equivalent) because it'll confuse bugreports with other cases of ssl_error_no_cypher_overlap.

Comment 20

[Masatoshi Kimura [:emk]]

Attachment: Implement weak crypto override UI, v2

(In reply to :Gijs Kruitbosch from comment #19)
> ::: browser/base/content/aboutNetError.xhtml
> @@ +132,5 @@
> > +        document.getElementById('weakCryptoAdvanced').style.display = 'block';
> > +
> > +        // Get the hostname and add it to the panel
> > +        for (span of document.querySelectorAll('span.hostname')) {
> > +          span.textContent = document.location.hostname;
> 
> Are we intentionally omitting port here (for the non-443 case) ?

I followed the sslv3 precedent.

> ::: browser/base/content/browser.js
> @@ +2810,5 @@
> > +      case "Browser:OverrideWeakCrypto":
> > +        let weakCryptoOverride = Cc["@mozilla.org/security/weakcryptooverride;1"]
> > +                                   .getService(Ci.nsIWeakCryptoOverride);
> > +        weakCryptoOverride.addWeakCryptoOverride(
> > +          msg.data.location.hostname,
> 
> Why doesn't this use the port? That seems wrong.

Our fallback whitelist does not have a concept of port. That is, all port on the host will be affected by the whitelist.

> ::: browser/locales/en-US/chrome/overrides/netError.dtd
> @@ +218,5 @@
> > +
> > +<!ENTITY weakCryptoUsed.title "Your connection is not secure">
> > +<!-- LOCALIZATION NOTE (weakCryptoUsed.longDesc) - Do not translate
> > +     "ssl_error_no_cypher_overlap". -->
> > +<!ENTITY weakCryptoUsed.longDesc "Advanced info: ssl_error_no_cypher_overlap">
> 
> Do we always use this ("weak crypto") error when no cipher overlap is
> available? That seems misleading, because we have had bugreported cases of
> websites that use modern ciphers that work in Chrome and don't work in
> Firefox. This will make it harder to diagnose these cases, punishes people
> for using modern crypto, and misleads users.

See the discussion in bug 1168635 comment #15 and onwards. PSM module owners (both former and current) really dislike to add complexity for the edge case.

Comment 21

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8674204 [details] [diff] [review]
docshell change

r=me

Comment 22

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Comment on attachment 8674203 [details] [diff] [review]
PSM change

Review of attachment 8674203 [details] [diff] [review]:
-----------------------------------------------------------------

Great - r=me.

Comment 23

[Justin Dolske [:Dolske]]

(In reply to Steve Workman [:sworkman] (please use needinfo) from comment #11)

> > As such, I don't think it's worthwhile to put in the significant engineering
> > effort needed to have easy fallback.
> 
> Not "easy", just easier than about:config. I understand all your rationale
> here, but I think for now we have to provide some kind of fallback UX. This
> is still a big step forward in deprecating RC4, and eventually we'll disable
> the fallback UX too.

Do we know exactly what Chrome and IE/Edge are doing? Are they also providing fallback UI to reenable RC4?

Comment 24

[Masatoshi Kimura [:emk]]

We can easily remove the override UX later, but the opposite is quite difficult (especially given that this patch requires string changes). Let's add the UX for now so that we can follow whatever Chrome/Edge does.

Comment 25

[Masatoshi Kimura [:emk]]

Moreover, the PSM module owner refused to disable RC4 without an override UX (see bug 1201025). We shouldn't miss the Fx44 train for bikeshedding.

Comment 26

[Tim Taubert [:ttaubert] (inactive)]

Comment on attachment 8674237 [details] [diff] [review]
Implement weak crypto override UI, v2

Review of attachment 8674237 [details] [diff] [review]:
-----------------------------------------------------------------

I don't have a good understanding of how exactly our error pages work but I think this is okay.

Looks mostly good except that nsIWeakCryptoOverride isn't clear about ports. We should clarify before landing this.

::: browser/base/content/aboutNetError.xhtml
@@ +141,5 @@
> +        document.getElementById("showWeakCryptoAdvancedPanel")
> +                .addEventListener("click", toggleDisplay.bind(null, panel));
> +
> +        var overrideLink = document.getElementById("overrideWeakCrypto");
> +        overrideLink.addEventListener("click", doOverride.bind(overrideLink), false);

Did you try this patch? .bind() will assign the first arg to |this| in the bound function, so that shouldn't work. Either use .bind(null, link) or:

overrideLink.addEventListener("click", () => doOverride(overrideLink));

@@ +388,5 @@
>          e.target.disabled = true;
>        }
> +
> +      function learnMoreWeakCrypto() {
> +        location.href = "https://support.mozilla.org/kb/how-resolve-weak-crypto-error-messages-firefox";

Is there a bug on file to make sure we don't forget actually creating this page?

::: browser/base/content/browser.js
@@ +2810,5 @@
> +      case "Browser:OverrideWeakCrypto":
> +        let weakCryptoOverride = Cc["@mozilla.org/security/weakcryptooverride;1"]
> +                                   .getService(Ci.nsIWeakCryptoOverride);
> +        weakCryptoOverride.addWeakCryptoOverride(
> +          msg.data.location.hostname,

As Gijs already mentioned, the lack of a port here seems off.

In the IDL, addWeakCryptoOverride() has a comment that mentions a port but it doesn't take any port parameters. removeWeakCryptoOverride() OTOH does take a port. So what's up with that?

@@ +2812,5 @@
> +                                   .getService(Ci.nsIWeakCryptoOverride);
> +        weakCryptoOverride.addWeakCryptoOverride(
> +          msg.data.location.hostname,
> +          PrivateBrowsingUtils.isBrowserPrivate(gBrowser.selectedBrowser),
> +          true);

true /* temporary */);

Comment 27

[Masatoshi Kimura [:emk]]

Attachment: Implement weak crypto override UI, v3

(In reply to Tim Taubert [:ttaubert] from comment #26)
> ::: browser/base/content/aboutNetError.xhtml
> @@ +141,5 @@
> > +        document.getElementById("showWeakCryptoAdvancedPanel")
> > +                .addEventListener("click", toggleDisplay.bind(null, panel));
> > +
> > +        var overrideLink = document.getElementById("overrideWeakCrypto");
> > +        overrideLink.addEventListener("click", doOverride.bind(overrideLink), false);
> 
> Did you try this patch? .bind() will assign the first arg to |this| in the
> bound function, so that shouldn't work. Either use .bind(null, link) or:

Hm, I tried but the bug was not uncovered. The doOverride() parameter will be eventually used in retryThis(), but location.reload(); will have already been kicked before I see the error. Anyway I fixed this using an arrow function.

> overrideLink.addEventListener("click", () => doOverride(overrideLink));
> 
> @@ +388,5 @@
> >          e.target.disabled = true;
> >        }
> > +
> > +      function learnMoreWeakCrypto() {
> > +        location.href = "https://support.mozilla.org/kb/how-resolve-weak-crypto-error-messages-firefox";
> 
> Is there a bug on file to make sure we don't forget actually creating this
> page?

Filed bug 1215490.

> ::: browser/base/content/browser.js
> @@ +2810,5 @@
> > +      case "Browser:OverrideWeakCrypto":
> > +        let weakCryptoOverride = Cc["@mozilla.org/security/weakcryptooverride;1"]
> > +                                   .getService(Ci.nsIWeakCryptoOverride);
> > +        weakCryptoOverride.addWeakCryptoOverride(
> > +          msg.data.location.hostname,
> 
> As Gijs already mentioned, the lack of a port here seems off.
> 
> In the IDL, addWeakCryptoOverride() has a comment that mentions a port but
> it doesn't take any port parameters. removeWeakCryptoOverride() OTOH does
> take a port. So what's up with that?

addWeakCryptoOverride() had a port argument, but it was removed by reviewer's request. I forgot to remove the port argument from the method comment. Thanks for catching this. I'll file a followup bug to fix the comment.
I couldn't remove a port from removeWeakCryptoOverride() because it was needed unlike addWeakCryptoOverride(). See bug 1168635 comment #35 & #36 for more details.

> @@ +2812,5 @@
> > +                                   .getService(Ci.nsIWeakCryptoOverride);
> > +        weakCryptoOverride.addWeakCryptoOverride(
> > +          msg.data.location.hostname,
> > +          PrivateBrowsingUtils.isBrowserPrivate(gBrowser.selectedBrowser),
> > +          true);
> 
> true /* temporary */);

Done.

Comment 28

[Masatoshi Kimura [:emk]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=a4d7b2be75cf

Comment 29

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

(In reply to Masatoshi Kimura [:emk] from comment #27)
> addWeakCryptoOverride() had a port argument, but it was removed by
> reviewer's request. I forgot to remove the port argument from the method
> comment. Thanks for catching this. I'll file a followup bug to fix the
> comment.
> I couldn't remove a port from removeWeakCryptoOverride() because it was
> needed unlike addWeakCryptoOverride(). See bug 1168635 comment #35 & #36 for
> more details.

A little more detail on this:

The weak crypto fallback list works on a per-hostname basis. That is, if a host is on that list, Firefox will attempt to use weak crypto when connecting to that host on any port (if it heuristically detects that only weak ciphers are supported). However, if there is ever a successful connection to that host that doesn't use weak ciphers, Firefox needs to update internal data structures that do depend on what port the connection was on. This could in theory result in an unexpected state if Firefox connects to a host that only supports weak ciphers on one port but supports strong ciphers on another port. So, there are some edges cases we could chase down if we have time.

Comment 30

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/942e5f11f8ce
https://hg.mozilla.org/integration/fx-team/rev/4ac1b4ce5cfc
https://hg.mozilla.org/integration/fx-team/rev/40c6bcb88bc4

Comment 31

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/942e5f11f8ce
https://hg.mozilla.org/mozilla-central/rev/4ac1b4ce5cfc
https://hg.mozilla.org/mozilla-central/rev/40c6bcb88bc4

Comment 32

[Steve Workman [:sworkman] (INACTIVE)]

Clearing needinfo since the patch has landed.

Comment 33

[Paul Silaghi, QA [:pauly]]

(In reply to Panos Astithas [:past] from comment #0)
> When the user comes across a site that uses weak crypto
Can you provide some examples in order to test this?

Comment 34

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

(In reply to Paul Silaghi, QA [:pauly] from comment #33)
> (In reply to Panos Astithas [:past] from comment #0)
> > When the user comes across a site that uses weak crypto
> Can you provide some examples in order to test this?

https://rc4.badssl.com/ is probably the best test site, since it's designed to only use RC4 and won't be "fixed".
You can find others in the list of bugs that block bug 1138101.

Comment 35

[Paul Silaghi, QA [:pauly]]

Thanks. Couple of observations:
1. "Learn more" button points to https://support.mozilla.org/en-US/kb/how-resolve-weak-crypto-error-messages-firefox which doesn't seem to be ready yet
2. How can I reset the exception? Once allowed, the exception doesn't appear again even after deleting the entire history.

Comment 36

[Masatoshi Kimura [:emk]]

(In reply to Paul Silaghi, QA [:pauly] from comment #35)
> Thanks. Couple of observations:
> 1. "Learn more" button points to
> https://support.mozilla.org/en-US/kb/how-resolve-weak-crypto-error-messages-
> firefox which doesn't seem to be ready yet

I filed bug 1215490, but no one responded yet.

> 2. How can I reset the exception? Once allowed, the exception doesn't appear
> again even after deleting the entire history.

There is no explicit UI to remove the exception. The exception will be cleared when the browser is closed.

Comment 37

[Paul Silaghi, QA [:pauly]]

(In reply to Masatoshi Kimura [:emk] from comment #36)
> There is no explicit UI to remove the exception. The exception will be
> cleared when the browser is closed.
It doesn't clear after simply restarting the browser.

Comment 38

[Panos Astithas (he/him) [:past] (please ni?)]

(In reply to Paul Silaghi, QA [:pauly] from comment #37)
> It doesn't clear after simply restarting the browser.

In case you have configured the browser to open the last page on startup, did you try reloading the page after restarting? That's the only somewhat confusing behavior that I can see with rc4.badssl.com, but that's due to page caching.

Comment 39

[Masatoshi Kimura [:emk]]

(In reply to Paul Silaghi, QA [:pauly] from comment #37)
> (In reply to Masatoshi Kimura [:emk] from comment #36)
> > There is no explicit UI to remove the exception. The exception will be
> > cleared when the browser is closed.
> It doesn't clear after simply restarting the browser.

Probably because the page was loaded from the cache.

Comment 40

[Bram Pitoyo [:bram]]

(In reply to Masatoshi Kimura [:emk] from comment #36)
> There is no explicit UI to remove the exception. The exception will be
> cleared when the browser is closed.

I have proposed that we add exception permanently by default, but always show a yellow flag afterwards (see http://brampitoyo.github.io/fx-untrusted-connection/untrusted-connection-warning-ui.png). This yellow flag would have a button to revoke exception.

We may also be able to have this revoke interface be inside the Control Center.

But the easiest thing to do right now may be to show the add exception modal dialogue that we currently use. In this dialogue, user can choose to add permanent exception, or proceed with temporary exception.

Comment 41

[Masatoshi Kimura [:emk]]

(In reply to Bram Pitoyo [:bram] from comment #40)
> I have proposed that we add exception permanently by default, but always
> show a yellow flag afterwards (see
> http://brampitoyo.github.io/fx-untrusted-connection/untrusted-connection-
> warning-ui.png). This yellow flag would have a button to revoke exception.

Filed bug 1219088 for this.

> We may also be able to have this revoke interface be inside the Control
> Center.

What is the Control Center?

> But the easiest thing to do right now may be to show the add exception modal
> dialogue that we currently use. In this dialogue, user can choose to add
> permanent exception, or proceed with temporary exception.

The RC4 error use a completely different API under the hood from one cert errors are using. Actually it is not even a cert error.
The current dialog will load and show a certificate, but it does not make sense for the RC4 error. I don't think the current dialog is reusable for the RC4 error.

Comment 42

[Paul Silaghi, QA [:pauly]]

(In reply to Masatoshi Kimura [:emk] from comment #39)
> (In reply to Paul Silaghi, QA [:pauly] from comment #37)
> > (In reply to Masatoshi Kimura [:emk] from comment #36)
> > > There is no explicit UI to remove the exception. The exception will be
> > > cleared when the browser is closed.
> > It doesn't clear after simply restarting the browser.
> 
> Probably because the page was loaded from the cache.
I guess it was somehow loaded from the cache.
Confirmed it's working fine after restart on 44.0a1 (2015-10-29) Win 7.
Verified fixed.

Comment 43

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Even though this has been fixed and verified, it's something worth tracking for 44.