380775 - Make general page of certificate viewer easier to understand

Status: RESOLVED WORKSFORME

(Core :: Security: PSM, defect, P3)

Description

[Johnathan Nightingale [:johnath]]

Attachment: Cert viewer, current and mockup for new proposal

Certificates are a very technical subject and we don't anticipate users walking the tree of cert properties as part of their day-to-day browsing.  We do, however, launch the certificate viewer from the browser in various places as a way for users to "Verify the certificate."  

This leads to things like bug 337392 which are really just the result of frustration, because the current cert viewer UI is not optimized for the case of a non-expert user trying to make a trust determination.  

I propose changing the general tab as presented in the attachment, so that the information more neatly anticipates this scenario.  Emphasis is placed on the subject and issuer particulars, and taken away from x509 details like fingerprints (still present, but with some descriptive text) and prescribed usages. 

I'm not proposing any changes here to the details tab, which I expect only experts to interact with anyhow.

I'm fine to do the actual XUL work to make this happen, so Kai, Nelson, and others shouldn't feel like this dev work being thrust upon them.  :)

Note that I include things here like policy URLs which are likely to be absent in many certs - the intent would be to fail quietly on fields that aren't specified, and show what we can in the sequence presented.

This also addresses Firefox 3 line item: SPI-001f

Comment 1

[Jesse Ruderman]

Do the serial number and fingerprints need to be on the General tab?

Comment 2

[Johnathan Nightingale [:johnath]]

Right, so that's a good question.

Fingerprints I left on in the mockup because I'm expecting the only time non-experts go in here is when they have been prompted to "verify the certificate" and fingerprints are the supposed primary mechanism for verification.  That doesn't mean anyone does that, but it felt a little weird to bury them, given that imagining of this tab's purpose.

Serial number though, I think is a good candidate for removal.  I left it in according to much the same logic as above, but unlike fingerprints, it's not a reliable verifier, and it is daunting-non-human-language looking.  There's a reason serial numbers go on the bottom of real world products - you rarely care.  :)  

I'd be fine to remove it from the tab.  

Looking at it again, I'm also considering removing Issued date, since it doesn't  seem to me to matter very much. It's there reflexively for parity with expiry date, but whereas expiry date can indicate important information, I'm not sure issued date does.  If it's in the past, it doesn't really matter.  If it's in the future then technically the site shouldn't be using it, but a) do CAs issue future-dated certs very often?  b) What is the attack here, that we would be preventing by displaying this information?

I guess if it was FAR in the past, it could be a warning that the information is likely to be stale, but I don't know if that's compelling enough.  Maybe the fact that it doesn't take up space (sharing a line with expiry) and isn't hard to understand argues for erring on the side of keeping it in, but I'm not sure I'm convinced.

Comment 3

[Kai Engert (:KaiE:)]

IIUC, bug 337392 is about a UI prompt that we want to disable in the future. We would like to disable access to incorrectly configured and/or untrusted sites and make it harder for users to override.

That bug seems to indicate that users are confused and probably will proceed anyway, if the cert claims to belong to the one they want to connect to.

I think what bug 337392 asks for is a link for more information.

So maybe the cert viewer dialog should have a "help" button that opens a help page that very briefly explains what makes a cert usually a valid and trusted cert (issued by an authority trusted by mozilla.org of by the user) that has proven to mozilla.org that it follows the guidelines on identifying an entity).

I'm not sure if removing information from this dialog will assist the user in making the right decision about its trustworthyness.


I appreciate your plan to clean this up and make the dialog more easier to understand. Some food for thought:


The "issued on date" helps you to answer questions like "is this really the personal cert that I just installed"?

Issuer name and serial number are the primary key of a certificate.
If someone wants to quickly identify a cert, that will be the field they look at.

Maybe the serial number should be displayed in the "issued by" section like (because the issuer issed the cert as its serial number ...)

Maybe there is a way to still display the serial number, but show it with less spacing and without a bold heading, like next to the policy URL.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

There are lots of issues with this display.  If we're going to rework it,
let's try to address the known issues, please.  

1. Let's show the user the RIGHT NAMES from the cert.

   Certificates have optional "Subject Alternative Names" (SubjectAltNames, 
   SANs for short). These optional parts of a cert are called "extensions".  
   The RFC that defines https says that if an https server cert contains an 
   SAN extension, then the names and addresses in that SAN must be used as 
   THE (only) server names for host name matching.  A SAN extension may 
   contain any number of host names and IP addresses.  If the SAN is NOT 
   present, then the single most-specific old (non-standard) Subject Common 
   Name (CN) may be used.  That means that when SANs are present, we ignore 
   the Common Name for host name matching purposes.  Also, the Subject Name
   (which commonly contains the CN attribute) may be EMPTY, in which case
   the subject's real name is in the SAN, and must be displayed from there.

   But this UI always displays only the common name, and never the SANs.
   Again, when SAN's are present, they should be shown EXCLUSIVELY as the 
   relevant host names.  The display should show the same names that the 
   software actually uses for name matching purposes.  (Note, this applies
   only to the host names, not to the other name attributes, such as 
   organization name, org unit name, locality, State, etc.)

   These bugs address this issue: Bug 344817, Bug 338419,  Bug 238142

2. When a cert fails to verify, this dialog now says "for an unknown reason"
rather than telling what the reason is.  The reason code is available, and is
very specific, and is useful for diagnostic purposes.  When FireFox says a 
cert doesn't verify, the server admin should have to do nothing more than try 
it in FireFox to see an explanation of the problem for himself. Our software should tell the server admin why the cert did not verify.  The server admin 
should not have to write to us (or file a bug) to get the answer.
These bugs address this issue:  Bug 183371, Bug 265873, Bug 289988

