Closed Bug 94557 Opened 23 years ago Closed 22 years ago

Password Manager/Logout does not clear authenticated https sessions with http keep-alive

Categories

(Core Graveyard :: Security: UI, defect, P1)

Product:
Core Graveyard
Component:
Security: UI
Version:
1.0 Branch
Platform:
x86
Windows 2000
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
psm2.4

People

(Reporter: lord, Assigned: KaiE)

References

(Blocks 1 open bug,
URL
)

Details

Attachments

(2 obsolete files) 

The Logout button does not seem to work.  

When visiting a client-auth site, the client asks which cert to use.  I select
Password Mananger/Logout.  Then I try to re-access that web page.  I *should* be
asked for the cert again, but I'm not.
Priority: -- → P1
Target Milestone: --- → 2.1
->javi
Adding aka.mcom.com as URL test case.

I also tested that if the cert is in a hardware device, then loging out of that
still allows me to go to aka.mcom.com without its requesting the cert again.
Assignee: ssaux → javi
URL: aka.mcom.com
Note that aka reverts to asking you your name/pwd if you don't have a cert to
present. This shouldn't affect the behavior, but it may help exercise the bug.
Keywords: nsenterprise
wtc just updated the NSS_CLIENT_TAG and I still see this behavior.  This looks
like an NSS bug.

Our client auth data hook gets called the first time we visit the site then
never again.

necko creates new sockets every time we visit, but NSS doesn't call us to pick a
cert.  So we'll need NSS help on this one.

BTW, the token is logged out.  If I then try to do SSL/IMAP, I do get prompted
for the password to my token.
I believe there were 2 bugs in NSS affecting this:
1) The code that made sure the token was still present didn't check to see that
we were still logged in.
2) The SSLv2 code didn't check to make sure the session was still valid like the
SSL v3 code did.

I'm going to attach a patch that fixes those problems.

This doesn't fix the problem for 100% of the cases.  It seems that the page is
cached, so the page will get laid out from the cache even with the forthcoming
patch attaced.  If you then go and clear the memory cache from the preferences
dialog and then try to re-connect, you will get re-prompted for you cert db
password.
adding wtc to cc list.
When did we start supporting SSL2 client auth? It was never supported in native
SSL2 clients (which is why the SSL2 coded does do the client auth checks on
restart).

bob
That's a good question.  All I know is that when I stepped through the SSL code,
ssl_LookUpSID was being called from sslcon.c and not ssl3con.c

I just added the session validity check where the session was found.

I used https://aka.mcom.com/ for testing.
Ah, OK I've found out why we call ssl_LookupSID in the SSL2 code. If ssl2 is
enabled, we always call the ssl2_BeginClientHandshake(). If we have a cached SID
for this session, we check to see if we were talking SSL3, and call the
ssl3_SendClientHello(). Note the comment below just before we call lookup:

   /* We ignore ss->sec->ci.sid here, and use ssl_Lookup because Lookup
     * handles expired entries and other details.
     * XXX If we've been called from ssl2_BeginClientHandshake, then
     * this lookup is duplicative and wasteful.
     */
    sid = (ss->noCache) ? NULL
            : ssl_LookupSID(&sec->ci.peer, sec->ci.port, ss->peerID, ss->url);

So the effect of javi's fix will be to uncache the sid on the SSL2 side before
we get here. This means the restart will issue an SSL2 Hello instead of an SSL3
Hello. It will still work, but I think it would be better to simply add the
isLoggin() test on the SSL3 side. Be sure to add to the above comment that if we
were to try to reuse the side looked up from ssl2_BeginClientHandshake, we would
still have to check for smart card removal.



adding some necko folks to cc list.  The attaced patch will fix an NSS bug that
didn't cause the user to get prompted for a password, but unless the memory
cache is cleared, the NSS code doesn't get called again to do another network
connection.

