285440 - Firefox UI to clear SSL session

Status: RESOLVED FIXED

(Firefox :: Security, enhancement)

Description

[Julien Gilli]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041207 Firefox/1.0 (Debian package 1.0-5)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041207 Firefox/1.0 (Debian package 1.0-5)

In IE, it is possible to clear the current SSL session (via "Tools -> Internet
Options -> Content -> Clear SSL State"). It is very handy when playing with
several certificates. We, as PKI developers, do it all day long. Our users have
to do this whenever they want to change the certificate they present to the
server. However they can't because :
- they don't want to check the "ask everytime" option because it asks too often.
- there is no way to close the current ssl session AFAIK.

I didn't find any plan to develop such a functionnality. We can achieve this
with Mozilla by clicking on "Tools -> Password Manager -> Logout". Is it
something planned, or undesirable ?

Keep up the good work, and thank you very much for your attention !

Reproducible: Always

Comment 1

[Daniel Veditz [:dveditz]]

There are existing enhancement requests asking to implement the Suite
functionality, but they're focused on HTTP auth logout and might only implement
that part of it.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

I am not entirely sure what all is done by IE's "Clear SSL State", but
I'd guess tht it clears the SSL client cache.  There is a bug about that 
already.  So, I'm marking this as a dup.  Ig you think this is not a dup,
please add a comment stating why not.


*** This bug has been marked as a duplicate of 194141 ***

Comment 3

[Daniel Veditz [:dveditz]]

Reopening. Fixing that core bug does not make sure there's some Firefox UI
widget that calls the hook.

Comment 4

[tony-mozilla1]

I would also love to see this feature added (I've just voted).   It seems to me
that adding a button "Clear SSL/TLS State" under Security might be enough here.  

A more heavy-weight solution would be to add the entries in the Manage
Certificates control panel under the "Web Sites" tab when they are accepted
temporarily, and flag these entries somehow as temporary (vs. permanent).  Then,
hooks to be able to View/Edit/Delete the temporary entries can be added, and the
temporary entries can be cleaned up automatically on Firefox shutdown/startup. 
I'm not even sure if this would be possible but it sure would be a slick
interface if it is.

Either way, I don't think this is blocked by bug 194141.  It seems the
underlying hooks are already there.

Comment 5

[Kai Engert (:KaiE:)]

Before I add more comments, please help me with a confusion.

At the end of your initial comment you say:
>> We can achieve this with Mozilla by clicking on "Tools -> Password Manager ->
Logout". <<

Do you say, 

a) this command already solves all your problems?

or

b) this command should be improved to do more cleanup?

Comment 6

[Julien Gilli]

I say that this command already does what i want, i.e it clears the ssl 
session and provides me with a dialog to choose the certificate to use when 
reloading the web page (or another web page).

However, it probably does others things related to passwords cache or 
whatever, so i suppose it may be stripped down to only ssl session clearing.

Comment 7

[Daniel Veditz [:dveditz]]

(In reply to comment #6)
> I say that this command already does what i want, i.e it clears the ssl 
> session and provides me with a dialog to choose the certificate to use when 
> reloading the web page (or another web page).

Kai: note that it does what he wants *in Mozilla* (suite). This bug is about
adding some way to get the same effect in *Firefox*.

Comment 8

[Mike Connor [:mconnor]]

I think we want this as a part of the Sanitize function, if anything.

Comment 9

[Mike Connor [:mconnor]]

Attachment: adds old Mozilla "Log Out" functionality to sanitize

This resets the master password bits, and clears http auth sessions.  This logs
me out of the non-cookie SSL sites I've tested so far, but I'm not sure it does
everything I want.

Comment 10

[Mike Connor [:mconnor]]

beltzner, is there something better than "Login Sessions" to use here?

Comment 11

[Daniel Veditz [:dveditz]]

Comment on attachment 190509 [details] [diff] [review]
adds old Mozilla "Log Out" functionality to sanitize

> pref("privacy.item.siteprefs",  false);
>+pref("privacy.item.sessions",   true);

Nit: I'd prefer "privacy.sanitize.item.foo" for better grouping/sense/clarity.
Otherwise item.foo true/false what?

>+        // if we've got a master password and we've entered it, clear that
>+        var pk11db = Components.classes["@mozilla.org/security/pk11tokendb;1"]
>+                               .getService(Components.interfaces.nsIPK11TokenDB);
>+        var token = pk11db.findTokenByName("");

As long as we're being paranoid and clearing things it might be better to call
nsISecretDecoderRing::logoutAndTeardown()

And if you're concerned about SSL session data in particular (via IRC
conversation) then this check-in ought to include the fix for bug 194141

