891665 - Remove the "General" tab of the certificate viewer

Status: RESOLVED WONTFIX

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

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Attachment: Screenshot showing harmful parts of the "General" tab of the certificate viewer

I propose that we completely remove the "General" tab of the certificate viewer as follows:

0. Move the "This certificate has been verified for the following uses" section to the details tab (see bug 450557).
1. Remove the "General" tab so that only the "Details" tab exists.
2. Move the contents of the "Details" tab to the encompassing dialog box so we can remove the tabs themselves.

I have attached a screenshot where I circled all of the parts of this tab that are **BAD** (not just "not good") for security. Notice that most elements of the tab are circled.

This would solve the following problems:

0. The "General" tab only shows one level of issuer. This doesn't account for important attack scenerios:
    Trusted Root CA -> Stolen Intermediate -> Verisign, Inc. -> mozilla.org.
    Untrusted Root -> Verisign, Inc. -> mozilla.org

In these scenerios, the dialog will show the certificate as being issued by Verisign even though it was really issued by an attacker. To the extent that the user has any hope of understanding these issues, the "details" tab more clearly shows the problem through the Certificate Hierarchy box.

1. The "General" tab shows the Organizational Unit (OU) field for both the end-entity and the issuer. The OU field is commonly abused by CAs to include policy information such as "Domain Validation Only" or disclaimers/legalize like "www.entrust.net/rpa is incorporated by reference." Besides being misleading and confusing to users, this wastes valuable space in the certificate. Such wastage of space adds up such that it is actively slowing down the adoption of OCSP stapling and other features that are actually important, due to performance concerns. My hope is that by removing this from the easily-accessible parts of our UI, we can convince other browsers to do the same, and remove the incentive that CAs have for including such wasteful and misleading statements in the OU field. (CAs have explicitly indicated that they abuse this field intentionally because we don't show the "certificate policy" field in the primary UI, which is also something we shouldn't do due to the same size/performance concerns.)

2. This tab prominently shows the MD5 fingerprint of the certificate, which is not a secure way to authenticate a certificate even if we accept the extremely uncommon scenerio of a user that understands and cares about fingerprints.

3. The General tab shows the Organization field of the certificate for non-EV certificates, even though we've made a deliberate decision to avoid showing the Organization field for non-EV certificates elsewhere (the address bar and Larry's doorhanger, in particular). By eliminating the general page, we remove the main cause of the inconsistency in the most efficient way.

4. Really, users generally have no hope of deciphering the information on this page, and for the very few that can, the precision and comprehensiveness of the details tab is superior to the presentation in the "General" tab.

5. This tab slows down access to the "details" tab for developers who are debugging certificate chain issues.

6. Neither Fennec nor B2G have any UI ("Details" or "General") for this, which means that users cannot even view the certificates at all when they want to add cert error exceptions on those platforms. In some ways, this indicates that viewing the General page is not critical for the purpose of deciding to add certificate exceptions. But, even if it is important, then the other issues (issue 0 in particular) motivate a display more like the "Details" tab.

Note that my primary motivation here is the removal of the "Organizational Unit" (OU) field for non-EV certificates, because I am working on guidelines to propose to CABForum about omitting useless and/or omitting information from certificates in order to make certificates smaller so that there is "room" in the SSL handshake for OCSP stapling. I believe removing this field from our UI (except for the details tab) will help motivate CAs to stop this abuse.

Note that this bug is in direct contradiction to bug 380775 which suggests making the "General" tab more usable. The heart of my argument here, and against bug 380775, is that the certificate viewer is really only useful for experts and a friendlier presentation of the information present in the UI would be counter-productive.

Comment 1

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

I just saw that Firefox for Android implemented the "General" tab but not the "Details" tab. It uses its "General" certificate details dialog for the "view cert" part of the "Import CA" function. You can see this by clicking on this link and then clicking the "view" button on dialog box that comes up:
http://www.cacert.org/certs/root.der

So, even if we remove the General tab on desktop, we can't remove any of the strings for the details tab until we've done the same for Android.

Comment 2

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Attachment: After vs. Before

