[dwmw2@i7 nssdb]$ sudo setup-nsssysinit.sh off [dwmw2@i7 nssdb]$ sudo certutil -d sql:/etc/pki/nssdb -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Intel_External_Basic_Issuing_CA_3A_20060322.crt CT,C,C Intel_External_Basic_Issuing_CA_3A_20090515.crt CT,C,C Intel_External_Basic_Issuing_CA_3B_20060322.crt CT,C,C Intel_External_Basic_Issuing_CA_3B_20090515.crt CT,C,C Intel_External_Basic_Policy_CA_20060216.crt CT,C,C Intel_Intranet_Basic_Issuing_CA_1A_20050524.crt CT,C,C Intel_Intranet_Basic_Issuing_CA_1A_20060524.crt CT,C,C Intel_Intranet_Basic_Issuing_CA_1A_20090515.crt CT,C,C Intel_Intranet_Basic_Issuing_CA_1B_20050610.crt CT,C,C Intel_Intranet_Basic_Issuing_CA_1B_20060524.crt CT,C,C Intel_Intranet_Basic_Issuing_CA_1B_20090515.crt CT,C,C Intel_Intranet_Basic_Issuing_CA_2A_20060524.crt CT,C,C Intel_Intranet_Basic_Issuing_CA_2A_20090515.crt CT,C,C Intel_Intranet_Basic_Issuing_CA_2B_20060524.crt CT,C,C Intel_Intranet_Basic_Issuing_CA_2B_20090515.crt CT,C,C Intel_Intranet_Basic_Policy_CA_20050518.crt CT,C,C Intel_Intranet_Basic_Policy_CA_20060524.crt CT,C,C Intel_Root_CA_20050518.crt CT,C,C [dwmw2@i7 nssdb]$ sudo certutil -d sql:/home/dwmw2/.pki/nssdb -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI CAcert Class 3 Root - Root CA ,, [dwmw2@i7 nssdb]$ /usr/lib64/nss/unsupported-tools/tstclnt -h twosheds.infradead.org -p 993 -d sql:/etc/pki/nssdb tstclnt: read from socket failed: Peer's Certificate issuer is not recognized. [dwmw2@i7 nssdb]$ /usr/lib64/nss/unsupported-tools/tstclnt -h twosheds.infradead.org -p 993 -d sql:/home/dwmw2/.pki/nssdb tstclnt: read from socket failed: Peer's Certificate issuer is not recognized. All is well...
[dwmw2@i7 nssdb]$ sudo setup-nsssysinit.sh on [dwmw2@i7 nssdb]$ /usr/lib64/nss/unsupported-tools/tstclnt -h twosheds.infradead.org -p 993 -d sql:/home/dwmw2/.pki/nssdb tstclnt: read from socket failed: Peer's Certificate issuer is not recognized. [dwmw2@i7 nssdb]$ /usr/lib64/nss/unsupported-tools/tstclnt -h twosheds.infradead.org -p 993 -d sql:/etc/pki/nssdb subject DN: CN=twosheds.infradead.org issuer DN: CN=CAcert Class 3 Root,OU=http://www.CAcert.org,O=CAcert Inc. 0 cache hits; 1 cache misses, 0 cache not reusable 0 stateless resumes * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN] Dovecot ready. WTF?
[dwmw2@i7 nssdb]$ certutil -d sql:/etc/pki/nssdb -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI CAcert Class 3 Root - Root CA CT,C,C
Throwing away the contents of /etc/pki/nssdb makes it go away. And this makes it come back: [root@i7 nssdb]# certutil -d sql:/etc/pki/nssdb -A -i ~dwmw2/class3.crt -n class3 -t TC,TC,TC [root@i7 nssdb]# certutil -d sql:/etc/pki/nssdb -D -n class3
It looks like NSS is using the trust bits from /etc/pki/nssdb for the certificate, instead of allowing them to be overridden by the bits in $HOME/.pki/nssdb. Surely that's the wrong way round -- the user should be able to override the trust settings inherited from /etc/pki/nssdb? And it's even *worse* that this continues to happen even after the certificate is supposed to have been *removed* from the database in /etc/pki/nssdb :)
Should we assign a CVE for this? Trusting a CA that the admin has *removed* from the trust database is worthy of a CVE, isn't it?
Let's start by not mixing all issues together. Reading this report, I believe the primary issue here is that when combining system and user nssdb data together, NSS may end up using trust flags from *deleted* system nssdb entry and certificate from *untrusted* user nssdb entry and trust in the combination of the two. It may be better to keep concerns regarding which trust flags should trump the other aside for now. I believe the correct way to trigger the problem is to do the following: - add CA cert to system nssdb, and set flags to trust it (e.g. TC,C,C) - add the same CA cert to user nssdb with no trust in in (,, flags) - remove CA cert from system nssdb Remove operation does not seem to fully remove it from the sqlite db (as can be verified with sqlite3 cert9.db). certutil -L output also indicates something is not as it should be. Running as root: # certutil -L -d sql:/etc/pki/nssdb/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI and as user: $ certutil -L -d sql:/etc/pki/nssdb/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI cacert.org CT,C,C $ certutil -L -d sql:$HOME/.pki/nssdb Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI cacert.org ,,
(In reply to comment #6) > Let's start by not mixing all issues together. Reading this report, I believe > the primary issue here is that when combining system and user nssdb data > together, NSS may end up using trust flags from *deleted* system nssdb entry > and certificate from *untrusted* user nssdb entry and trust in the combination > of the two. Yes. > It may be better to keep concerns regarding which trust flags should trump the > other aside for now. It may. Or it may be that fixing that will also fix the primary issue. I do try to file separate bugs for separate issues where appropriate. It may even be that this bug is *introduced* by the fix for another bug, such as bug 603313.
(In reply to comment #7) Dabid, I don't think the patch for bug 603313 is the cause, see the discussion in https://bugzilla.redhat.com/show_bug.cgi?id=643134, I'm testing a patch from Bob with good results. Could you try out the scratch build pointed at in https://bugzilla.redhat.com/show_bug.cgi?id=643134#c7 ?
Created attachment 456770 [details] script to reproduce the bug / verify fix
Comment on attachment 456770 [details] script to reproduce the bug / verify fix Though I verfied the fix againts the Rawhide build at http://koji.fedoraproject.org/koji/buildinfo?buildID=202661 I also couldn't reproduce teh problem with prior builds. Did I oversimplify the bug reproduction steps?
The original involved *deleting* the cert from the system database -- see comment 3
Btw, it's probably best to use another machine that isn't on my ADSL line -- such as bombadil.infradead.org. And your tstclnt should surely be using sql:/etc/pki/nssdb (which with nsssysinit enabled will automatically also include the db from the user's home directory)
Created attachment 457828 [details] script to reproduce the bug / verify fix With the changes suggested in Comment 11 and Comment 12 this time I'm able to reproduce the bug.
Verification of the "fix" failed.
Elio, are we still in the "no fix available yet" state?
Yes, no fix yet. I am going to need Bob's help with this one.
Created attachment 462718 [details] cert in DER used for testing downloaded from http://www.cacert.org/certs/class3.der
Created attachment 474753 [details] Fix to honor user's preferences regarding trust Thank you Bob for the fix and the advise. Verified with attachment 457828 [details]. Also, listing via 'certutil -L -d sql:/etc/pki/nssdb' shows ,, in the trust column.
nss-3.12.9-2.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/nss-3.12.9-2.fc14
nss-3.12.9-2.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update nss'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/nss-3.12.9-2.fc14
Created attachment 474865 [details] to reproduce / verify fix - with a few more steps
I'm using the packages from updates-testing. I have a passphrase set on my database in ~/.pki/nssdb. I'm using a version of xulrunner with bug 546221 fixed. (I hope everyone who cares about the NSS system DB is doing so, too?) Now *every* time I go to a form which needs passwords, I am asked for the passphrase for my NSS DB. Before updating to the new NSS packages, I was only ever asked *once* during the lifetime of each firefox process. I assume this wasn't an intentional change?
Created attachment 475463 [details] Updated patch per upstream review requests This is what is actually checked in upstream after we sent the fix for review.
> Now *every* time I go to a form which needs passwords, I am asked for the > passphrase for my NSS DB. Before updating to the new NSS packages, I was only > ever asked *once* during the lifetime of each firefox process. I assume this > wasn't an intentional change? No, is this happening with the patches Elio sent out. It sounds like the root database is running as the default database. This would happen if you get the updated patches for NSS, but not the latest nsssysinit. (or the latest nsssysinit without the latest NSS). bob
Hm, sorry, do I have the wrong packages installed? nss-3.12.9-2.fc14.i686 nss-3.12.9-2.fc14.x86_64 nss_compat_ossl-0.9.6-1.fc13.x86_64 nss_db-2.2.3-0.3.pre1.fc14.x86_64 nss-debuginfo-3.12.9-1.fc14.x86_64 nss-devel-3.12.9-2.fc14.x86_64 nss_ldap-265-6.fc14.x86_64 nss-mdns-0.10-8.fc12.i686 nss-mdns-0.10-8.fc12.x86_64 nss-softokn-3.12.9-1.fc14.i686 nss-softokn-3.12.9-1.fc14.x86_64 nss-softokn-devel-3.12.9-1.fc14.x86_64 nss-softokn-freebl-3.12.9-1.fc14.i686 nss-softokn-freebl-3.12.9-1.fc14.x86_64 nss-sysinit-3.12.9-2.fc14.x86_64 nss-tools-3.12.9-2.fc14.x86_64 nss-util-3.12.9-1.fc14.i686 nss-util-3.12.9-1.fc14.x86_64 nss-util-debuginfo-3.12.9-1.fc14.x86_64 nss-util-devel-3.12.9-1.fc14.x86_64 xulrunner-1.9.2.13-5.sysdb.fc14.x86_64
Created attachment 475517 [details] V3: Updated patch per additional upstream review requests
(In reply to comment #27) > Hm, sorry, do I have the wrong packages installed? > Those were the right packages I posted on Sunday. Since then I pulled it the back from updates testing because we though prudent to get the patches reviewed and checked in upstream first. The changes made in response the review are not significant relative to what you have though. I'll make a scratch build available tomorrow so we can both check this.
OK, thanks. The only thing I'm doing 'special' is fixing the bug that firefox doesn't use the shared nssdb, and setting a password on mine. It shouldn't be hard to reproduce.
(In reply to comment #30) >It shouldn't be hard to reproduce. Well, if one has already the patched version of xulrunner :-) The nss cratch build is here http://koji.fedoraproject.org/koji/taskinfo?taskID=2746491 and a xulrunner scratch build with a like patch like yours applied http://koji.fedoraproject.org/koji/taskinfo?taskID=2746491 I still have to test them. Unfortunately, I'm currently tied up with some time critical tasks and don't have time right now to pusue this.
I installed the updates and haven't had problems. I don't quite understand how to reproduce it as in: > > Now *every* time I go to a form which needs passwords, I am asked for the > > passphrase for my NSS DB. Before updating to the new NSS packages, I was only > > ever asked *once* during the lifetime of each firefox process. I assume this > > wasn't an intentional change? > Could you offer us more details? For example, a site I could connect to (the ones I login and require password are either kerberos or ssh so nss is not involved) Is the remember password not working, did you went to another paged and came back to that of the site? > No, is this happening with the patches Elio sent out. It sounds like the root > database is running as the default database. An the whole point of the patch is that the userdb be the default.
(In reply to comment #32) > Could you offer us more details? I go to a site for which I have saved passwords. For example https://clueless.aaisp.net.uk/main.cgi?GSEARCH A pop-up appears, saying "Please enter the master password for the Software Security Device". I enter the password that I have on my sql:~/.pki/nssdb database and then it fills in the correct password for me. I log *out* of the site in order to log in with another account (which is also remembered by firefox). But when I go back to the login URL, I get that 'Please enter the master password...' popup *again*. I never used to get it more than once, in the lifetime of a firefox process.
nss-3.12.9-5.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/nss-3.12.9-5.fc14
nss-3.12.9-5.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update nss'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/nss-3.12.9-5.fc14
(In reply to comment #33) I set up my own webserver that requires authentication, I can access it without any problems from my client machine whit the broswer configured to remember passwords, the user db with password, and a patched xulrunner. Password is remembers, as I navigate to others site and come back there is no additional prompt for it. The server is behind a firewall so I can't share it.
Package nss-3.12.9-8.fc13,nss-softokn-3.12.9-5.fc13,nss-util-3.12.9-1.fc13,nspr-4.8.7-1.fc13: * should fix your issue, * was pushed to the Fedora 13 updates-testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing nss-3.12.9-8.fc13,nss-softokn-3.12.9-5.fc13,nss-util-3.12.9-1.fc13,nspr-4.8.7-1.fc13' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/nss-3.12.9-8.fc13,nss-softokn-3.12.9-5.fc13,nss-util-3.12.9-1.fc13,nspr-4.8.7-1.fc13 then log in and leave karma (feedback).
nss-softokn-3.12.9-5.fc14, nss-3.12.9-8.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 636859 has been marked as a duplicate of this bug. ***
nss-3.12.9-8.fc13, nss-softokn-3.12.9-5.fc13, nss-util-3.12.9-1.fc13, nspr-4.8.7-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.