Closed Bug 278629 Opened 20 years ago Closed 8 years ago

No way to inspect the certificate of a signed extension

Categories

(Toolkit :: Add-ons Manager, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: alex, Unassigned)

Details

(Keywords: sec-want, Whiteboard: [sg:want P4])

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

When the extension XPI is signed, the name of the signer appears instead of the
red "not signed" warning. There is no way for the user to verify the certificate
and see its details (like in the security dialog that pops up when clicking on
the secure site's lock icon). 

Right now, a test (self-signed) certificate can be created with any name entered
as the signer and this name will appear when installing the extension. This way
it is very easy to impersonate anyone, and thus the signing mechanism is
essentially broken.
If a "certificate info" dialog was available, the user could see that it's not a
real certificate.

Reproducible: Always
Severity: normal → critical
Version: unspecified → 1.0 Branch
> Right now, a test (self-signed) certificate can be created with any name entered
> as the signer and this name will appear when installing the extension. This way
> it is very easy to impersonate anyone, and thus the signing mechanism is
> essentially broken.
> If a "certificate info" dialog was available, the user could see that it's not a
> real certificate.

Did a little further investigation on this. The above seems to be incorrect -
sorry :). In order to impersonate using an extension signed with a test
certificate, the user will have to have this test certificate installed, and
that isn't the case (I hope I got this right this time :) ).  

Also, when installing a signed extension, the signer info appears in the
"Options > Advanced > Manage Certificates > Web Sites" (even before the
extension is installed by clicking "Install") and can be inspected there (I'm
not sure this is the correct behavior). This window should be accessible from
the installation dialog.

I'm not sure that the fact that the user cannot easily inspect the signer and
the certificate info can be easily exploited, but I believe that this is still
an important issue. I'll do some further research on it. 

Any security experts out there - what do you think?
Although the security module knows the cert details, I don't think it'll be easy
to get it for use by the chrome front end.

The cleanest UI might be be to have the signer be a link that brings up the cert
details dialog when clicked. Unobtrusive, but there for folks who want it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
> The cleanest UI might be be to have the signer be a link that brings up the cert
> details dialog when clicked. Unobtrusive, but there for folks who want it.
Totally agree. 
Several things should be added IMHO to the current UI:
1. Prepend "signed by: " or "publisher: to the signer name. Right now only the
name itself appears and the user can only know the extension is signed by the
absence of the "not signed" warning (see
http://www.j-maxx.net/abtrans/xul/albhed-0.1.2.xpi).
2. At the bottom of the dialog where it now says "Malicios software can
damage..." it can also say something like "This extension was signed by xxxxx.
Please make sure you trust xxxxx before installing this extension".
We must make sure, though, that this warning is not more prominent than the
unsigned extension warnings, because otherwise we might end up worrying the user
more when the extension is signed, than when it's not. 
3. A link/button that will pop up the cert details dialog

Should I submit separate bugs for the first two points?

Is this still security sensitive?
(In reply to comment #4)
> Is this still security sensitive?

I believe that this is a security issue. I can quote several articles on this: 

-----------------
Apple Security Concepts:
http://developer.apple.com/documentation/Security/Conceptual/Security_Overview/Concepts/chapter_3_section_7.html
The confidence you can have in a given certificate depends on the confidence you
have in the certificate authorities and in their procedures for ensuring that
subsequent certificate recipients in the certificate chain are fully
authenticated. For this reason, it is always a good idea to examine the
certificate that comes with a digital signature, even when the signature appears
to be valid.
-----------------
How Secure Is Secure Web Browsing?
http://people.sabanciuniv.edu/levi/ssl-risks.pdf
You must examine the certificate details to ascertain commercial identity. For
example, when you connect to www.delta.com, you can’t be certain you’re
connected to Delta Airlines just by the closed padlock; you have to scan the
certificate details by clicking on the padlock. If www.delta.com was, say, Delta
Foods, you would have seen a closed padlock even if the Web page looks like the
airline’s.
-----------------
This is a security-related issue, but it does not need to be confidential.
Group: security
Assignee: bugs → nobody
QA Contact: bugs → extension.manager
Version: 1.0 Branch → Trunk
Severity: critical → normal
Whiteboard: [sg:want P4]
Product: Firefox → Toolkit
Blocks: 495687
No longer blocks: 495687
Is this still applicable with the new methodology?
In the "new methology", the error message is not user-oriented.  It not only does not provide a means to inspect the signature on the add-on, it does not even provide an indication that a root certificate is missing.
I don't think this is useful anymore, now that we require all add-ons to be signed by Mozilla.

If I am missing something please re-open and explain.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: