421341 - Make Certificate Viewer labels' content selectable

Status: RESOLVED DUPLICATE of bug 932116

(Core Graveyard :: Security: UI, defect)

Description

[Andrés Delfino]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008030610 Minefield/3.0b5pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008030610 Minefield/3.0b5pre

IMO, labels' contents should always be selectable, so users can easily use that information if they need.

Reproducible: Always

Comment 1

[Jo Hermans]

see bug 200621, also that only speaks about the fingerprints.

Comment 3

[Daniel Veditz [:dveditz]]

bug 435539 comment 0 has a longer argument about why this should be so. It's not a conspiracy to make that information non-copyable, just a bug.

The information on the "Details" tab is copyable, and mostly the same information. The Fingerprint, though, only appears on the General tab since that's something we calculate, not data embedded in the cert itself, and if you wanted to copy a bunch of data the arrangement of info in the General tab is convenient.

This is not new in FF3, the problem exists in FF2 and probably since this dialog was created.

Comment 4

[L A Walsh]

But it's not the fingerprint that's at issue -- it's the _variable_ content
on the 'general' tab that is at issue.  It's not a label (though the labels need to be copyable along with the data -- otherwise, you don't know what you are looking at).

As for the Details page...grrr...gimmee a break.  The "ability" to copy info from the 'details' tab is a joke!  In order to get the "labels" for each of the data fields (there were 20 fields with data on the cert I looked at, and an additional 4 labels that had no associated data).  But do you really expect people to manually cut and paste 40 separate fields?  Uh....that sounds like non-consensual sadism in my book...;^/

The data on the detail page should be save-able in 1 operation either copied to
the clipboard or save-able to a file in a user-readable form, but 
copy/paste -- 40 times?  Torture!

Comment 5

[Kai Engert [:KaiE:]]

law: I have a workaround for you: In Cert viewer, click the advanced tab and use the "export" feature, and save the cert to a file. Then you can use software specialized on cert processing to produce the format you desire.

Comment 6

[Daniel Veditz [:dveditz]]