(also via irc, the font stuff from another bug will be taken out of the patch)

Comment 12

[Mike Connor [:mconnor]]

Attachment: use nsISecretDecoderRing instead

let's leave fixing up the prefnames aside, its probably better, but I'd want to
see what's already using these prefs before I change them

I'll attach a patch to bug 194141 separately, since it'll need separate review
anyway.

Comment 13

[Daniel Veditz [:dveditz]]

Comment on attachment 190517 [details] [diff] [review]
use nsISecretDecoderRing instead

r=dveditz

Comment 14

[Mike Connor [:mconnor]]

Attachment: add accesskeys

Barring beltzner-feedback, this is what'll go in ASAP, the other stuff is not
strictly blocking the branch, but I will get a patch in for that before beta.

Comment 15

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #10)
> beltzner, is there something better than "Login Sessions" to use here?

I'm afraid that "Login Sessions" will be easily confused with remembering
cookies (which are sometimes used to persist "logins") and/or passwords.
Assuming that I'm reading this right, what we're doing here is clearing the
cached SSL connections, which we present to users as "secure connections", and
we should probably make the label say that.

So, perhaps "Secure Connections"?

Using the Sanitize dialog verbiage ...

Clear the following items now:
   [ ] Browsing History
   [ ] Saved Form Information
   [ ] Saved Passwords
   [ ] Download History
   [ ] Cookies
   [ ] Cache
   [ ] Secure Connections

If I've misinterpreted, please let me know!

Comment 16

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: using "secure connections" label

Boy, I hope I did this right. Changed the label to "Secure Connections" and the
access key to "n" (presuming that there was some reason why "S" wasn't being
used for "Saved Passwords").

Comment 17

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: using "secure connections" label (small fix)

(sorry, the first character of the patch had gotten clipped for some reason)

Comment 18

[Nelson Bolyard (seldom reads bugmail)]

Suggestion:
Please change new pref name privacy.item.sessions to privacy.item.SSLsessions

Comment 19

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: using "secure connections" label and "privacy.item.SSLsessions"

Comment 20

[Mike Beltzner [:beltzner, not reading bugmail]]

mconnor pointed out that we're not just clearing SSL connections, but also HTTP
authentication connections, and that HTTP connections really don't qualify as
"Secure Connections". Really, what we want is "Logins that aren't actually just
cookies", but that's hard to encapsulate :)

Maybe "Authenticated Connections" or "Authenticated Sessions"?

Comment 21

[Mike Connor [:mconnor]]

checked in

Comment 22

[Bryan]

With the landing of https://bugzilla.mozilla.org/show_bug.cgi?id=191642 I've
added access keys to the Sanitize settings dialog (among others) and
consequently _S_ is already being used (_S_anitize Deer Park on shutdown).  Can
someone please change the accesskey for "Authenticated _S_essions" to
"A_u_thenticated Sessions"?  If this isn't done the accesskey for "Authenticated
_S_essions" will be broken (Currently is).  :-(

Comment 23

[Julien Gilli]

I tested the last attachment with firefox Deer Park on a debian Linux box (I
applied the patch with patch -p0 < file.patch in the mozilla source directory)
and it seems not to work.

I accessed an HTTPS resource, then chose the certificate to use in the popup
window. After that, I just had a look around the website (every resource access
uses HTTPS) and then, I pressed ctrl + shift + del and left only "Secure
connections" checked. Then I clicked "sanitize now" and then clicked on a link
of the website (which uses HTTPS too). The popup window that allows me to choose
the certificate to use did not pop up.