How can we handle the case where the lower layer wants to clear some data out of
the cache?
patch looks good;). r=relyea
javi: there isn't much support for that... perhaps you could describe the
circumstances under which the page is being reaccessed.  is it via back/forward?  

perhaps Logout could flush matching HTTPS cache entries.
Here is the scenario:

1) User visits a web site that requires a client side certificate for access. 
(User logs into his/her cert db) https://aka.mcom.com/ is such an internal site
(when it's accessible).

2) The user sufs some pages.

3) The user logs out of his/her cert db.  

4) The user goes back to the page in step 1.  

What happens:
The page loads without asking to log-in to the certificate db.

What should happen:
The user is asked to log back into his/her cert db since he/she is no longer
logged in and a certificate was required.

With the attached patch, the NSS portion of this is fixed.  But I still have to
go to Edit->Preferences->Advanced->Cache and clear the memory cache to see the
NSS fix get exectuted.

If there is a way to say, don't cache this page, that would work as well.  That
way in the client auth callback, we could in effect say "don't cache this page."


when you say: "The user goes back to the page in step 1" do you mean via the
Back button?  or do you mean via some link click?
I've been typing the URL in a new window and/or doing shift reload.  
The NSS patch has been checked in, we just need to decide what we're going to do
about any necko caching issues.
 setting to future. It's unlikely that a good solution to the caching problem
can safely be implemented in the 0.9.4 timeframe.
Target Milestone: 2.1 → Future
Keywords: nsenterprise+
QA > junruh
QA Contact: ckritzer → junruh
Version: 2.0 → 2.1
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9+) Gecko/20020306

After logging out of password manager, Moz Mail still checks my POP3 account. It
should not be able to do this; it should not be able to access my POP3 password
now that I have logged out of the password manager, hence not check mail.

This was noticed monitoring traffic on my router once I had logged out of the 
password manager.
Keywords: nsbeta1
We still have this bug.
Keywords: nsbeta1 → nsbeta1+
-> me
Assignee: javi → kaie
In this bug, multiple disucssions occurred. I'll try to summarize where we are.


When doing Password Manager / Logout, the result is only partial.
My current testing shows:
1) I am indeed logged out for certificate database operations, when I try to
delete a personal cert, I am prompted again
2) using SSL client authentication is still working
3) cached pages can still be displayed

So,
- 1) works correct
- 3) there is not much we can do about that. I generally thought that https
pages would never be cached. But that is definitively a separate bug, and should
not be handled here, IMHO.


As a result, I think we can concentrate on the client authentication issue.

It was said the patches from this bug have landed long time ago, therefore I
will mark them as obsolete.


I just retested with the mentioned corporate internal site at https://aka.mcom.com

- I can access the start page.
- next, I used Password Manager / Logout
- I clicked a link on aka, a link I had not previously accessed in that session.
It worked. I was served the request.


It seems the NSS issue is not yet fixed.
I believe that NSS still remembers everything that is required to communicate
with the site, and is continuing to do so, ignoring the fact that a logout had
been requested.

Is it possible that NSS/SSL is using some kind of session cache for SSL
connections, which does not get flushed when we call the NSS logout function?
Blocks: clientauth
Attachment #46485 - Attachment is obsolete: true
Attachment #46794 - Attachment is obsolete: true
Check with Nelson, but the SSL session cache probably needs to be cleared when
you do a logout. nss/lib/ssl/sslnonce.c:SSL_ClearSessionCache(void)

Kai, Can you repeat your AKA test but after you log out from the SSD, you should
wait for 10 seconds until you click on a link.

Also you're using the Tools->pwd mgn->log out thingy.

See if it makes any difference if you use the device manager to log out of the
device.

I've tested that with my ActivCard, when I log on to AKA, and then use the
device manager to log out of my ActivCard, and wait for a few seconds (10), then
when I click I do a full SSL handshake (I'm asked to enter the pwd for the AC,
pick a cert, etc...).

