314695 - unnecessarily prompts for smartcard PINs

Status: RESOLVED DUPLICATE of bug 326637

(NSS :: Libraries, defect, P2)

Description

[bill]

Saw this in FireFox 1.5 beta 1, still present in FireFox RC 1.

Steps to reproduce:
- insert your smartcard
- start FireFox (which already has the security module for the smartcard installed)
- go to any SSL website (e.g. https://www.amazon.com)

Actual result:
- you are prompted for the master password for the smartcard before ANY HTML is rendered
- if you enter your smartcard PIN correctly, the browser window is then rendered.

Expected result:
- the SSL webpage is rendered (since your smartcard certs aren't required for SSL server auth)

Comment 1

[bill]

This is a really annoying bug and it's bad security hygiene to prompt for a credential that your program doesn't actually use.

This bug is still present in BonEcho and my smartcard users are complaining.

Comment 2

[Kai Engert (:KaiE:)]

Hi Bob, do have have an idea why NSS unnecessarily prompts for the smartcard password?

I can reproduce the bug with latest NSS_3_11_BRANCH, either firefox or seamonkey.

Attaching text file that shows the call stack of initial unnecessary prompt.

Comment 3

[Kai Engert (:KaiE:)]

Attachment: call stack

Comment 4

[Kai Engert (:KaiE:)]

The problem is,
- NSS decides it needs to verify some cert during the SSL connection
- NSS decides it should look at all tokens to see whether they have a CRL stored
- NSS looks at each token and decides, the CoolKey is "unfriendly", i.e. you can only look at it and find what it has stored, after authenticating to it

As NSS wants to look at the token, and CoolKey is unfriendly, it forces to login.

I guess a workaround is to not search SmartCards for CRLs, but is that what we want?

Is it common practice that SmartCards store CRLs?

Comment 5

[Bob Lord]

-> rrelyea

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Adding Mr. CRL to the cc list.
I think we're seeing so much commotion about this that we must 
resolve this soon.  

The biggest issue is going to be defining "unnecessary".  

I think the answer lies in defining "friendly" to include 
being able to search CRLs (not only certs) when the user is 
not logged in.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Another possible solution (?): 
only search friendly tokens and logged-in tokens for CRLs.  

Storing CRLs in tokens is not all that common, but I wouldn't say that only 
NSS soft-tokens do that.   If we disabled that feature (e.g. in browsers), 
I don't think we could say that only NSS softoken users would find that 
their CRLs are no longer being examined.

Comment 8

[Julien Pierre]

I don't have access to any smartcard to test this problem with anymore, so this makes the problem more difficult to track. But I will try to review the code changes in NSS 3.10 . There were a lot in the CRL area, about 2000 lines worth, but they were all reviewed. I guess something fell through the cracks. The first place to look at if you have a test case is pk11_RetrieveCrls in pk11nobj.c . This uses pk11_TraverseAllSlots . Bob, how do we make sure this traversal doesn't force a login if the token is friendly WRT certs/CRLs ?

Comment 9

[Robert Relyea]

We looked at this a while ago and found it was a change from one call to the traverse call. I tried to look at the diffs today, but find the particular change. (I was looking in pk11cert.c). The code change happenned between NSS 3.9 and nss 3.10.

bob

Comment 10

[Robert Relyea]

I believe this bug is related to 326637. It may be the exact same issue.

bob

Comment 11

[Robert Relyea]

Making it linkable: bug 326637

Comment 12

[Chandrasekar Kannan]

I tried the following with the FF 2.0 beta1 build.

1. inserted enrolled coolkey
2. launch FF 2.0 beta1 build ( windows xp )
3. visit https://www.wellsfargo.com

I don't see the prompt for the 'master password'. 

Comment 13

[bill]

I confirm that this issue seems resolved now.  Thanks!