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)
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.
Comment 1•20 years ago
|
||
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
Comment 3•19 years ago
|
||
-> 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
Comment 4•19 years ago
|
||
Bob will want to see this!
Comment 5•19 years ago
|
||
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
Comment 6•19 years ago
|
||
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/
Comment 7•19 years ago
|
||
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
Comment 8•19 years ago
|
||
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.
Description
•