Closed Bug 308863 Opened 19 years ago Closed 6 years ago

Camino doesn't access certificates in OS X Keychain

Categories

(Camino Graveyard :: OS Integration, enhancement)

Product:
Camino Graveyard
Component:
OS Integration
Platform:
PowerPC
macOS
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: tmiller, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; de-de) AppleWebKit/125.5.5 (KHTML, like Gecko) Safari/125.11
Build Identifier: 2005091409

Apple's Keychain holds more than passwords; user and website X509 certificates
are stored in Keychain as well.  Camino cannot use user certificates in the
user's keychain, limiting access to secure websites or forcing the user to
maintain two duplicate certificate stores.

In addition, Keychain on OS X 10.4 can access certificates stored on smartcards.
 Without Camino support for Keychain certificates, these certificates cannot be
used at all.  This limits Camino's use in secure environments.

Reproducible: Always

Steps to Reproduce:
1. Install a user certificate and private key in Keychain.
2. Navigate to a web page using SSL client authentication that requires that
certificate.

Actual Results:  
Camino is unable to authenticate.

Expected Results:  
Camino should use the certificate in Keychain for authentication.
There are several bugs about holes in our keychain support; not sure if this is
a dupe of any of them or something new.
Assignee: dveditz → pinkerton
Component: Security → OS Integration
QA Contact: camino
(In reply to comment #1)
> There are several bugs about holes in our keychain support; not sure if this is
> a dupe of any of them or something new.

I looked at many of the other Keychain-related bugs, and I'm confident to call this a new but related issue.  
The use of client certificates is not especially common, and the use of smartcards even less so.
I think this is really an NSS issue, as I don't believe it's possible for Camino
to register any "fall-back" APIs that would get called if NSS can't find a cert
in its data stores.

Or is there a away that we can implement an additionanl "security device" that
wraps Keychain APIs?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Yes.  A "security device" in NSS is a dynamic shared library
that exports the PKCS #11 interface and talks to a software
or hardware crypto module.  So you can write a PKCS #11 library
that talks to the Keychain.
(In reply to comment #4)
> Yes.  A "security device" in NSS is a dynamic shared library
> that exports the PKCS #11 interface and talks to a software
> or hardware crypto module.  So you can write a PKCS #11 library
> that talks to the Keychain.

OS X already includes a PKCS#11 module that is compatible with NSS (it's at
/usr/libexec/SmartCardServices/pkcs11/pkcs11.bundle/Contents/MacOS/pkcs11) 
Works fine in Firefox/Mozilla.  Camino includes no UI for adding or managing
security modules the way that Firefox does (in
Prefrerences->Advanced->Security->Security Devices).

While full-on Keychain support for certs would be most "Mac-like", if Camino
could include this UI, I'd consider that an acceptable interim solution.

(In reply to comment #4)
> Yes.  A "security device" in NSS is a dynamic shared library
> that exports the PKCS #11 interface and talks to a software
> or hardware crypto module.  So you can write a PKCS #11 library
> that talks to the Keychain.

The issue then remaining is whether we can faithfully convert a Keychain
certificate (SecCertificateRef) to whatever NSS/PSM need.

(In reply to comment #5)

> Works fine in Firefox/Mozilla.  Camino includes no UI for adding or managing
> security modules the way that Firefox does (in
> Prefrerences->Advanced->Security->Security Devices).

Right, adding this UI would be the next step.
It seems that for camino, we always want to key ring PKCS #11 module loaded.
(probably for Firefox Mac as well). I think we should have some code in
nsComponent::NSS_Init() which makes sure this is the case. We already have code
in there to make sure the built-ins are loaded.

There are 2 options here if we do this:
   option 1) always load the keyring PKCS #11 module if it's not already
included in secmod.db (that is NSS hasn't loaded it in it's init call). After
loading store it into secmod.db. There is a special call that does both:
SECMOD_AddNewModule(). Currently this is what the builtins module does.
   option 2) always load the keyring PKCS #11 module if it's not already
included in secmod.db (that is NSS hasn't loaded it in it's init call). Do not,
however, add it to secmod.db. For this you would use the new
SECMOD_AddUserModule call. There is some talk of moving toward this model for
the builtins.

option 1 has the advantage that if you have more than one version of firefox and
camino, they would all use the key ring, even if they don't have this code.

option 2 has the advantage that you aren't 'polluting' the secmod.db with
modules which may be moved on the file system (this is a bigger advantage for
the builtins, because each version of firefox/camino has it's own version of the
builtins which could differ).

Both options have the 'disadvantage' of not being able to turn off loading of
the key ring.
(In reply to comment #7)
> It seems that for camino, we always want to key ring PKCS #11 module loaded.

s/keyring/KeyChain/g  :)

> (probably for Firefox Mac as well). I think we should have some code in
> nsComponent::NSS_Init() which makes sure this is the case. We already have code
> in there to make sure the built-ins are loaded.
> 
> option 2 has the advantage that you aren't 'polluting' the secmod.db with
> modules which may be moved on the file system (this is a bigger advantage for
> the builtins, because each version of firefox/camino has it's own version of the
> builtins which could differ).

This is a big problem that we already suffer from: I've seen bad stuff happen
when deleting an old copy of Mozilla, because the secmod.db in my profile has an
entry pointing to a lib in this copy of Mozilla. We should _never_ store any
paths to libs in the application in a user profile.
What's the status of this? Is there any way this could be in 1.0?
No way this is gonna happen in 1.0.
Target Milestone: --- → Camino1.2
Assignee: mikepinkerton → nobody
QA Contact: os.integration
Okay, now that 1.1 is beta, what's the progress on this issue?
Still unfixed, as indicated by the bug's status. This is not going to be a 1.1 feature.
Mass un-setting milestone per 1.6 roadmap.

Filter on RemoveRedonkulousBuglist to remove bugspam.

Developers: if you have a patch in hand for one of these bugs, you may pull the bug back to 1.6 *at that point*.
Target Milestone: Camino1.6 → ---
I think what we really want to do is make Camino more integrated with the Mac OS. A good first step was moving password management to the KeyChain, but I think that all certificate management should be done in the OS and certificates stored in the KeyChain eventually. Then the internal Camino certificate management system could be phased out.
(In reply to comment #14)
> I think that all certificate management should be done in the OS and 
> certificates stored in the KeyChain eventually.

That's out of the scope of this bug; this is specifically about reading certificates from the keychain. If you'd like to write an entirely keychain-based implementation of the core certificate system, please take that up in a new bug.
(In reply to comment #15)
> 
> That's out of the scope of this bug; this is specifically about reading
> certificates from the keychain. If you'd like to write an entirely
> keychain-based implementation of the core certificate system, please take that
> up in a new bug.
> 

I don't have the skills to do it or I might. And I am not complaining either. I know developers are doing this in their free time, and this is not an urgent feature enhancement. I was just giving feedback on something that I noticed today as a new user, that with a goal of being integrated with the MacOS much more than Firefox, it makes sense to use the OS certificate handling in addition to the Keychain for password management. I think the password management being moved over was much more important and it is great that it is done, but that eventually Camino should use the OS for certificate management and validation. I mean this could be a v2 or later thing for sure.

This bug was the closest to this idea that I could find, and I figured it good to run by the people following this issue. If others agree that this is the eventual goal, then it may not make sense taking the intermediate step of completing this bug.
(In reply to comment #15)

> That's out of the scope of this bug; this is specifically about reading
> certificates from the keychain. If you'd like to write an entirely
> keychain-based implementation of the core certificate system, please take that
> up in a new bug.

Actually, if you go back to my original problem statement which is that Camino can't access certificates in Keychain, doing certificate management, chaining, and validation via the Apple APIs rather than NSS is implied though not specifically stated.

-- Tim
Would fixing this bug using the stuff in comment 7 fix the issue people are having with the confusing NSS "software security device" passwords, e.g. http://forums.mozillazine.org/viewtopic.php?p=2992263#2992263, or do we need a separate bug on it?
I read through this bug.

I vote that we do option 2 from comment 7 (option 1 seems to have disadvantages, and it seems reasonable to require the recent version of camino/firefox if users wants this fix).

So what is left to be done?

An NSS developer must go ahead and implement option 2 from comment 7, which must be done internally in NSS.

What I wrote in comment 19 is for the "automatic" solution.

You still have the option to include the UI to manually add additional modules (which, however, will be recorded in secmod.db - effectively recording the full path of the user specified module in the secmod.db local to the mozilla app and profile)

Actually, option 2 would be implemented in PSM, much like the existing root cert handling.

bob
Time, do you know if Mac OS X is always using the same directory and filename for the module in /usr/libexec/SmartCardServices/pkcs11/pkcs11.bundle/Contents/MacOS/pkcs11 ?

Bob, thanks for the clarification, now I see what you mean.

I think option 2 really refers to function SECMOD_LoadUserModule.

You're saying, PSM should only attempt to load it, if NSS didn't yet load it (meaning, it was not recorded in secmod.db).

How would we protect us from accidentially loading the module twice? We can't rely on the module name, because it could be anything (if someone copied secmod.db over from another profile).

Is it possible to iterate the loaded modules and obtain filename / directory?

Or will NSS protect itself from loading the same module twice?

Kai--

That module directory has been the same since 10.3 (prior to that it didn't exist except as an add-on package).  I don't expect it to change, but I'd need a copy of Leopard to be sure.  :)

-- Tim
Depends on: 963354
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.