348601 - permanent certificate error overrides not removed after using "clear recent history..."

Status: RESOLVED WONTFIX

(Core :: Security: PSM, defect, P5)

Description

[carglue a t ya hoo do tcom]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060803 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060803 Firefox/1.5.0.4

When the Mismatched Certificate warning dialog appears:
   "You have attempted to establish a connection with XXX.  However, the security certificate presented belongs to YYY.  It is possible, though unlikely, that ..."

- the "Clear Private Data" option will not reset/clear this dialog, even if the Authenticated Sessions option is checked on the Clear Private Data popup.

Thus, once this dialog appears and has been confirmed/acknowleged, it will never reappear again for that url until the browser has been restarted. 
Nothing I could do would get it to reset again.

I have tried using the sanitize feature of the nsIBrowserGlue interface...
var glueService  = CC['@mozilla.org/browser/browserglue;1'].getService( CI.nsIBrowserGlue );
glueService.sanitize( null );
(along with ensuring that my privacy.item.sessions pref was set to true).

I've also tried clearing the authentication cached directly using:

var authService = CC['@mozilla.org/network/http-auth-manager;1'].getService( CI.nsIHttpAuthManager );
authService.clearAll();

Yet, nothing seems to clear/reset this warning until I restart the browser.

Note, this problem appears to be specific to the mismatched cert dialog only, not the other user/pass authentication dialogs, which do appear to clear/reset properly.  It may also be a problem for the expired cert warning, though I have not check for it.


Reproducible: Always

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

This appears to be a complaint about some Javascript method on some JavaScript
object.  NSS doesn't do Javascript.  I don't know what product is right for
this complaint, but I'm gonna guess PSM.  

I'm not sure there's any bug here.  I think these features are working as 
designed.  You might want there to be a new feature that clears out all 
certificate error overrides that the user has previously made, ones where
the user indicated that the override was to last for the rest of the process
lifetime.  That would be a new feature, AFAIK.  

Comment 2

[carglue a t ya hoo do tcom]

Two things:
1.  This has nothing to do with JavaScript.  The examples provided could've just as easily been written as C++ calls, as both would use the same XPCOM nsIBrowserGlue and nsIHttpAuthManager interfaces.

2.  Perhaps you are correct about this behavior being 'by design', but I cannot imagine why someone would want to 'sanitize' their user session certificate activity, yet keep any previous approvals or denials of mismatched or expired certificates.

This issue may be of most interest to embeders, or those who write apps for kiosk, training, demonstration, or other multi/transient user interfaces.  Note also, that it doesn't matter if a message is sent telling firefox that the profile is or has been switched, it will always retain the previous user's selections until restart.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

The last sentence in comment 2 sounds like a bug, pure and simple. 

Comment 4

[Kai Engert (:KaiE:)]

Mass change owner of unconfirmed "Core:Security UI/PSM/SMime" bugs to nobody.
Search for kaie-20100607-unconfirmed-nobody

Comment 5

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

Temporary certificate error overrides appear to be cleared as expected. Permanent certificate error overrides are not cleared. Moving this to a component where it will get the attention it needs.

Comment 6

[Ryan VanderMeulen [:RyanVM]]

Doesn't really feel like a Places bug, but starting with Mak to see if he has any ideas as to where to move this to.

Comment 7

[Marco Bonardo [:mak]]

If it's related to sanitize, it's just cause some of the used components is not clearing part of the data, and I have no idea if that's on purpose or a bug.

The only related thing I can find in sanitize.js is a call to
 let sss = Cc["@mozilla.org/ssservice;1"].getService(Ci.nsISiteSecurityService);
 sss.clearAll();
But I don't know if the outcome is the expected one.

Comment 8

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

(In reply to Marco Bonardo [::mak] from comment #7)
> If it's related to sanitize, it's just cause some of the used components is
> not clearing part of the data, and I have no idea if that's on purpose or a
> bug.

This is the question Firefox front-end needs to answer: when using "clear recent history", should (and when should) the browser also clear any permanently saved certificate error overrides?

> The only related thing I can find in sanitize.js is a call to
>  let sss =
> Cc["@mozilla.org/ssservice;1"].getService(Ci.nsISiteSecurityService);
>  sss.clearAll();
> But I don't know if the outcome is the expected one.

This is unrelated - it clears HSTS data. The temporary overrides are cleared as a result of clearing sessions:

  let sdr = Components.classes["@mozilla.org/security/sdr;1"]
                      .getService(Components.interfaces.nsISecretDecoderRing);
  sdr.logoutAndTeardown();

which calls:

NS_IMETHODIMP
nsSecretDecoderRing::LogoutAndTeardown()
{
...
  rv = nssComponent->LogoutAuthenticatedPK11();

which is:

nsresult nsNSSComponent::LogoutAuthenticatedPK11()
{
  nsCOMPtr<nsICertOverrideService> icos =
    do_GetService("@mozilla.org/security/certoverride;1");
  if (icos) {
    icos->ClearValidityOverride(
            NS_LITERAL_CSTRING("all:temporary-certificates"),
            0);
  }

Comment 9

[Marco Bonardo [:mak]]

(In reply to Dana Keeler [:keeler] (use needinfo?) from comment #8)
> (In reply to Marco Bonardo [::mak] from comment #7)
> > If it's related to sanitize, it's just cause some of the used components is
> > not clearing part of the data, and I have no idea if that's on purpose or a
> > bug.
> 
> This is the question Firefox front-end needs to answer: when using "clear
> recent history", should (and when should) the browser also clear any
> permanently saved certificate error overrides?

I'm sorry but I don't know the answer, I can only provide my opinion (I think we should).

I'm forwarding to Dolske, maybe he knows who could take such a decision in a more official way.

Comment 10

[Justin Dolske [:Dolske]]

Hmm, I think it's debatable. Clear Recent History doesn't clear things like bookmarks and passwords, and is generally targeting the ancillary things that accumulate as a side-effect of browsing, and isn't a post-facto replacement for Private Browsing or rolling back a profile to a previous state. Also, the cert override does say "permanently store".

I wouldn't object to clearing it, but neither is it a clear-cut bug! :)

Do we currently store the time the override was added? Is there an explicit API for clearing it? For CRH to handle clearing permanent exceptions, it would need to support clearing by time-range. Otherwise CRH would have to nuke all of them, and I don't think that's acceptable for a "permanent" override. (It's a bug that it nukes all temporary overrides, but not really a big deal because the impact is low.)

If we add this, I'd include it under "Site Preferences" (i.e. not a separate item), and have it affect both permanent and temporary exceptions.

Comment 11

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

We don't currently store the time the override was added (we could add that, though). There is an API for removing overrides, but again not by time.

Comment 12

[Simon Mainey]

Duplicate of Bug 518343 ?

Comment 14

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

Sure, but I'm going to say we shouldn't change how this works based on Dolske's reasoning in comment 10 re: bookmarks and passwords.