164258 - SSL Session reuse does not work with smart cards

Status: VERIFIED WORKSFORME

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

Description

[Markus Bitterli]

We found a problem accessing web sites which ask for client authentication with
certificates. As long as the certificate is one which is stored directly within
PSM everything works fine. But as soon as the certificate and the corresponding
key is stored on a smart card session reuse is no longer supported. That leads
to the effect that for every frame, picture or whatever object on a web page the
SSL handshake is done from scratch. This can easily be detected if you set the
certificate security preference "Client Certificate Selection" to "Ask every
time". This behaviour leads to a huge performance problems.

Comment 1

[John Unruh]

Adding an in-house test URL. Get the cert here
https://lab212sun.mcom.com:444/DirUserEnroll.html

Comment 2

[Stephane Saux]

I have certs on an ActivCard and I use ask everytime, and I use a 1.0 branch
build, and I visit SSL client-auth-only sites a thousand time a day, and I would
die if the software did that. It's either card specific or the server has a problem.

Comment 3

[John Unruh]

Reporter, what build are you using? With today's build, I'm not seeing a 
problem. This in-house client auth site downloads 100 gifs in under 3 seconds - 
https://pki.mcom.com:6007/color/color.html . The cert is on an iButton. 
Get the cert here. https://lab212sun.mcom.com:444/DirUserEnroll.html

Comment 4

[Kai Engert (:KaiE:)]

Markus, what are your cache settings?

Comment 5

[Markus Bitterli]

The cache setting is on "When page is out of date", but the effect is the same
if I set it to "Never". If just reproduced it with the just released 1.1 version.

Comment 6

[Markus Bitterli]

I have as well a debug version of the PKCS#11 software which writes out all call
made by Mozilla. Unfortunately I do it not understand but perhaps some of you do.
Since the trace is quite big (uncompressed 3018KB, zipped 448KB) I can't load
them up. If somebody is interessted I can mail it.

Comment 7

[Robert Relyea]

Yes, send it to [e-mail] and I'll take a look.

Since this function works correctly with the tokens we have here, my guess is
there is something your token is doing to make SSL think that that your token
has been removed. When you are doing client auth, SSL checks to make sure the
token that the client certificate came from is still attached (hasn't been
pulled out and reinserted). This is so we will stop future connections which are
authenticated with your smart card cert once you pull your card.

NSS detects that your card has been pulled by examining the state of the
'primordial session'. That is the session NSS creates on your token when it
first detects initializes your token. If that session suddenly becomes invalid
(that is getSessionInfo on it fails), then NSS will assume that means the card
has been pulled from the slot. If there is a card in the slot, NSS will then
reinitialize it's data structures relating to the card (because it could be a
different cards).

Look to see if your are failing C_GetSessionInfo() and why.

bob

Comment 8

[Markus Bitterli]

Thank you very much for the information. I will try to sort out whether this is
the problem. Unfortunately this will take some time since I've no direct contact
to the responsible developer of the PKCS#11 module.
So far I was quite sure that the problem is within the Mozilla software since it
works without any problem with the Netcape 4.x Browsers.

What I see in my log file is that the content of the token is read many times in
for doing even the first SSL handshake.

What our token distinguishes from others is that it tells Mozilla that it has no
PIN to open. This task is completely done with the token's own software.

Markus

Comment 9

[Robert Relyea]

Actually working with Netscape 4.x is not a good determiner of compliance with
the PKCS #11 spec. 4.x did not use as many of the PKCS #11 features as mozilla
does, so subtly broken PKCS #11 devices which worked in 4.x may not work in mozilla.

Also 4.x had a bug in this area. It did not check for card removal, so you could
log into a web site and pull a card and not get prompted again, so problems in
this area would not be noticed by your driver even if it was faulty.

If you token never requires login, it would be quite easy for it to appear to
work correctly even it it has always failed the C_GetSessionInfo() check. The
only way to detect the failure is either to notice excessive password prompts
(which won't happen in your case), or to notice some performance degregation
(which this bug reports).

bob

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

I just found out about this bug today.  I wonder how many other SSL bugs
I've never been CC'ed on.

What is the status of this bug?  
Did the submittor ever send the 1/2 MB zip file to relyea?  
What did it show?

Comment 11

[Robert Relyea]

No, I quick search of my mail shows no mail from ubs.com (3 months is an
eternity to remember). 

I am surprised no one CC'd nelson, though this bug appears to be primarily token
related. I haven't seen this problem with other tokens, though ubs may be doing
something different but acceptable that could be triggering this error.

Marcus did my previous comments help you resolve this problem?

bob

Comment 12

[Markus Bitterli]

Yes, your comments helped a lot. After presentign them to our PKCS#11
implementor and some testing they developed a new one which now works fine.

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

Marking WORKSFORME, based on the submittor's comment above.

Comment 14

[John Unruh]

verified