Closed Bug 249393 Opened 20 years ago Closed 19 years ago

Invalid handling of smartcard based client certificates if smartcard contains more than one certificate

Categories

(Core :: Security: PSM, defect)

x86
Windows 2000
defect
Not set
major

Tracking

()

RESOLVED EXPIRED

People

(Reporter: Ulrich.Lohrmann, Assigned: KaiE)

Details

(Whiteboard: [sg:nse])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.7) Gecko/20040626 Firefox/0.9.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.7) Gecko/20040626 Firefox/0.9.1

We use Firefox with a webserver that requires client authentication. We have
smartcards that contain 2 certificates: one for authentication and encryption,
one for digital signature. In Tools-->Options-->Advanced-->Certificates-->Client
certificate selection we have selected "Select Automatically".
If I connect to the webserver that requires client authentication, Firefox
selects the client certificate "authetication and encryption". After the PIN has
been entered, I can access the content of the webserver. Now I wait a little bit
(> 30 sec). If I then click an arbitrary link the webserver requires the client
again to authenticate but then Firefox passes the other certificate that is
stored on the smartcard (the "Digital Signature") certificate.

Reproducible: Always
Steps to Reproduce:
1.Need a smartcard with a least two certificates
2.Connect to a webserver that requires client authentication
3.Let Firefox select the client certificate to be used automatically
4.After acessing the secured content, wait a little bit
5.Change the current page and check, whether or not the webserver requires
client authentication again. If not, just wait a little longer

Actual Results:  
During the first time, the webserver requires client authentication, Firebox
passed the correct certificate (the one designed to be used for client
authentication). The second time the webserver requires client authentication,
Firefox might pass the other certificate from the smart card.

Expected Results:  
Use the same certificate for client authentication every time.

To me it looks as if this is a problem that has to do with caching of client
certificate information.
The first time the webserver requires client authentication, everything works
fine. After accessing the secured content and waiting a little bit, the
webserver requires the client to autheticate again and Firefox accesses the
certificates on the smart card again. But then the Browser does not take the
certificate used during the first authentication but takes the first certificate
on the smart card.  Whether or not this is the same certificate used during the
first client authentication is arbitrary.
If I switch the browser configuration to ask the user which client certificate
has to be used, Firefox preselects the "authentication and encryption"
certification when the webserver requests client authentication the first time
and preselects the "Digital signature" certificate when the webserver requires
client authentication the following times.
I assume Mozilla behaves the same? I can't think of any Firefox-specific code
for smartcard handling. Please check in Mozilla, because if we can assign it to
the right component (PSM or NSS?) it's more likely to get fixed.

I don't see a security exploit here -- website can't control which cert it gets,
and in any case it's only getting the public part. Any reason I shouldn't clear
the "confidential" flag?
Whiteboard: [sg:needinfo]
The behavior is the same with Moziall as well as with Netscape.

If you don't see a security problem here you can clear the "confidential"
flag
-> PSM (though possibly NSS does this?)

Clearing security flag, this is a bug not an exploit.
Assignee: firefox → kaie
Group: security
Component: General → Security: PSM
Product: Firefox → Core
QA Contact: general
Whiteboard: [sg:needinfo] → [sg:nse]
Version: unspecified → Trunk
Bob will want to see this!
Hmmm... the problem is that you have ambiguous certs. Any cert that can be used
for Digital signature is accepted as an SSL client auth cert. If you have 2 such
certs that are signed by the same CA, Firefox can't tell which cert to use. If
you turn off 'select automatically', then you should see both certs in the
selection box (Firefox automatically filters certs that don't match the
requirements of the Server). When using select automatically, either cert may be
used.

I'm assuming (it's not clear from the description) that you are going back to
the same website), and the two certs are signed by the same CA (or at least some
CA in the list of CA's that the server accepts for client auth). If that's not
the case,  then it's highly likely that Firefox is selecting a different cert
because the server is asking for a different CA.

Finally, I'm wondering about interactions with the smart card. I have tokens
with have multiple valid signature certificates, and while it's arbitrary which
certificate is going to be selected, I've never seen firefox change it's mind
about which certificate to use. On the other hand I don't see how it could be a
smart card issue since NSS reads all the certs out of the token and caches them
on the initial insert (unless the token itself acts like it's been 'removed' and
then changes the order the certificates are presented).

Anyway there is a basic problem depending on Ask Only if you have one of these
ambiguous situations. I see a potential RFE to have firefox sort auth Signing
certs (ones without the 'repudiation' bit) over ones with the non-repudiation
bit... but I could also argue Firefox should prefer 'pure signing' certs over
ones that do encryption.

bob
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
Based on Bob's comment 5, we should have a better resolution
for this bug than EXPIRED, but ...
You need to log in before you can comment on or make changes to this bug.