Have you tested the attached patch ? If so, does it work for you ?

Thank you very much for your work !

Comment 24

[Daniel Veditz [:dveditz]]

This is not really clearing the SSL session cache if bug 194141 is not fixed yet.

Comment 25

[Daniel Veditz [:dveditz]]

Also see comment 22

Comment 26

[Julien Gilli]

Seems to work fine when applying both the last attachment to this entry and the
one from 
bug 194141. I'll use a patched version of Deer Park from now on to report any
bug if I find one.

Thank you very much !

Comment 27

[Kadir Topal [:atopal]]

Hmm, as translator I've a tough time to translate this item. Actually even I
didn't know what it meant, before reading this bug, so how are regular people
supposed to decide whether they want this to be checked or not? All the other
items in the list are well known things, like: 'Browsing History', 'Saved
Passwords' or 'Cookies'. Only 'Secure Connections' stands out. Can we at least
find a better wording for this action?

Comment 28

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #27)
> Passwords' or 'Cookies'. Only 'Secure Connections' stands out. Can we at least
> find a better wording for this action?

mconnor and I went around on this a few times, and the current choice of
"Authenticated Connections" was deemed to be the best balance between expressive
and comprehensible. Of course, this isn't something that the average user is
really going to be able to understand - nor should the average user really care.
 (Sometimes makes me wonder why we have it in the sanitize options as opposed to
buried deeper in the UI)

We need to make it clear that all the function is doing is erasing any
remembered authentications from this session. It doesn't: delete cookies,
certificates or stored passwords.

Other potential labels:
  - Authentications
  - Secured sessions
  - Security tokens
 
Suggestions welcome.

Comment 29

[Kadir Topal [:atopal]]

(In reply to comment #28)

> Of course, this isn't something that the average user is
> really going to be able to understand - nor should the average user really care.
>  (Sometimes makes me wonder why we have it in the sanitize options as opposed to
> buried deeper in the UI)

You are absolutely right, this is something that at most maybe 2% of our users
will ever want to do and the sanitize panel is a really way too much exposed
place for an item, which 98% of the regular users may not even undestand. And
correct me if I'm wrong, but isn't it pretty bad design to add an item to the
UI, which even advanced users of your software are not supposed to understand?
No offense meant, but if we move it to the security tab in the advanced panel
(to where it belongs anyway imho) we could add a description, explaining the
action it does.

Comment 30

[Julien Gilli]

I agree with you. Nevertheless, I think that it's important to be able to access
this functionnality through a keyboard shortcut.

Comment 31

[spam.mozilla.org]

Can someone please explain what clearing "authenticated sessions" does. i need
this info to help with an update to my "master password timeout" extension.
perhaps you could explain the feature with an actual example?

Comment 32

[Kadir Topal [:atopal]]

I wish you'd do something about it. We already get a lot of questions, what this
option does. It's something no normal or even advanced user knows about. I don't
want to repeat myself, but I still think it's a bad UE decision to put an item
on a highly visible panel, which is not supposed to be used or (even worse)
understood by maybe 95% of your users.

Comment 33

[Julien Gilli]

(In reply to comment #31)
> Can someone please explain what clearing "authenticated sessions" does. 

It terminates the current SSL session so that a new SSL handshake will occur the
next time some data is exchanged over a network connexion that uses SSL.

> perhaps you could explain the feature with an actual example?

Some PKI implementations use several different client certificates to complete a
task (for example, enroll a user). To complete each steps without this feature,
you need to restart Firefox each time you need a different client certificate.

Comment 34

[Kristian Kraljic]

Why was this put to RESOLVED FIXED? As far as I can tell, there is still no method to clear to purge the SSL Session. This is a request is for parity with the issue at Chromium https://bugs.chromium.org/p/chromium/issues/detail?id=90454 and very similar to https://bugzilla.mozilla.org/show_bug.cgi?id=287957.

Comment 35

[Justin Dolske [:Dolske]]

Kristian: please find/file a new bug: this bug is more than a decade old, and it's not useful to continue here.

(It is weird that what got fixed here isn't what the bug was filed about.)