196399 - Use of PKI certs via eToken/epass2000 lead to a session termination for SSL access to a page

Status: NEW

(NSS :: Libraries, defect, P2)

Description

[Katsuhiko Momoi]

** Observed with Mozilla 1.2.1, 1.3b but NOT with 1.0.2 **

This report comes from a Japanese user whos uses eToken and ePass2000
along with Mozilla. These devices were working well with 1.0.2 but
there is a problem as described below with the recent builds.

Problem: When accessing PKI certs via eToken or ePass2000 with Mozilla, 
         if Mozilla accesses a page with SSL, the page is not displayed
         and instead the session is terminated.

I talked to thayes today and he said that there were recent changes to
NSS to fix some problems and that may have to do with this problem.
Needs to set up a test case.

The original Japanese bug is filed below -- in Japanese. I will contact
the original filer for more details.

http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=2989

Comment 1

[Katsuhiko Momoi]

CC'ing thayes and relyea.

Comment 2

[Robert Relyea]

To be clear, there have been fixes in NSS that have been known to expose latent
problems in some vendor's PKCS #11 modules.

In order to debug this we would need some of these eTokens in house.

bob

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

There was a change in recent NSS (3.7.2, IINM) that requires the token used
to do SSL client auth to remain in a logged in read-write state in order for
the SSL session to remain usable.  If the token becomes removed, or is logged
out or no-longer in a read-write state, any SSL session that did SSL client
authentication with that token will become unusable.  This typically
necessitates performing another client authentication.

The usual manifestation of this is not a complete failure but rather is that 
the user is asked to reauthenticate to the server more often than desired.

Some tokens have the behavior that after you login to them and do a single 
signature (or other private key) operation, they immediately log the user 
out again.  This is intended to force the user to have to enter his password
every time he uses his private key.  Unfortunately, for NSS users, it also
has the effect of making their SSL sessions very very short lived.  This is
also an issue for tokens that logout users after a short fixed time, like a
minute or two.  I suspect that's what's going on with the tokens named above 
in this bug report.

We've had complaints about this in the mozilla crypto newsgroup.  Users have
asked that NSS be changed to actually detect token removal, and make the 
SSL session unusuable when the token is used, not merely when it is logged
out.  

This is a tough call.  As long as the only way to get a user to reauthenticate
to the token for every private key op is to log him out after each op, this
situation will continue to exist.  This seems like a limitation of PKCS 11.
But some PKCS 11 token users find NSS unusuable as it is now.  

Marking P2 because NSS's usability with hardware token devices is a hot issue.

Comment 4

[Robert Relyea]

Nelson, what do you mean by 'R/W' state? NSS only needs R/W sessions when the
token is loading new certs or generating new keys. SSL never requires R/W state,
and shouldn't require it now.

NSS does require that the token is present and logged in to continue an
*authenticated* SSL session. This is a request we got from users who are
surprised when their SSL sessions continued to function even when their token
has been removed.

Trying to reauthenticate on logout only is something I believe we can do pretty
easily, and seems reasonable. Doing so on token removal is a little harder.

Separate signing key passwords is a functionality that is not yet supported in
NSS. The PKCS #11 working group is still debating how to support this feature.
It's one of many things (like biometrics) that are not really supported in mozilla.

bob

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Please ignore my previous comment about R/W.  

How do we make SSL useable for users whose tokens return to a "public session"
state (a logged out state) immediately after each and every private key op?
That's the real issue facing this user, I believe.

Comment 6

[Katsuhiko Momoi]

Let me provide clarification from the original bug filer (in Japanese).
I am trying to find out more but the following info has been provided
so far.

1. After installing Mozilla, go download the eToken driver at:

http://www.aks.com/etoken/downloads/rte.asp

2. Open Preferences | Privacy & Security | Certificates | Manage Security
Devices    
     | Load
3. Choose the driver downloaed in step #1: e.g. c:\winnt\system32\eTpkcs11.dll

4. Import a personal certificate for yourself. e.g. 

   Preferences | Privacy & Security | certificates | Manage Certificates |
     Your Certificates | Import

5. When the user goes to a Client Authentication page using SSL, instead of
   displaying the page, the session is terminated. (Server authentication
   works but Client authentication does not. The user has a Client
   authentication page using openssl / apache 1.3.27+modSSL.)

   Note: Step 5 is where I am asking additional questions, e.g. if the filer
         can provide the URL to his Client Authentication Page, etc.

Comment 7

[Carsten]

The cert passphrase is never asked for. Empty screen is returned. Still does not
work with 20031130 build