Closed Bug 322145 Opened 15 years ago Closed 4 years ago
PKCS#11 password prompt when working with TLS/SSL sites that accept client certificate
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051231 Firefox/1.5 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051231 Firefox/1.5 New to 1.5. When working with email server using TLS/SSL protocol, the site may accept optional client certificate. If a PKCS#11 module is installed within Thunderbird, it always prompts for token password. This is very annoying, especially when the user know that he don't wish to authenticate using a client certificate for this site. Reproducible: Always Steps to Reproduce: 1. Install PKCS#11 provider. 2. Work with gmail using pop3/smtp over SSL. Actual Results: You should be poped up for token password when receive and send emails. Expected Results: The following setting: ---> Account Settings->Server Settings->Security Settings->Use secure authentication If turned off it should not attempt to logon to the PKCS#11 token at key negotiation. Also the following option: Outgoing Mail->Security And Authentication Should have a similar switch: Use secure authentication If turned off it should not attempt to logon to the PKCS#11 token at key negotiation.
is there a way you could get into gmail with a client certificate on your pkcs11 device if you wanted to? see also Bug 327001 and Bug 290787
Do you see problem using thunderbird 2? Or, better yet, Thunderbird 3 beta 2**? If you do, please comment. If you do not, please close the bug with resolution WORKSFORME (or some appropriate resolution, but not FIXED) ** Beta 2 has big fix of Bug 239131 Thunderbird should use the new password manager http://www.mozillamessaging.com/en-US/thunderbird/early_releases/ (suggest you backup your profile before using beta release)
Component: General → Security
Martin, I'm amused by you analysis. The concept that PKCS#11 tokens require a login before you can do ANYTHING with them is a characteristic of the PKCS#11 token model, not "an NSS idea". The vast majority of PKCS#11 tokens work that way. One reason for that is that there are certain standards for crypto devices (such as FIPS-140) that require it. Some (very very few) tokens allow you to list their certs even when you're not logged into them. They are the exception, not the rule, not the "normal case" nor the "normal functionality". NSS gives PKCS#11 module authors the ability to say "My module is exceptional and allows applications to search through the certificate objects, even when not logged in" by setting the bit you mentioned when the PKCS#11 module is installed. Such a module is said to be "friendly", and is signified in NSS's configuration file of PKCS#11 modules with the flag bit you mentioned. When NSS is looking through the PKCS#11 tokens available to the process, and it finds a token that is not logged in, and is not marked friendly, then NSS asks the user to login to the token before attempting to list the certs in that token. NSS will only do that for tokens that are "present". NSS will not prompt for a password for a token that is not available. NSS/Firefox provide a way for INSTALLERS of PKCS#11 modules to set that "friendly" bit at installation time. The bit is not set by default because modules/tokens that allow certs to be searched while not logged in are rare. It is set by default on NSS's own built-in pure software module, when that module is not configured to operate according to FIPS 140, because NSS's own module allows this "friendly" behavior. If you set that bit in NSS's configuration file for a module that does not actually support this so-called "friendly" behavior, you'll have problems with that module. I'd say it doesn't hurt to try it, and if you're lucky and your module is a "friendly" module, then it will be a win for you. But if your module is typical and does not support "friendly" behavior, then it may seem to stop working entirely for you at that point.
Good to hear! From PKCS#11 v2.11 spec, with emphasis added: Further classification defines access requirements. ***Applications are not required to log into the token to view “public objects” ***; however, to view “private objects”, a user must be authenticated to the token by a PIN or some other token-dependent method (for example, a biometric device). I know OpenSC which supports a handful of tokens and I believe most if not all of them have/support certificates as public objects. So do all EU eID cards. I know that across the big sea there is FIPS and CAC/PIV (which AFAIK OpenSC also supports) that hide some certificates before authentication. Next I quote what is written in mozilla.org wiki, with emphasis added: PKCS11_PUB_READABLE_CERT_FLAG: This is the only flag ***most smart tokens should turn on***. You can turn this flag on if: the certs on your token can be read without authentication and, the public key on your token can be found by ID, MODULUS, or VALUE and all your private keys have the associated public key. Turning this flag on will illuminate a large number of password prompts for your token when looking up certs in Communicator. GUI has a "Turn on FIPS mode" button - I would assume that if you require FIPS and the login-before-you-see-anything mode, that button could turn it on. Or maybe if there is a token but no objects, try to log in and see if you could find something. So, I have here on my system this coolpkcs11provider.dll/.so where the provider doesn't even know what firefox is, just provides cool hardware. The provider is already installed to my system, now I'm installing it into Firefox/Thunderbird. No luck with the friendly bit thing! The key issue here is that GUI applications hide the feature. Tech-speak about which is more right (the friendly approach or unfriendly) might be "legally OK" but useless from usability point of view.
Most PKCS#11 tokens treat all objects as "private" objects. The "FIPS Mode" button only controls the behavior of NSS's built-in pure software token, not the behavior of third party tokens. As I wrote before, there is a way to install a PKCS#11 module that sets the "friendly" bit, but Firefox/PSM's UI for adding modules does not expose it. I believe there's already an RFE on file about that. You could resolve this bug as a duplicate of that one.
Wrong. It is not in the PKCS#11 domain to decide if objects are privates or public. PKCS#11 provider *MUST* support public objects and private objects. It is up to the user/administrator/security-officer to decide which object type is assigned what attributes. Every provider I know, and I know many, endorse using certificates as public objects. There is a minor issue why certificates are public in most of providers, as if a vendor wishes to support both PKCS#11 and CSP interfaces, it must follow the common requirements. Unless you want to violate CSP best practices, access to certificate objects should be done without authentication. As Martin said, all national ids provides certificates as public objects. Again, this has nothing to do with PKCS#11. Most implementation decides to set world ACL to the certificate objects.
Alon, thanks for the clarification, I just wanted to e-mail you to ask for some empirical statistics based on pkcs11-helper that how many providers do not provide/support public certificates. Talking about national IDs - I believe PIV is the only (public government provided eID) one that hides some objects before C_Login. I could not find a ticket for the Friendly bit GUI thing.
> Wrong. > > It is not in the PKCS#11 domain to decide if objects are privates or public. > PKCS#11 provider *MUST* support public objects and private objects. This is not true. PKCS #11 modules *MAY* allow the "administrator" to arbitrarily set public or private on particular objects, however it may also be true that a given hardware token only supports private objects, for instance.... or only requires all keys to be private objects. This is a characteristic of the token, which is then reflected to the application through the standard PKCS #11 interface. > Every provider I know, and I know many, endorse using certificates as public > objects. Several FIPS level-4 tokens do not. This case is rare but it does exist. Both of these points are somewhat irrelevant, though. The issue is not finding the certificate, but finding the certificate with the associated private keys. In general private keys are marked private, and are not found by C_FindObjects unless the token is loggged in. Because of this, NSS cannot guarantee correct behaviour when searching for a user certificate in a generic PKCS #11 token unless it authenticates to that token. As the poster noted, this can be quite annoying, particularly if you authenticate to the token and it does not have the required key/cert, you've effectively authenticated 'in vain'. That is why NSS has the 'Publically readable Certs, or Friendly flag (the latter is the internal name)". This tells NSS that the token conforms to a standard, more strict than PKCS #11, Where 1) token certificates are all publically readable, 2) All token private keys have a corresponding token public key which is publically readable, and 3) There are no token public keys which do not have a corresponding private key. [NOTE that PKCS #11 still requires all three to share the same CKA_ID, NSS depends on this as well]. It the token all of these criteria, it's safe to set the 'Publically Readable' flag to tell NSS not to authenticate when searching for user certificates. Two important Notes about this flag: 1. In a very real sense it's more than if the PKCS #11 token supports these sematics, it's also if the token was provisioned with these semantics. That is, if a token supports storage of keys and certs, it's possible for someone to provision the token by importing both the public and private keys as well as the certs. If the same token is provisioned by only importing the private keys and certs, it would no longer meet the requirements. 2. As Alon pointed out, most tokens and provisioning systems do make the certificates publicly readable. So it's usually requirements 2 and 3 that are an issue. If your token doesn't support requirement 3, then you may get false positives when you set the publically readable flag. This would be exceedingly rare, so such tokens it's probably safe. Requirement 2, however, will render the token effectively inactive for any type of client authentication, (and probably signing as well) until you explicitly log in to it. > I believe PIV is the only (public government provided eID) one that hides > some objects before C_Login. Almost all tokens will hide private keys... or any other objects marked private. > I could not find a ticket for the Friendly bit GUI thing. If there isn't one, we should convert this bug into one. The lack of a public readable cert flag in the UI for mozilla products really is a deficiency. For your own purporses, you can use the modutil command line tool to change that flag. bob
Assignee: nobody → kaie
Component: Security → Security: PSM
Product: Thunderbird → Core
QA Contact: thunderbird → psm
Could you summarize the beavior new desired GUI and either update the subject of this bug or file a new one? Thanks.
Kai, this bug is a request for the ability to configure a Thunderbird email account to NEVER attempt to use a certificate to do client authentication, thereby eliminating the search for a suitable certificate, and the related password prompt from the PKCS#11 module. I believe this is a duplicate of bug 437683.
Mass change owner of unconfirmed "Core:Security UI/PSM/SMime" bugs to nobody. Search for kaie-20100607-unconfirmed-nobody
Assignee: kaie → nobody
We won't be allocating resources to implementing this feature.
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.