322145 - PKCS#11 password prompt when working with TLS/SSL sites that accept client certificate

Status: RESOLVED WONTFIX

(Core :: Security: PSM, defect)

Description

[Alon Bar-Lev]

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.

Comment 1

[Ralf Hauser]

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 

Comment 2

[Wayne Mery (:wsmwk)]

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)

Comment 3

[Martin Paljak]

This is most probably related to the internal NSS "Friendly certs" PKCS11_PUB_READABLE_CERT_FLAG  "feature" which is described on https://developer.mozilla.org/en/JavaScript_crypto

The problem comes from the NSS idea that tokens require a PIN code to read the certificates off the token. If the remote end of a SSL enabled server uses "SSLClientCert optional" or similar configuration option (which means "if you have a client certificate to present, you can send it but I don't need one to continue") and then Thunderbird has to log on to all the tokens it knows and prompt for the PIN  of the token just to read out the certificate on the token only to find out that none of the certificates matches the CA list presented by the server.

No "big clients" (Firefox, Thunderbird) enable it by default as it is supposed to be. Also, both Firefox and Thunderbird lack a GUI option to check "certificates on this token are publicly readable".

So most non-trivial PKCS#11/PKI setups have really bad usability with both thunderbird and firefox :)


Solution to the problem: 1) set the PKCS11_PUB_READABLE_CERT_FLAG on by default for all modules, as this the normal case 2) in PSM GUI allow to uncheck the flag for every slot/token to disable the normal functionality (which is to assume publicly readable certificates)

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 5

[Martin Paljak]

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.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 7

[Alon Bar-Lev]

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.

Comment 8

[Martin Paljak]

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.

Comment 9

[Robert Relyea]

> 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

Comment 10

[Kai Engert (:KaiE:)]

Could you summarize the beavior new desired GUI and either update the subject of this bug or file a new one? Thanks.

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 12

[Kai Engert (:KaiE:)]

Mass change owner of unconfirmed "Core:Security UI/PSM/SMime" bugs to nobody.
Search for kaie-20100607-unconfirmed-nobody

Comment 13

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

We won't be allocating resources to implementing this feature.