Whenever libSSL tries to restart an SSL session on which client 
authentication had previously been done, libSSL attempts to check that the 
PKCS11 token that was used for the authentication is logged in, and has not 
been removed (or reinserted).  This test is only done when doing an SSL 
handshake.  I'm not aware of any other tests to see if the token is still 
logged in.  (Relyea, are you?)

I do not know if this will detect a case where the user logged out and 
then logged back in again.  

If an SSL connection stays alive for a long time after the last handshake is 
done, a logout of the token might not be detected for that SSL connection,
so it is posible that an IMAP connection that was established before the
logout would continue to work afterwords.  Flushing the SSL session cache
will not solve this problem, because the cache is only used when a handshake
is done.  

> Check with Nelson, but the SSL session cache probably needs to be cleared when
> you do a logout. nss/lib/ssl/sslnonce.c:SSL_ClearSessionCache(void)

As per Nelson, I didn't try.


> Kai, Can you repeat your AKA test but after you log out from the SSD, you should
> wait for 10 seconds until you click on a link.

10 seconds does not seem to be enough.
But after about 30 seconds, I'm indeed prompted to select the cert and enter my
SSD password again.


> Also you're using the Tools->pwd mgn->log out thingy.
> See if it makes any difference if you use the device manager to log out of the
device.

It does not make a difference.


I think one should not be required to wait 30 seconds without using SSL to
guarantee one is indeed logged out.

How could this be done? Is there a way to instruct SSL to re-require handshakes
immediately?

But in addition, IMAP seems to keep its sockets open continously.
Could/Should we force SSL to bring down all its open sockets?
Nelson is correct. The current check only checks if the token which the cert was
stored is logged in or out, or was the token inserted or removed.

Perhaps a better check would be does the key for the cert still exists. Looking
at the SSL code, it looks like that could be a problem since we don't actually
cache the cert we used to authenticate. We could cache a KeyID of somekind.

I think the best way to solve this problem is replace all the series,
isPresent(), and isLoggedIn with a key lookup.
Target Milestone: Future → 2.4
I looked into this more. Our "problem" is caused by the HTTP keep-alive
networking option. If I disable the keep-alive option, this bug can no longer be
reproduced.

When keep-alive is used, HTTP has idle connection objects, and those objects
have NSS resources assigned to them. The NSS/SSL objects in memory have
remembered state information that enable them to do further SSL activity without
requiring another handshake.

I think, a correct approach would be to find out the list of such open
connections and close them.

Since PSM does I/O layering, PSM could maintain the list of currently open SSL
sockets. When PSM receives any request to log out of any token, it should mark
all its currently open sockets as being "broken".

While we currently only know about https showing this behaviour, I suggest it is
safer to generally bring down all SSL connections, in case other protocol code
should try similar behaviour in the future.

Darin, what do you think would be easier, which of the following options would
you prefer?

PSM could mark its own sockets as being broken, and produce a failure on the
next attempted read or write. (In case you prefer this solution, do you want to
suggest the failure return code?)

Alternatively, PSM could try to find out the fd's for all its SSL sockets, and
instruct Necko to shut them down.
Summary: Password Manager/Logout is broken → Password Manager/Logout does not clear authenticated https sessions with http keep-alive
so what you're basically proposing is to disable keep-alive for HTTPS
connections?  please tell me i'm misunderstanding you ;-)
You misunderstood me :)

I want a way to explicitly bring down all kept alive HTTPS objects, but only
when the user requests to do so.

ok, sorry about that.  i see what you're after.  perhaps the solution is to add
a new event type that nsHttpHandler::Observe could listen to that would cause
all the https connections to be dropped.  like the network-teardown, but maybe
"https:teardown" or something like that.  this would avoid having to introduce
some new interface.
What if the connection is currently in use? For example, we could be downloading
a file while this happens, and so on.