1. I combined the two tabs into one tab, removing the redundant/misleading information in the "General" tab.
2. For the certificate usage section at the top, I use non-breaking spaces within each list item so that a single usage is never wrapped across two lines, and separate them with ", " so that they wrap.
3. I removed the **Boldness** from the headings. I could not find any other places in the Firefox UI where bold was used the way it was used in this dialog before.
4. I shrank the bottom "value" field so that the new version of the dialog would be the same size (actually a little smaller) than the old, because I didn't know how big was too big so I wanted to play things safe.

Comment 3

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Attachment: Remove the "General" tab from the FxDesktop certificate viewer

Comment 4

[Gervase Markham [:gerv]]

In general, I approve :-)

The validity range is useful in the reasonably common case of expired certs; can we have a:

Validity range: 20/02/1999 - 30/04/2013

line below the "uses" line? For bonus points, make the dates turn red if we are outside the range.

Can we come up with better strings for the uses - so "Identifying Servers" instead of "SSL Server Certificate" and "Signing Other Certificates" instead of "SSL Certificate Authority"?

Gerv

Comment 5

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Gervase Markham [:gerv] from comment #4)
> The validity range is useful in the reasonably common case of expired certs;
> can we have a:
> 
> Validity range: 20/02/1999 - 30/04/2013
> 
> line below the "uses" line? For bonus points, make the dates turn red if we
> are outside the range.

If the certificate is already expired, or if it has any other problem that causes it to fail to validate, then the "usages" section will be replaced with an error message. In the case of expiration, the message is "Could not verify this certificate because it has expired."

Notice that the "Validity" part of the "Certificate Fields" tree is above the fold. So, one thing we could do is change that part of the "Certificate Fields" tree to show the validity dates:

Before             After 
---------------    ---------------
   Validity        Not Before 1/2/2012
     Not Before    Not After 7/31/2013
     Not After

> Can we come up with better strings for the uses - so "Identifying Servers"
> instead of "SSL Server Certificate" and "Signing Other Certificates" instead
> of "SSL Certificate Authority"?

I'd be happy for somebody to put forth a concrete proposal for that, but that's outside the scope of this bug. I did not change those strings as part of this patch.

Comment 6

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Brian Smith (:briansmith), was [e-mail] (:bsmith) from comment #5)
> If the certificate is already expired, or if it has any other problem that
> causes it to fail to validate, then the "usages" section will be replaced
> with an error message. In the case of expiration, the message is "Could not
> verify this certificate because it has expired."

NOTE TO SELF: Make sure that this continues to be displayed. I may need to move this text to the new <description> element I added.

Comment 7

[Kathleen Wilson]

Brian, I'm glad to see these changes!

