471995 - A deleted permanent certificate exception still persists for some of the session

Status: RESOLVED DUPLICATE of bug 660749

(Core :: Security: PSM, defect)

Description

[Thomas Greenwood]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.1b3pre) Gecko/20081221 Firefox/3.1b3pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.1b3pre) Gecko/20081221 Firefox/3.1b3pre

This may be by design, however:

After visiting a site requiring a certificate exception where "Permanently Store this exception" was enabled, I deleted the offending certificate exception and for some time, within the same Firefox session, the certificate was still accepted. I am unsure at this time how long the exception is still allowed for. But a few minutes later the exception no longer works and I am once more prompted for the "Invalid Certificate". I Opened a new tab within the few minutes and browsed to the same URL and did not need the exception.

Reloading the browser immediately removes the exception as one would expect.

I have been able to reproduce this with Firefox 3.0.5 as well. 

It didn't make a difference if a page was using the excepted certificate at the time.

Reproducible: Always

Steps to Reproduce:
1. Browse to a secure site requiring a certificate exception and accept the exception with "Permanently store the exception" enabled.
2. Remove the exception from within Preferences.
3. Open a new tab and/or browse back to the secure site.
Actual Results:  
A new exception was not required and the page was allowed to load.

Expected Results:  
Prompt that the certificate was invalid(or equivalent) and required an exception before showing the page.

Also occurs with Firefox 3.0.5. I haven't checked any other version.

Comment 1

[Matthias Versen [:Matti]]

that's expected because a not permanently exception is a session only exception (removing a permanent one makes it a session exception again).

Did you close Firefox between removing the exception to close the current session ?

Comment 2

[Thomas Greenwood]

It may be expected but I'm not sure its good practice. Removing a Permanent Exception may be because you have decided to do no longer trust that certificate. Therefore the exception should be removed completely with the option of recreating it, regardless of whether it is the same session or not.

Comment 3

[Johnathan Nightingale [:johnath]]

I agree that this is surprising behaviour - Kai knows our cert caching/exception mechanisms best, so I'm hoping when he gets a second he can take a look, but he's a pretty busy guy.  I notice your platform is x86_64, have you noticed this problem on other platforms at all?  On the one hand, it might help to know it was 64-bit only, on the other, it would help to know if there's anything specific to the site/certificate

Comment 4

[Thomas Greenwood]

I can confirm that this also occurs in Firefox 3.0.5 32 bit under XP SP3.

I can also confirm it is not limited to one url, it also occurs with https://home.cornish-caravan.co.uk/roundcube/

Comment 5

[Kai Engert (:KaiE:)]

Maybe calling SSL_ClearSessionCache() after having deleted an exception would be sufficient?

Comment 6

[Kai Engert (:KaiE:)]

Hmm, we already call SSL_ClearSessionCache() in function nsCertOverrideService::ClearValidityOverride()

Comment 7

[Honza Bambas (:mayhemer)]

It could be potentially a keep-alive connection reuse, also according to the description: "But a few minutes later the exception no longer works".

Comment 8

[Honza Bambas (:mayhemer)]

We could use notification from bug 527157 to close all keep-alive connections when user deletes a cert exception. I will work on a way to make it a host-specific.

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

Is there a way to traverse keep-alive connections, and forcibly close them?  
There should be at most just a few of them, right?

Comment 10

[Honza Bambas (:mayhemer)]

(In reply to comment #9)
> Is there a way to traverse keep-alive connections, and forcibly close them?  
> There should be at most just a few of them, right?

There is currently no API to have a custom visitor or iterate all http connections, AFAIK, but it should not be that big problem to create such. We have a hash table in nsHttpConnectionManager that holds (among other things) nsHttpConnectionInfo objects, where we can get info about host name and if it is using ssl.

Not sure how ftp connection manager (if there is any) works, but I expect it to be very similar.

Then we have news, nntp, imap, pop3, smtp protocols that should also allow this interception. So, it seems to be a bigger deal.

We can only have an opt-in variant as observer registration provides.

Comment 11

[Kai Engert (:KaiE:)]

Yes, any solution to tear down all SSL sockets should be global, and not limited to a subset of protocols (like http).

Comment 12

[Honza Bambas (:mayhemer)]

Then we have to use a different mechanism then opt-in variant. I'll try a patch that will close all ssl sockets registered on level of PSM, we'll see how much I'll break.

Comment 13

[Kai Engert (:KaiE:)]

In the days where SeaMonkey was our primary product, and when some funding company had the requirement to use multiple user profiles without restarting the application, we had the "switch profile" feature. (This feature may still be offered in the SeaMonkey UI, I haven't looked lately.)

In order to support a profile switch, it was necessary to completely shut down NSS. This required us to completely bring down all networking, because otherwise NSS wouldn't allow to shutdown/reinit, because of open handles.

If you look at nsNSSComponent, you'll see broadcast events that are listened for.

IMHO the effort for fixing this bug may not be necessary. IMHO it would be sufficient to let the user know that a full application restart is necessary to ensure immediate complete effectiveness of the forgotten exception.

I recommend against it, and would rather recommend that you make use of the application-restart mechanism that is being used for addon-installation (and remind the user to restart, if the application doesn't support such an automatic restart).

If you really would like to invest the time to solve this bug, I recommend you follow the same path as that old profile switch attempt (but no need to shutdown)reinit NSS). So my proposal is:

- remind the user that immediate effectiveness for this change requires to temporarily close all open network connections
- shut down all networking
- clear all TLS sessions
- bring networking up

Comment 14

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

This will most likely be fixed by bug 660749 (you can verify by loading the page, adding an exception, deleting the exception, and shift-refreshing the page).