537103 - Client Certificate Authentication remembers decision when canceling

Status: RESOLVED DUPLICATE of bug 511384

(Core :: Security: PSM, defect)

Description

[Eddy Nigg (StartCom)]

Firefox remembers the selected certificate for client certificate authentication by default (Remember this decision). However when attempting to authenticate and clicking cancel (for various reasons, for example no certificate exists), Firefox apparently remembers that too.

Reproduce by going to https://www.startssl.com/?app=12 and click on "Authenticate" and hit cancel. Try to authenticate again and the request fails automatically. The only way to get out of this, is by restarting the browser completely.

Firefox should not send ANYTHING to the server when the request is canceled at the client side and certainly should not remember that decision. Users get very confused because they don't regularly restart their browser.

Comment 1

[Kaspar]

(In reply to comment #0)
> Firefox should not send ANYTHING to the server when the request is canceled at
> the client side

Should it immediately abort the handshake, or what do you mean by "not send anything"?

How would I be able to connect to a server without presenting a client cert, in this case? (Servers are sometimes configured for optional client auth.)

> and certainly should not remember that decision.

Quite the contrary: I certainly consider this a feature. Maybe the underlying issue is that a user can't clear remembered decisions without restarting the application, but the fix should definitely not consist of changing nsClientAuthRememberService to never remember "Cancel" decisions.

Comment 2

[Eddy Nigg (StartCom)]

(In reply to comment #1)
> Should it immediately abort the handshake, or what do you mean by "not send
> anything"?

Perhaps. If I click cancel I expect that it aborts everything and not continues. E.g. I don't want to connect to this site and not send a certificate.

Maybe there needs to be an option (empty select?) not to send a certificate and nevertheless try to connect. I believe the server can't indicate if it's optional, hence this might result in a hard failure or not.

> Quite the contrary: I certainly consider this a feature. Maybe the underlying
> issue is that a user can't clear remembered decisions without restarting the
> application, but the fix should definitely not consist of changing
> nsClientAuthRememberService to never remember "Cancel" decisions.

Well, it's not obvious to me that when the request is canceled (for various reasons, including forgetting to enter a smart card) and when trying again it remembers "cancel". From my experience, users believe client authentication is broken - it's certainly not obvious that the only way out is restarting the browser. Nor convenient in this particular situation.

Comment 3

[Kai Engert (:KaiE:)]

History context:

The behaviour "remember that the user canceled", was necessary, because we required a workaround for stable branches (where users where annoyed with repetitive prompts), but were our choices for UI changes were very limited (the only thing we were able to do was adding the checkbox to remember/not remember).

This workaround still lives on trunk, we haven't yet implemented a better solution.

Comment 4

[David Balažic]

So if I clear the checkbox, the "Cancel" will not be remembered?

Hopefully this will be cleaned up...

Comment 5

[Kai Engert (:KaiE:)]

(In reply to comment #4)
> So if I clear the checkbox, the "Cancel" will not be remembered?

correct

Comment 6

[David Balažic]

Note that IE has an option to forget/clear the remembered state with a button press.*
No need to restart the browser.

(sounds funny: MS product not requiring a restart... ;)

PS: Is there a bug about "Not being able to "log out" of certificate auth without restart" ?

* - In IE8 : menu Tools / Internet Options / Content / Certificates / Clear SSL state

Comment 7

[Kai Engert (:KaiE:)]

In Firefox:

Tools / clear recent history / time range: everything / details:

- check "Active Logins"
- uncheck everything else, so you don't lose that information
- Clear now

I've tested this with www.startssl.com
I have a personal cert, I authenticate, I select "remember", OK.
On the web site, in the upper right, I click that logout icon (go out of the door).

If I do, I will briefly see the start page, however, because Firefox has the use of the client cert remembered, it will immediately log in again using the client cert.


Next, I use above steps to "clear active logins".

Now, if I clock the logout icon on the StartSSL site, I will be really logged out.


I know that the current interface should be enhanced, but it hasn't happened yet, because of limited resources.

Comment 8

[Bruce A. Peebles]

I realize this 'zilla has been marked as a duplicate of  bug 511384  but I disagree with this assessment.

The original problem for this bug still exists. I will restate it here:

When using certain kinds of Authentication (like "Basic Authentication")
When the Firefox browser receives a "401 Authorization Required" header
it properly challenges the user for Uid/PW

Normally, a user would enter their Uid/PW and click OK... but the problem is seen when the user clicks CANCEL.

The stated problem is that when the user clicks CANCEL... Firefox choses to send the saved 'active' credentials to the server. These saved credentials may have been stored for days in the cache and are stale. When FireFox is running for weeks at a time, this can lead to inadvertently logging in as the wrong user because FireFox took it upon itself to send old credentials to the server.

As stated in original append "Firefox should not send ANYTHING to the server when the request is canceled"

To validate that FireFox is doing this, I have written my own webserver in Java so I can scrutinize the headers moving between FireFox and the Server.

Other browsers do not exhibit this behavior. This should be construed as a SECURITY HOLE in Firefox!!

Clicking CANCEL should never send saved userid/PW credentials to the server!!

Comment 9

[Gus Heck]

I would like to second Bruce's sentiment by noting that "cancel" is normally a "SAFE" operation (in the same sense as in SAFE/IDEMPOTENT/UNSAFE for GET/PUT/POST operations). Remembering a cancel as if it were a decision is always bad user interface design, and will always surprise the user. A user who is faced with a question that they don't know the answer to, or don't want to decide right now will always click cancel expecting to be able to decide later when they know more or have more time. 

In this case it also leads to an unrecoverable "soft crash" of the browser. Technically the browser is up, but if the user actually needed to access the site (or subsequently needs to), the browser must be restarted and therefore is no more useful than if it crashed.

I ran into this when I restarted my browser. When my tabs opened was immediately faced with this pop-up, but didn't need the page at the moment. I canceled expecting that I could decide later. 30 min later I tried to get to the site in question and had to restart the browser again. If you have to close the browser, it's actually worse than crashing because the user has to GUESS that shutting down the browser will fix the problem. This is a very bad bug, and failing to track this specific form bad UI by duping it against a redesign bug leaves open the possibility that the new UI will fall into the same pit. At most it should "relate to" or be "blocked by" the bug it is presently marked as a duplicate of.