370804 - Add Bad Certificate Override manager as common code

Status: RESOLVED INVALID

(Core :: Security: PSM, defect)

Description

[Kai Engert (:KaiE:)]

This is a proposal to introduce a new dialog, similar to "install add ons" permission dialog, that could be used to configure sites that are allowed to use a bad cert.

The idea is, in order for end users to be able to connect to a bad cert site, they must proactively find this new manager and add their host.

I'm proposing to add this as common code to mozilla/security/manager, so every Mozilla application will be able to make use of it.

I would like to reuse existing permission manager code, and store the new kind of permission in the existing hostperm.1 file.

Unfortunately the current code seems to exist in two locations. browser+suite. And not in Thunderbird, although I would like to make it avaiable there, too.

So I'm probably going to copy.

Comment 1

[Kai Engert (:KaiE:)]

Attachment: Patch v1 - shared UI code - stolen from suite, slightly changed

Comment 2

[Kai Engert (:KaiE:)]

Attachment: Illustrating the changes to stolen shared UI code

Comment 3

[Kai Engert (:KaiE:)]

Attachment: Patch v1 - Add new button to Firefox prefs

Comment 4

[Kai Engert (:KaiE:)]

Attachment: Patch v1 - Add new button to Thunderbird prefs

Comment 5

[Kai Engert (:KaiE:)]

Attachment: Patch v1 - Add new button to SeaMonkey prefs

Comment 6

[Kai Engert (:KaiE:)]

Attachment: Patch v1 - change PSM to make use of the override list

Comment 7

[Johnathan Nightingale [:johnath]]

Hey Kai, thanks for getting this work underway.  A couple comments/questions, while I learn how to read patches again...

1) Is this bug intended to track the UI used to present these questions to the user (ref: email conversations about using error pages, and beltzner's thoughts about possible confirmation mechanisms) or should that be tracked in a separate bug?  If it should, does that bug exist yet?  And if it does, can we add the dependency?

2) Should this be a new top-level button on Prefs>Advanced>Encryption, or should it be part of the existing Certificate Manager dialog?  We are managing certificates after a fashion, and this does seem like a logical sibling of the other things in that tab.  

(Secretly, part of the reason for this question is that I'm a little worried we're going button crazy on the root Advanced>Encryption page, and while N-levels of nesting is bad, so is having to look multiple places for things.  If I hadn't read the patch and you asked me where this list would appear, I would have guessed the Cert Mgr.)

Comment 8

[Johnathan Nightingale [:johnath]]

3) If I read correctly here, the effect of declaring a bad cert as okay is that we will go back to presenting the standard "you are secure" message.  Is that appropriate, or should we consider the weaker version, namely, "If you okay this crazy thing, we'll stop error paging you, and we'll use the cert and all, but we still won't claim you're secure, because we're not so sure you are, we're just not nagging you about it."  I don't know, maybe that's over the top, but it seems odd for us to say "Error!  This cert is broken!" and then later say "Don't worry, you're safe!"  Thoughts?

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

Johnathan,  if I may interject,  

You may recall that, before the lock icon appeared in Netscape Communicator 4.0,
Netscape Navigator used a skeleton key icon.  It had 3 states: key absent, 
key present with one "tooth", key present with 2 teeth.  These were used to 
signal low and high strength encryption respectively.  Netscape got a new UI
czar for 4.0 and he was absolutely adamant that 3 states was one too many.
He thought that users would have enough difficulty understanding a two-state
icon, and 3 states was just going to be beyond most users' comprehension.  
He also forced us to stop using the term "private key" anywhere in the UI,
and always use the term "certificate" instead, which has caused no end of 
confusion for users.  

Now, fast forward to today.  UI people are calling for things like 
a) more icons, separately signifying the states of various aspects of the 
crypto security, e.g. one icon for encryption, one icon for authentication,
etc.  And there have been calls for representing 3 or 4 states of security
in UI icons.  

>From my viewpoint, it seems like this area is changing at the whims of the
UI czar-du-jour.  I hope mozilla products don't oscillate between presenting 
minimal states and finely detailed states.  

I completely agree with your point 3 in comment 8.  When the user overrides 
NSS and uses a cert that does not come from a trusted source, we should not
thereafter continue to show him signals that all is as secure as if he had
used a cert from a trusted source.  

Personally, I believe that users should NEVER be given the chance to override
an error caused by the detection of insecure behavior, with a single click, 
at the time it happens.  That's what we have today, and it has been well shown
that all it does is condition users to always click that override button, 
without thinking about it.  

At the time that the user encounters the bad cert dialog, he's typically not 
expecting it, and he reacts to it.  There's an obstacle in his way, and he 
wants to get past it with the override.  His decision is reactionary, not 
deliberate.  I think security overrides should always be done DELIBERATELY,
and should be done in a context of configuring the security parameters of 
the application.  IOW, it should be done in prefs, not in an error dialog.
The user should have to go there for that specific purpose, having thought
about it, and deciding that he's willing to take the risk.  He just won't
do that level of thought when trying to dismiss an error dialog.  