Do we want to drop immediately, or after the current request finishes? I do't
think we want to wait for all the requests in a piplining case, though.
bbaetz: we can mark the connections as not keep-alive and they will go away once
they are done with whatever they are doing.  as for the pipelined case, i'm not
sure it matters that much if we wait for the current pipelined requests to
finish or if we pre-empt them.  doesn't seem worth it to try to pre-empt them.
Bug 177260 has a patch that tries to eliminate leaks in PSM, and it extends PSM
with a capability to track all of its open wrapper class instances that hold
references to NSS objects.

I have changed my opinion how this bug should get fixed.

When the user requests the security logout, PSM should iterate over all open SSL
connections, and make them fail at the next I/O event.
Depends on: 177260
*** Bug 177319 has been marked as a duplicate of this bug. ***
It has become unclear whether we will use the
track-everything-and-shutdown-early approach in bug 177260, therefore we might
need to use a different approach. But leaving the dependency on 177260, to
remind us to revisit the problem once we have fixed it.

Fixed.

After you have selected logout, no additional bytes will travel over
authenticated connections, but a communication failure will be enforced at next
attempt (lacking a way to close the connection from within the crypto module).
Fix was part of the patch for bug 189205.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Reopening. Logout doesn't prevent me from re-entering aka.mcom.com. I don't need
a  name and password to enter aka after logging out. Client auth also does not
require my cert after entering a client auth site, logging out, and re-entering
the site.
Get a cert here - https://pki.mcom.com:1025/ca/DirUserEnroll1024.html
Test client auth here - https://pki.mcom.com:6007/tests.html
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
John, it seems to work for me on aka.mcom.com using a linux build.
Does it work for you on Linux, i.e. is this a problem on Windows only?



I tried Moz Win2000, Netscape 7.01 OSX, plus Moz and Netscape 7 on Linux - all
Jan 29 builds.
1.) Visit aka.mcom.com, entering your name and password.
2.) Visit another site.
3.) Logout of your master password. Tools>Password Manager>Logout.
4.) Click OK on the confirmation dialog box.
5.) Visit aka.mcom.com
What happens: I go right to https://aka.mcom.com
I believe I understand now why we see different results, I suspect we are
talking about the different authentication mechanisms that aka.mcom.com supports.

I have only tested certificate based SSL client authentication.
I believe this was the problem reported in this bug initially.
John, could you confirm that client based authentication no longer works after
you have logged out? You must connect to aka using your corporate cert, but not
order a username/password combination, in order to test this.


In the steps you gave in your previous comment you say you are using password
based authentication.

I can confirm what you say. Indeed, logging out of password manager does not
clear the password you had previously entered in the same session to access the
web site, using http basic authentication.

I believe this is a separate bug in the "password manager" component.

right, without a cert, the browser will do HTTP basic auth, and the username and
password you entered will be stored in HTTP's auth cache.  the auth cache has
nothing to do with PSM.
Thanks, Darin. Maybe we should file a separate bug about flushing the auth cache
when logging out of the password manager.

Darin, can you file the bug from comment #43? 
This time I used my AOL cert to reach aka.mcom.com. I logged in to aka, went to
another site, logged out of my master password, went to aka and had to select my
cert again.
However, for this to work, the cache setting must be on "Every time I view the
page", or else aka will reappear without asking for client auth again after logout.
Setting back to fixed.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Verified.
Status: RESOLVED → VERIFIED
OS: Windows 2000 → All
Hardware: PC → All
Version: 2.1 → 2.4
> However, for this to work, the cache setting must be on "Every time I view the
> page", or else aka will reappear without asking for client auth again after
logout.

Oops? We are caching https content?

junruh, kai: see bug 160482 which was marked a duplicate of bug 55181.
OS: All → Windows 2000
Hardware: All → PC
Version: 2.4 → 2.1
kai: yeah, we cache HTTPS content in the memory cache.  we follow all server
specified cache directives to limit the lifetime of the cache entries.
Product: PSM → Core
Version: psm2.1 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: