122255 - connecting to SSL website causes NSS to query smartcards for root certs...takes too long

Status: RESOLVED FIXED

(NSS :: Libraries, defect)

Description

[bill]

using Netscape 6.2.1 RTM with ActivCard Gold and Schlumberger Palmera Access
JavaCard.  The smartcard stores my personal certificates.  When I go to an SSL
website for the first time since launching browser the initial connection takes
upwards of 5-10 seconds to complete the handshake.  During that time NSS is
querying the smartcard (presumably for root certificates to match the signer of
the website).  In some cases this takes so long that the browser doesn't
actually go to the SSL site and I have to re-click on the SSL link to make it
connect.  This retry happens much more quickly.

suggested behavior:  if NSS finds a valid root certificate that signed the web
server's certificate, NSS should stop querying other PKCS#11 tokens since
hardware tokens tend to me slower than the built-in token.

Comment 1

[Ian McGreer]

this is due to bug 121628

Comment 2

[Wan-Teh Chang]

Ian,

Should I mark this bug as a duplicate of bug 121628?

Comment 3

[Ian McGreer]

Well, bug 121628 is sort of the broad solution, but I've been marking bugs as
dependent on it instead of dupes.  We should go through the various hardware
tokens and test them before marking the bugs fixed.

Note that this bug popped up in Netscape 6.2.1, which is not using NSS 3.4.  NSS
3.4 *should* fix this bug, but it may not given that the bug existed in an
earlier version of NSS (bug 121628 tries to bring back behavior that was once
there, not add new behavior).

I was incorrect when I said, "This is due to ...".  I should have said, "This
should be fixed in NSS 3.4 by ...".  The methods used to chain a cert in 3.4 are
such that the token should not be queried for a root, but I don't think we
should mark this bug as a dupe until we have actually tried it.

Comment 4

[Wan-Teh Chang]

Bob, Ian,

Should we target this in NSS 3.4.1?

Comment 5

[Ian McGreer]

This bug was dependent on bug 121628, which was fixed.  Therefore, this bug
*should* be fixed, but I'm hesitant to mark it so until the test case is retried.

If it isn't fixed, I think it should be targeted for 3.4.1.  It is not a regression.

Comment 6

[Wan-Teh Chang]

shadow: could you use a Mozilla daily build produced
after 2002-02-07 (which has the new NSS 3.4) and retry
your test case?  Thanks.

Comment 7

[Wan-Teh Chang]

Changed the QA contact to Bishakha.

Comment 8

[Wan-Teh Chang]

shadow, are you still having this problem with Mozilla 1.0 RC2
or Netscape 7.0 PR1?

Assigned the bug to Bob.

Comment 9

[bill]

I don't see this behaviour anymore in MachV builds.
- If the smartcard is inserted in the reader when visiting an SSL site the card
is queried for about 5 seconds before the page loads, but it loads correctly.
- If the smartcard is NOT in the reader when visiting an SSL site, the card is
not queried and the SSL negotiation happens more quickly.

But I don't see the errors I reported before.

Comment 10

[Robert Relyea]

Does the second page load with the smart card inserted happen more quickly (the
5 second delay is on first smart card reference).

bob

Comment 11

[Wan-Teh Chang]

Marked the bug fixed in NSS 3.4.

Comment 12

[bill]

yup...subsequent pages loads (to other sites as well) happen much more quickly
after the first load.