So if you agree, I think the challenge is to design reasonable UI for making
that deliberate choice after the fact.  

MSIE 7 has an interesting approach to this.  When the user gets a bad cert 
dialog, the user can click an override button, but it doesn't simply dismiss
the dialog.  It fires up Windows' cert import wizard, and makes the user go
through numerous pages of wizard to get to the final goal of having imported
the cert.  The user goes though the same steps as if he was importing the 
cert from a file on a local disk drive.  Then finally the user must manually 
re-visit the URL that triggered the bad cert error.  You can see screenshots 
of all 10 steps in the process at 
http://pics.rq.online.lt/index.php?folder=/screens/windows/ie7/

MAYBE all those steps will give the user time to think about what he's doing, 
but I think it will merely annoy the user, who will continue to be in 
reactive mode throughout the whole process.  

Comment 10

[Johnathan Nightingale [:johnath]]

(In reply to comment #9)
> You may recall that, before the lock icon appeared in Netscape Communicator
> 4.0,
> Netscape Navigator used a skeleton key icon.  It had 3 states: key absent, 
> key present with one "tooth", key present with 2 teeth.  These were used to 
> signal low and high strength encryption respectively.  Netscape got a new UI
> czar for 4.0 and he was absolutely adamant that 3 states was one too many.
> He thought that users would have enough difficulty understanding a two-state
> icon, and 3 states was just going to be beyond most users' comprehension.  
> He also forced us to stop using the term "private key" anywhere in the UI,
> and always use the term "certificate" instead, which has caused no end of 
> confusion for users.  
> 
> Now, fast forward to today.  UI people are calling for things like 
> a) more icons, separately signifying the states of various aspects of the 
> crypto security, e.g. one icon for encryption, one icon for authentication,
> etc.  And there have been calls for representing 3 or 4 states of security
> in UI icons.  
> 
> >From my viewpoint, it seems like this area is changing at the whims of the
> UI czar-du-jour.  I hope mozilla products don't oscillate between presenting 
> minimal states and finely detailed states.  

Just so I'm clear, I am absolutely not recommending a return to a lock with three states in this bug.  I can understand why it may look like whim-of-the-czar to have things changing back and forth, but I am not suggesting changing back in any way.  I think the change away from "counting teeth" and the terminology change, while they blur technology distinctions in a way that can be tiresome, were both probably good changes to make, based on accepted usability heuristics and based on an understanding of our typical user and their typical goals and understanding.

Perhaps this comment came from my mention of a "weaker" stance in #3?  If so, I didn't mean weaker to imply a third state, rather, as I think the rest of the comment illustrates, I meant to say "let's weaken the treatment of bad-but-overridden certs so that they appear as insecure, not secure."  I wasn't advocating a third state, and while I do think that we need a richer signalling system around trust on the internet, it's out of scope for this bug, and still incubating.

> At the time that the user encounters the bad cert dialog, he's typically not 
> expecting it, and he reacts to it.  There's an obstacle in his way, and he 
> wants to get past it with the override.  His decision is reactionary, not 
> deliberate.  

Right.  Basically we all think Gutmann ( http://www.cs.auckland.ac.nz/~pgut001/ ) is dreamy.  :)

> I think security overrides should always be done DELIBERATELY,
> and should be done in a context of configuring the security parameters of 
> the application.  IOW, it should be done in prefs, not in an error dialog.

I suspect that everyone agrees that this is a choice that needs to be automation-resistant.  The discussion will no doubt revolve around whether prefs are the appropriate mechanism for that.  But that is the purpose of my Question 1 above - is this the bug for that?  I think Kai means this bug to track only the introduction of the preference dialog functionality, and not to also encompass the UX of actually visiting such a page.

Before we have a design discussion which is out of scope, I'd like to hear Kai's thoughts on this.

Comment 11

[Kai Engert (:KaiE:)]

I think a lot has changed since we wrote the above comments, in fact, we see much clearer now on what we want.

I believe this bug and its patch is now obsolete, because our latest thinking is: The override should NOT be simply on the host name. Instead, we want the override to be tied to a specific {host, port, cert} triple.

This is what is currently being implemented in bug 327181.

Comment 12

[Johnathan Nightingale [:johnath]]

My first bugzilla interactions with Kai and Nelson, and the first time Gavin and I shared a cc list -- quite a heartstring tugger!

Also, Kai was right 5 years ago, this bug is obsoleted by other approaches that started in bug 327181 - closing this one. It's a little bit WONTFIX, a little bit INVALID, and a little bit DUP. INVALID it is!