(In reply to comment #4)
> But do you really expect people to manually cut and paste 40 separate
> fields?  Uh....that sounds like non-consensual sadism in my book...;^/

Of course not, that's why I confirmed it as a bug.

Until fixed, copying from the Details tab would help some people since in most problem cases you're not going to need all the fields. If you do you probably should export the whole cert as Kai suggested, because if you need all that much data then it isn't all available on the General tab either.

Comment 7

[Cees T.]

Depends on bug 123170 – Implement selectable labels.

Comment 10

[Alain Knaff]

Bug still present in 5.0

If/when this is fixed, please try to fix it globally (i.e. _all_ dialogs' fields should be selectable)

Comment 11

[Tom Lowenthal]

The importance of this bug should be elevated in light of the decreased trustworthiness of the CA PKI.

Comment 12

[Matt McCutchen]

(In reply to Tom Lowenthal [:StrangeCharm] from comment #11)
> The importance of this bug should be elevated in light of the decreased
> trustworthiness of the CA PKI.

Realize that under the same-origin policy, inspecting the certificate via the site identity button is useless as a security measure.  It is for diagnostic purposes only.

Comment 13

[Alain Knaff]

(In reply to Matt McCutchen from comment #12)
> (In reply to Tom Lowenthal [:StrangeCharm] from comment #11)
> > The importance of this bug should be elevated in light of the decreased
> > trustworthiness of the CA PKI.
> 
> Realize that under the same-origin policy, inspecting the certificate via
> the site identity button is useless as a security measure.  It is for
> diagnostic purposes only.

Could you elaborate? Does this also apply to the "View certificate" button in the "Add exception" workflow that pops up when a self-signed certificate is encountered? Should we maybe fix the "same-origin policy" to make the certificate display reliable?

Indeed, many people live under the assumption that self-signed certificates can be safe if the browser user verifies their SHA1 fingerprint against a trusted source (such as business card handed to them by website operator, or confirmation over the phone). If a fingerprint match cannot be trusted due to "same-origin" policy, this would be rather bothersome...

Comment 14

[Matt McCutchen]

(In reply to Alain Knaff from comment #13)
> (In reply to Matt McCutchen from comment #12)
> > Realize that under the same-origin policy, inspecting the certificate via
> > the site identity button is useless as a security measure.  It is for
> > diagnostic purposes only.
> 
> Could you elaborate?

To avoid going further on this tangent here, I've filed bug 687764 with the explanation.

> Does this also apply to the "View certificate" button
> in the "Add exception" workflow that pops up when a self-signed certificate
> is encountered?

No, in that case you're adding an override for the exact cert you see, and are still exposed to anyone who can pass the default acceptance test.

> Should we maybe fix the "same-origin policy" to make the
> certificate display reliable?

If you have a comprehensive solution that doesn't break the web, I'm all ears (in a separate bug).

Comment 15

[Alain Knaff]

(In reply to Matt McCutchen from comment #14)
> To avoid going further on this tangent here, I've filed bug 687764 with the 
> explanation.

Sorry to continue replying here, but as the argument seems to be given as a reason not to address this bug here (#421341), other readers here should see it.

In summary your argument boils down to saying that a badly set up SSL web site may compromise security (such as including unencrypted elements, or elements from third party sites such as googleapis, or sites reusing the same session cookie over encrypted and unencrypted pages). While true, I feel how this is particularly relevant to self-signed certificates. CA-validated certificates suffer from the same issue, as proven by the Firesheep extension which snoops non-SSL cookies from Facebook.

> No, in that case you're adding an override for the exact cert you see, and 
> are still exposed to anyone who can pass the default acceptance test.

I'm pretty sure that if an SSL site includes data from other SSL sites, you'll get certificate warnings for _all_ elements, if appropriate.

> If you have a comprehensive solution that doesn't break the web, I'm all ears 
> (in a separate bug).

Actually, many browsers do warn if an encrypted page contains non-encrypted elements. And a security-savvy webmaster will avoid doing this, for this exact reason. And its not as if a man-in-the-middle could introduce such elements in pages where there were none originally, as that would break the top-level cert.

In any case, as you say, this is a tangent, as CA-validated certificates suffer from the exact same problem. So why should this be used as an argument to not make certificate fingerprint display more user friendly?

Comment 16

[Tom Lowenthal]

(In reply to Matt McCutchen from comment #12)

Inspecting the fingerprint of a certificate and manually comparing it to a known good value (say, by confirming it with the operator over a side channel) is a valid and reliable mechanism which can be used as a trust anchor for that certificate outside the PKI. The inability to select and copy details from the certificate viewer impairs a user's ability to do just this.

The critical use case for this feature is not inspecting a certificate which has already been trusted, it is for determining the validity of a certificate which is not automatically trusted, perhaps because the user has chosen not to generally trust the root CA.

TL;DR: notwithstanding anything else, a user should be able to select and copy important text like certificate fingerprints.

Comment 17

[Matt McCutchen]

(In reply to Tom Lowenthal [:StrangeCharm] from comment #16)
> Inspecting the fingerprint of a certificate and manually comparing it to a
> known good value (say, by confirming it with the operator over a side
> channel) is a valid and reliable mechanism which can be used as a trust
> anchor for that certificate outside the PKI. The inability to select and
> copy details from the certificate viewer impairs a user's ability to do just
> this.
> 
> The critical use case for this feature is not inspecting a certificate which
> has already been trusted, it is for determining the validity of a
> certificate which is not automatically trusted, perhaps because the user has
> chosen not to generally trust the root CA.

Agreed.  Your comment 11 confused me.

Comment 18

[Nikolay Edigaryev]

It's been over 2 years since 5.0 came out, but the bug is still present in 23.0.1.

Comment 19

[Ryan Pearl [:rpearl]]

Attachment: Make all fields in the viewCert window readonly textareas.

I have a patch; who reviews this part of the codebase?

Comment 20

[Ryan Pearl [:rpearl]]

Comment on attachment 818053 [details] [diff] [review]
Make all fields in the viewCert window readonly textareas.

17:02 < dvander> you could just r? gavin and see what happens

Comment 21

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 818053 [details] [diff] [review]
Make all fields in the viewCert window readonly textareas.

Hey Ryan, thanks for the patch.

One issue I see is that this file (viewCertDetails.xul) cannot depend on browser-specific stylesheets (chrome://browser/content/pageinfo/pageInfo.css), since it is used in contexts where those don't exist (e.g. Thunderbird).

The easiest way to remedy that would be to just copy whatever relevant style rules you're depending on (the "fieldValue" class?) to either a new CSS file in security/manager/pki/resources/content/, or just put it directly in a <style> block in viewCertDetails.xul.

Looks fine otherwise!

Comment 22

[:Cykesiopka]

FWIW, Bug 932116 made all the field values in the General tab selectable and copyable.
I would mark this bug as a dupe of Bug 932116, but I'm not entirely sure if this bug is asking for more.

Comment 23

[:Cykesiopka]

I'm going to mark this bug as a dupe of Bug 932116. Please reopen if this is incorrect.