Would you please still keep the Sha1 Fingerprint? 
The Cert Viewer interface is used both when clicking on the lock icon and also from the Certificate Manager. It can be difficult to distinguish between some root certs, so the SHA1 Fingerprint helps a lot. I think it would be fine if a Sha1 Fingerprint field was included in the "Certificate Fields" list, and had to be clicked on to be viewed.
While doing this, can you also add the SHA256 Fingerprint? (bug #622332)

Regarding date, the Not Before and Not After fields display two different dates, e.g.
3/22/15 3:27:17 
(3/22/15 10:27:17  GMT)
So if you do decide to display a date in the initial view, please use the GMT date, because the date in the first row sometimes causes confusion.

I use the "Cert Viewer Plus" add-on, so I am wondering if that add-on will break with these changes. Or maybe it won't be needed anymore? I've been using that add-on for so long that I may not be remembering correctly, but I believe it is this add-on that makes the SHA1 Fingerprint copy-paste-able, and shows which trust-bits are enabled for each cert in the hierarchy (I use these two features a lot).

Thanks!
Kathleen

Comment 8

[Larissa Co [:lco]]

Your fundamental assertion is that the Certificate Viewer is useful only for experts, therefore we should focus only on the features that will help them diagnose issues, and remove information that could mislead novices who stumble into this UI. I'm not opposed to that, but I'd like to make sure that assumption is correct.

Are there any use cases in which a novice might have to interact with the Certificate Viewer? And if there are, what are the likeliest things they want to do here? And will they have any guidance (e.g. articles, experts) helping them do what they need to do?

Reducing the amount of stuff and simplifying down to one tab is great for usability, but I also want to make sure it's not at the expense of usefulness. Since I'm not an expert on the use cases here, would it make sense to make this discussion more visible on a mailing list?

Comment 9

[Larissa Co [:lco]]

And one quick question-- Why does the Larry Menu say that the website doesn't supply any ownership information when there are details that look very "ownership-related" in the Cert Viewer? I think this might be very confusing for someone who isn't an expert but somehow stumbles upon the Cert Viewer. I'm not saying we should change it, I just want to understand the decision.

Comment 10

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Larissa Co [:lco] from comment #8)
> Are there any use cases in which a novice might have to interact with the
> Certificate Viewer? And if there are, what are the likeliest things they
> want to do here? And will they have any guidance (e.g. articles, experts)
> helping them do what they need to do?

As an educated guess, here are the main reasons why an end-user would deal with the certificate viewer:

1. They have encountered a certificate error and they are trying to fix it themselves. In this scenerio, it may be helpful to know the validity dates and the "Certificate Subject Alt Names" (the list of domain names for which the certificate is valid). We already show this information on the cert error page:

* "The certificate expired on $DATE1. The current time is $DATE2."
* "The certificate is only valid for the following names: $NAME1, $NAME2, $NAME3"

2. They are trying to install a certificate that their IT people have asked them to download and install. In this case, *in theory* the SHA1 fingerprint would be helpful. We could add this fingerprint to the "Certificate Fields," at the top (above the fold) for people who care about it.

3. They are using a client certificate to authenticate themselves to a (rare) server that requires such certificates to be used. In this case, the information needed to disambiguate certificates is shown in the client certificate chooser dialog box. (If things are still ambiguous given the information shown in that dialog, then the user would likely need to deep dive into the certificate details.)

4. Thunderbird S/MIME certificate stuff. Thunderbird may want to keep the old style of dialog box.

> Reducing the amount of stuff and simplifying down to one tab is great for
> usability, but I also want to make sure it's not at the expense of
> usefulness. Since I'm not an expert on the use cases here, would it make
> sense to make this discussion more visible on a mailing list?

What do you think would be a good forum? firefox-dev?

Comment 11

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Larissa Co [:lco] from comment #9)
> And one quick question-- Why does the Larry Menu say that the website
> doesn't supply any ownership information when there are details that look
> very "ownership-related" in the Cert Viewer? I think this might be very
> confusing for someone who isn't an expert but somehow stumbles upon the Cert
> Viewer. I'm not saying we should change it, I just want to understand the
> decision.

I agree, and that's one of the biggest motivations for making this change.

Also, see bug 444980, where we will (most likely) remove this "does not supply ownership information" string.

Comment 12

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Kathleen Wilson from comment #7)
> Would you please still keep the Sha1 Fingerprint? 

We can put the SHA1 fingerprint in the "Certificate Fields" list, like you suggest.

> While doing this, can you also add the SHA256 Fingerprint? (bug #622332)

Let's keep that as its own separate bug.

> Regarding date, the Not Before and Not After fields display two different
> dates, e.g.
> 3/22/15 3:27:17 
> (3/22/15 10:27:17  GMT)
> So if you do decide to display a date in the initial view, please use the
> GMT date, because the date in the first row sometimes causes confusion.

I will look into this. We should be formatting these dates consistently throughout the product.

> I use the "Cert Viewer Plus" add-on, so I am wondering if that add-on will
> break with these changes. Or maybe it won't be needed anymore? I've been
> using that add-on for so long that I may not be remembering correctly, but I
> believe it is this add-on that makes the SHA1 Fingerprint copy-paste-able,
> and shows which trust-bits are enabled for each cert in the hierarchy (I use
> these two features a lot).

If we add the SHA1 fingerprint to the "Certificate Fields" then it should become copy/pastable.

Kaspar, I suspect that this change may cause you some inconvenience in that you will probably need to tweak your Cert Viewer Plus extension. Do you forsee any problems with making this change?

Comment 13

[Kaspar]

(In reply to Brian Smith (:briansmith), was [e-mail] (:bsmith) from comment #12)
> (In reply to Kathleen Wilson from comment #7)
> > Regarding date, the Not Before and Not After fields display two different
> > dates, e.g.
> > 3/22/15 3:27:17 
> > (3/22/15 10:27:17  GMT)
> > So if you do decide to display a date in the initial view, please use the
> > GMT date, because the date in the first row sometimes causes confusion.
> 
> I will look into this. We should be formatting these dates consistently
> throughout the product.

The date in the first row wouldn't cause confusion if the time zone is also included. Unless you also intend to change the date/time which is displayed on the cert error page (cf. comment 10), I would warmly recommend to *not* drop the local date/time here.

> If we add the SHA1 fingerprint to the "Certificate Fields" then it should
> become copy/pastable.

Not really a good place to place the fingerprint under. "Certificate Fields" should be limited to those things which are really included in the certificate, and not display synthesized metainformation (see also bug 400036 comment 2, where this mistake happened with the EV status).

> Kaspar, I suspect that this change may cause you some inconvenience in that
> you will probably need to tweak your Cert Viewer Plus extension. Do you
> forsee any problems with making this change?

Depends on what other changes (besides dropping the "General" tab) you're intending to apply. I guess I'll have to wait and see, and then decide on whether I want to continue to maintain this as a public extension. The lack of responsiveness when proposing PSM patches in the years 2007-2012 (see e.g. bug 408547) was certainly no incentive to invest more time in improving the built-in features of the certificate viewer (like bug 315871 did, which took more than a year to get it in, finally).

Comment 14

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Attachment: Misleading or wrong information in the "General" Tab

"Issued on" is also misleading, since the certificate might have been issued before or after that date, based on backdating or forward dating by the CA. I updated the image that shows the wrong and misleading information in this tab to take that into account.

Comment 15

[David E. Ross]

Re comment #8:  

I am an end-user; I am also a retired software test engineer.  I sometimes encounter a SSL problem.  I want to see the chain from the site certificate through ALL intermediate certificates up to the root.  I also want to see the "Not Before" and "Not After" dates and the Issuer.  In the past, I have used some or all of this to notify the site certificate owner that it has a problem.  

I would request that Mozilla stop trying to protect its users by dumbing down its user interfaces.

Comment 16

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to David E. Ross from comment #15)
> I am an end-user; I am also a retired software test engineer.  I sometimes
> encounter a SSL problem.  I want to see the chain from the site certificate
> through ALL intermediate certificates up to the root.  I also want to see
> the "Not Before" and "Not After" dates and the Issuer.  In the past, I have
> used some or all of this to notify the site certificate owner that it has a
> problem.  
> 
> I would request that Mozilla stop trying to protect its users by dumbing
> down its user interfaces.

What you want is exactly what this bug is about doing. See the "After vs. Before" screenshot attachment.

Comment 17

[Jan]

Attachment: Mockup of certificate UI with details shown directly in list

This change would require two additional clicks to read just the validity period, and an additional click for every other value. To avoid this, I propose showing the details in the list itself to the extent they fit (see attached mockup). This will make it possible to see the most important information at a glance while still keeping the "details" tab as the only tab. For fields that don't fit, the user will be able/required to click on the field to view the full text, as before.

The end-entity certificate should be visibly selected by default in the top list and thus its details should be shown when the dialog opens. (I think we currently don't do the highlighting.)

In addition, we need to somehow show the fingerprint, which was only available on the first tab so far. Unlike for the other values, I think we should *not* show a truncated fingerprint. I'd suggest showing the fingerprints in the "value" box if the user selects the certificate itself (i.e. if the user clicks on the certificate in the hierarchy box, or on the top line of the certificate layout box). Consequently, the fingerprint would be shown by default as the dialog opens. Thus, most of the information currently available on the "general" tab would be immediately available in the new UI.

We could add a "click here for fingerprint" note in gray behind the first line of the cert detail tree.

We could additionally show the fingerprint when the "certificate" line is selected and add the note there. This has the advantage that there will always be space for the note, however it is slightly misleading, since the "Certificate" line represents the tbsCertificate while the fingerprint is calculated over the entire cert. Showing the note in the first line (which seems to be a CN summary) would be better, but that one can sometimes already span the entire width of the dialog.

Comment 18

[SresthaSrivastava [:srestha]]

Hey, can I take this up?

Comment 19

[Dana Keeler (she/her) [:keeler]]

We reimplemented the certificate viewer and won't be continuing to develop the old one.