On 17-Mar-09, at 7:55 AM, Ian G wrote:
I'd like to ask a couple of questions to those people closer to the
development effort. I spent some hours trying to get a couple of
users up and going on the weekend using client certs and ff/tb
combinations. On the Firefox side, there were problems because of
the popup madness where every click resulted in request(s) to
confirm the certificate [1].
Doing some research on bugzilla, it transpires that the default is
to always ask before using a client certificate, because otherwise
we have a privacy issue. <https://bugzilla.mozilla.org/show_bug.cgi?id=295922
> Now, this is a bit of a killer issue, because the certs probably
have info in them, and there are obvious harvesting possibilities
[2] [3].
However, the fix is to turn on the "ask always" default, which makes
client certs unusable [4] because every click there is a request for
confirmation, and sometimes there are several clicks.
So we have seem to have a choice: client certificates are unusable
because they always ask, or they are unusable because they always
leak private info. There is no middle ground.
Have I understood it correctly so far?
Starting from a point of basic agreement that client certs need to be
a lot more usable than they currently are, I'll nevertheless point out
that your experience isn't the typical one, here. As you mention in
your footnote, there appears to be some brokenness with your testing
server wrt SSL sessions. The initial client cert auth should be used
to establish an authenticated session, which the server should persist
for some period of time thereafter, making subsequent identifications
less onerous. Nelson has commented on bugs of this ilk before, I hope
he's around for this thread as well.
Having said that...
There is some discussion that there should be a "whitelist"
management along the lines of the tuple {site, cert, status}. And
some juicy UI to manage that.
So the next questions are: is whitelisting decided, and how far
advanced are we on that? (Or, is there some alternative?)
I started this reply with "client certs need to be a lot more usable."
This is something I wanted to do for Firefox 3.5 (née Firefox 3.1) but
other obligations kept me from doing much work on that release in the
early "feature planning" stages. It continues to be something I'd like
to improve in Firefox Next, specifically in the areas of:
- Remembering certs used on a particular site for future interactions
- Improving the cert selection dialog so that it can be read by humans
- Reviewing the cert management/installation UI to see if we're
really serving our users' needs there (should every cert pushed be
installed without prompting?)
I think the implicit 4th step there is evangelism, because I think
they're a much more robust identification/authentication technology
than login+pw, or most of login+pw's would-be replacements. But I
also think there's no point evangelizing the current state of affairs,
for the reasons and frustrations you've already outlined. :)
Finally, and this is the really difficult question: what are the
policy implications here?
Need there be? Certainly we should avoid annoying our users with
endless prompts AND we should avoid compromising our users by enabling
new forms of invisible tracking, but there's a healthy middle ground
of user choice that can be clearly understood and communicated
("Always use this certificate for this site") that seems to me,
perhaps naively, not to be overloaded on policy. What am I overlooking?
Cheers,
Johnathan
---
Johnathan Nightingale
Human Shield
john...@mozilla.com
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