3.  At one time, it was true that this dialog would report that the cert 
was unverified for an unknown reason UNLESS that cert was trusted as an 
issuer of EMAIL certs.  Without email usage, the display would say invalid.
So an SSL-only CA, or a code-signing-only CA would report as unverifiable.  
That's bug 289988.  We should fix it, if it's still a problem.

4. If the certificate does not verify, and hence is not provably issued by 
one of the CAs we trust to tell us the truth, then we should not display 
its contents as if they were gospel truth.  We should not say "This cert 
belongs to" and "This cert was issued by" if those are unproven statements.
We probably should seriously caution the user, with words like "This cert
PRETENDS to belong" or "makes the unproven claim that it was issued", or
perhaps "This cert might or might not belong to",  or "the true owner and
issuer of this cert are unknown, and may not be the parties named herein."

Otherwise, users will "confirm" or "verify" the cert simply because it 
contains the name they expect it to contain, even if it was falsified.

Comment 5

[Jean-Marc Desperrier]

About 1 : For SSL server cert, if the certificate is valid then the name has to be the same as the name of the site currently accessed. It would be good to display the relevant one when a server or a mail signing cert contains several identities.

About 4 : Why not just remove then most of what is displayed in the "general" tab and replace it with the description of what kind of problem there is with the certificate ?

One more point : We don't anticipate either users to check the complete tree up to the root CA. So wouldn't it be good when there's several CA level to indicate what the initial trust point (the root) is ?

Mock up :

This certificate is issued by :          Acting on delegation from :
Private company XXXX                     XRamp Security Services Iinc
Town                                     San Antonio
Country                                  Texas
http://                                  http://

It would be necessary to identify cases where the intermediate cert is in fact the same company as the root.

Comment 6

[Gervase Markham [:gerv]]

We also have a question of authority here - the same question we have when deciding how and in what way to populate Larry the Passport Guy's dialog. IMO, to be consistent, we should only be showing company name and address information from EV certificates. In fact, question: how is this dialog different from Larry's dialog?

In the non-EV case, we should just say:

This certificate is owned by:
www.mozilla.org

The issue date _might_ be useful because, if it's really recent, that might be a "Hmm" point for suspicion. But perhaps too few users would say "Hmm" to make it worth keeping.

We should ditch the MD5 fingerprint, or relegate it to another tab - I've been finding that no-one uses it any more. And yes, ditch serial number.

Let's see if we can find better text for the names of the permission bits.

Also, the fingerprints don't "prevent tampering" so much as identify the cert. Perhaps "Each certificate has a unique fingerprint which can be checked to make sure the right one is being used. If you have been given a fingerprint, compare it with this:"
or similar words.

Gerv

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

As long as the serial number remains in the "detail" tab, I agree that it's
of no interest to most users.

Comment 8

[Kaspar]

(In reply to comment #6)
> The issue date _might_ be useful because, if it's really recent, that might be
> a "Hmm" point for suspicion.

Or when the cert has been issued 8 years ago - another situation for a "Hmm" point. As there are now CAs issuing certs with a 10-year validity, I would not drop the notBefore date.

Also, it might be worth considering to add the time of the validity also on this tab (i.e. use nsIX509CertValidity's notAfterLocalTime instead of notAfterLocalDay), since in case of expiration, the user might get an error about an expired cert already during the last day of its validity (the cert for *.mozilla.org e.g. will expire on 2008-01-05 05:40:19 GMT already).

Comment 9

[Eddy Nigg (StartCom)]

One of the things which should be improved, are in my opinion access to the details itself. This means, hovering over the padlock should reveal the most important bits, with one click action on it presenting the full subject line and issuer in question. Additionally some "hint" about the nature of the certificate would be interesting if this is possible. Certainly details about, if self-signed/temporary accepted versus signed by a CA trusted by the user (i.e. explicit imported CA or built-in) should be included.

I don't agree with Gerv concerning the removing of the subject line - specially since there is no design yet for EV certs, if at all. The subject line are the most important details included in an x.509 certificate, about one must know in order to build an opinion about a certain site (Same is true for client certs of course). Easier access to the most important information might raise awareness by the casual user and help to build better understanding in the long run.
More than that, I suggest to provide easy access to the CA policy if present in the X509v3 Certificate Policies extension (Quick Button). 

Concerning the post made by Kaspar: So this is off-topic, it should be brought up perhaps on the mailing list and something for consideration for the Mozilla CA policy. But there is no way a CA can issue a certificate to the end user with a strait face for 10 years. Not even five or three, because during this time a domain name might change owners, but names and addresses of the holder as well. Potentially one could buy a popular domain name, receive a certificate for 10 years and let the domain expire. Whoever picks that domain name during the next  10 years can effectively spoof the new domain owners site.

Comment 10

[Johnathan Nightingale [:johnath]]

Attachment: Initial visual re-org

Here's a patch that cleans up the visuals to look less like name=value and more like human readable information.  It also adds a large warning icon to draw attention to validation errors, when they occur.  

It doesn't account for many of the suggestions Nelson made around fixing the way this data is presented (e.g. choosing the right domain name).

Comment 11

[Johnathan Nightingale [:johnath]]

Attachment: screencap of presentation with patch

Comment 12

[Johnathan Nightingale [:johnath]]

Attachment: presentation with patch on broken cert

Comment 13

[Eddy Nigg (StartCom)]

Johnathan, why did you move the warning icon and message to the bottom? This shouldn't be IMO.

Comment 14

[Bob Lord]

Any update on this proposal? 

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

This bug covers a multitude of problems with the cert manager's cert viewer.
Perhaps the most well known of them is bug 91403.  
I'm marking this bug as depending on that other, 7 year old bug.

Comment 16

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

The certificate viewer got reimplemented.