Closed
Bug 624075
Opened 14 years ago
Closed 14 years ago
TLS client authentication fails with latest Firefox 4 nightlies (nsNSSIOLayer calling into PrefService off of the main thread)
Categories
(Core :: Security: PSM, defect)
Core
Security: PSM
Tracking
()
VERIFIED
DUPLICATE
of bug 624514
Tracking | Status | |
---|---|---|
blocking2.0 | --- | betaN+ |
People
(Reporter: guillaume.romagny, Unassigned)
References
()
Details
(Keywords: regression, Whiteboard: [hardblocker])
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 Build Identifier: Minefield 4.0b9pre 2011-01-07 Hello, I can do X509 client certificate login with www.cacert.org (in fact secure.cacert.org) with IE 8 and Firefox 3.6 (up-to-date) on Win7_64 but recently I just can no longer do certificate login with FF 4pre9. I have a valid CAcert.org certificate and all CAcert roots certs added in the keystore. I have tried the automatic cert selection or manual selection in FF4, I have checked I have a valid certificate in the keystore, FF4 no longer proposes to select a client certificate, so the login fails with : "Secure Connection Failed An error occurred during a connection to secure.cacert.org. SSL peer was unable to negotiate an acceptable set of security parameters. (Error code: ssl_error_handshake_failure_alert) The page you are trying to view can not be shown because the authenticity of the received data could not be verified. Please contact the web site owners to inform them of this problem. Alternatively, use the command found in the help menu to report this broken site." Have you reinforced SSL negociation schemas (dropped some old SSL protocols) ? Best regards, Guillaume Romagny Reproducible: Always Steps to Reproduce: 1. connect to https://secure.cacert.org/index.php?id=4 Actual Results: No way to select a client certificate then FF4 displays : Secure Connection Failed An error occurred during a connection to secure.cacert.org. SSL peer was unable to negotiate an acceptable set of security parameters. (Error code: ssl_error_handshake_failure_alert) Expected Results: X509 Client certificate login to the website.
Reporter | ||
Comment 1•14 years ago
|
||
I have tested with all plugins disabled. I don't understand why I have "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3"
Version: unspecified → trunk
(In reply to comment #0) > Have you reinforced SSL negociation schemas (dropped some old SSL protocols) ? Yes: bug 535649 comment 67 Time to apply http://www.debian.org/security/2011/dsa-2141 on the CAcert infrastructure.
Assignee: nobody → nobody
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Component: Build → Security: UI
OS: Windows 7 → All
Product: NSS → Core
QA Contact: build → ui
Hardware: x86 → All
Resolution: --- → INVALID
Version: trunk → Trunk
Reporter | ||
Comment 3•14 years ago
|
||
Thank you Kaspar, I will forward to CAcert sysadmin team to check.
Guillaume, it turns out that my conclusion in comment 2 was somewhat premature. After another look at this issue, I noticed that you were testing with "Minefield 4.0b9pre 2011-01-07", which happens to be one of the (first) nightlies where bug 585706 is becoming a real issue, in particular when it comes to using client auth. Upgrading the CAcert systems won't help with this particular problem, actually (but of course it doesn't hurt to apply the patches from DSA-2141).
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---
So, for the sake of clarity: it's separate from the issue in bug 585706 (which deals with nsNSSCertificateDB), and here's again the analysis, which I originally posted to that other bug: Note that after this commit here: http://hg.mozilla.org/mozilla-central/rev/d2856d5970b6 this is getting a real issue with PSM - it breaks TLS client auth, among other. Here's a stack showing what happens when NSS is calling PSM, to ask for a client cert: nsPrefService::CheckAndLogBackgroundThreadUse nsPrefBranch::GetCharPref nsPrefService::GetCharPref nsGetUserCertChoice nsNSS_SSLGetClientAuthData ssl3_HandleCertificateRequest [...] What happens is that pref->GetCharPref("security.default_personal_cert", &mode); in nsNSSIOLayer.cpp:nsGetUserCertChoice fails (GetCharPref returns NS_ERROR_UNEXPECTED), which means that nsNSS_SSLGetClientAuthData won't ever supply a client cert to NSS (irrespective of whether security.default_personal_cert is set to "Ask Every Time" or "Select Automatically").
Status: REOPENED → NEW
Component: Security: UI → Security: PSM
QA Contact: ui → psm
Summary: Impossible to do x509 client certificate login with recent Firefox 4 version (CAcert website) → TLS client authentication fails with latest Firefox 4 nightlies (nsNSSIOLayer calling into PrefService off of the main thread)
Reporter | ||
Comment 6•14 years ago
|
||
Hello Kaspar, the CAcert "critical system" team is usually pro-active regarding the patching of the Debian distros. I confirm FF4 does no longer request a certificate to login (whatever the option to select the cert manually or automatically)... I have tried to change the option like in bug 535649 comment 67 but *** I still fails ***. Your first review was quite logical : the initial negociation fails so no client cert requested. so thanks your for re-reading of the request. I'll forward the CAcert sysadmin Best regards, Guillaume
Reporter | ||
Comment 7•14 years ago
|
||
Hello, I also have tested with FF4 Ubuntu PPA MineField 4.0b9pre (2011-01-09) Mozilla Firefox for Ubuntu canonical - 1.0 And I have the same problem. So the problem is cross plateform. Best regards, Guillaume
Reporter | ||
Comment 8•14 years ago
|
||
Ubuntu, the following Lucid version works fine with client certificate login : version 3.6.14pre Mozilla Firefox for Ubuntu canonical - 1.0 Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.2.14pre) Gecko/20110107 Ubuntu/10.04 (lucid) Namoroka/3.6.14pre
![]() |
||
Updated•14 years ago
|
blocking2.0: --- → ?
Keywords: regression
Guillaume: you don't have to test further to track down what versions are affected (I already adapted the platform fields for this entry, BTW). It's actually clear by now that this is a regression caused by changeset 60055:d2856d5970b6 (committed on 6th January 2011 00:32 UTC). You can use one of the nightlies at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011-01-05-03-mozilla-central/, and I'd bet it will work with these versions. Also, note that nigthlies are different from beta versions - they include more recent, but somewhat less tested code (with 4.0b8 you wouldn't have run into this problem either).
![]() |
||
Comment 11•14 years ago
|
||
Are there any suggestions how this should be fixed? Most clear should probably be to cache and observe the value in PSM component and protect it with a mutex. I can do this. Kaspar, what do you think?
Reporter | ||
Comment 12•14 years ago
|
||
Hello Kaspar, (In reply to comment #9) > Guillaume: you don't have to test further to track down what versions are > affected (I already adapted the platform fields for this entry, BTW). It's > actually clear by now that this is a regression caused by changeset ok, good & thanks... but I will keep using the nigthlies anyway. if I need to connect to CAcert, I will start FF 3.6 :) Best regards, Guillaume
Comment 13•14 years ago
|
||
(In reply to comment #11) > Most clear should probably be to cache and observe the value in PSM component > and protect it with a mutex. I can do this. > > Kaspar, what do you think? Well, I'm probably not the best person to judge this, but it's what bz suggested for bug 585706, so it can't be that wrong, I guess :-) Another question is whether we should continue treating a failure of GetCharPref as "fatal" in nsGetUserCertChoice, or whether we should simply default to *certChoice = ASK in this case (it might hide future issues with accessing the PrefService, yes, but at least it would allow the user to select a cert and continue, anyway).
Comment 14•14 years ago
|
||
The real fix for this bug will happen for bug 624514 but we already backed out the patch that caused this regression. Resolving as a dupe of 624514.
Status: NEW → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → DUPLICATE
Whiteboard: [hardblocker]
Reporter | ||
Comment 16•14 years ago
|
||
(In reply to comment #14) > The real fix for this bug will happen for bug 624514 but we already backed out > the patch that caused this regression. Resolving as a dupe of 624514. > > *** This bug has been marked as a duplicate of bug 624514 *** Minefield version 4.0b10pre 2011-01-13 the client certificate login seems to work. thanks.
Reporter | ||
Comment 17•14 years ago
|
||
(In reply to comment #16) > (In reply to comment #14) > > The real fix for this bug will happen for bug 624514 but we already backed out > > the patch that caused this regression. Resolving as a dupe of 624514. > > > > *** This bug has been marked as a duplicate of bug 624514 *** > > Minefield version 4.0b10pre 2011-01-13 the client certificate login seems to > work. thanks. side note : at the same time, I was no longer able to backup a personal certificate (pkcs12 format with private key) from the keystore, FF4 requested a filename for backup, then just stopped without requesting for a password to cipher the private key of the pkcs12 file. This problems seems to have dissapeared at the same time. I won't open a new bug request. Best regards, Guillaume
Updated•14 years ago
|
blocking2.0: ? → betaN+
You need to log in
before you can comment on or make changes to this bug.
Description
•