Code Signing

What is code signing?

Code signing confirms that software does indeed come from the publisher who has signed it and that it has not been tampered with since it was signed. There are various code signing certificates available for different application types and browsers.

Netscape Object-Signing allows packages, pages, applets and plug-ins to be signed by developers on netscape platforms (navigator, firefox etc). When you begin a download of a signed object (eg a plug-in, applet or xul app) a popup opens giving the option of accepting the supplied credentials and proceeding with the download, or cancelling the process.

If your certificate is accepted by the user your code can then ask for and receive extended privileges (eg reading and writing to the file system).

To sign objects you need a special Netscape Object-signing certificate from a provider such as Thawte. https://www.thawte.com/ssl-digital-certificates/code-signing/index.html

Why we need it

Carey gave a nice summary:

There are two issues

1. signing the extension itself - this verifies that the extension is infact the version deployed by us, not a modified keylogging malware version hacked by somebody else. The extension manager in firefox shows the extension is from a trusted source. I believe this to be the modern professional way to distribute software regardless of the merits and cost of the certificate system. However in practise it isn't necessary yet, firefox doesn't require an extension to be signed. I think we can forgo this for a while.
2. signing the applications - our online applications require elevated privileges to use the zinc extension. Those elevated privileges pretty much allow the javascript in the served web pages to do anything it wants to the end users computer. Obviously the browser doesn't allow this behavior by default, first it establishes the trustworthiness of the served application and then asks the user if they want to allow it. We currently circumvent the first check using the signed.applets.codebase_principal_support option in the about:config. It is _really_ bad practise to instruct people to disable security to run our online apps. It is also problematic because most people miss this step or are scared off by it (rightly so!). So the certificate does away the signed.applets.codebase_principal_support hack for applications signed by us. An application is zipped up into a jar and the jar is signed, the jar file can then be served from anywhere and the user knows it remains unchanged from when it was jar'ed up by us. In my view if you are inviting the world to use your online application that has the ability to access/destroy the users machine you have do so responsibly, respecting security mechanisms and ensuring the integrity of your application is part of that.

Getting it

A code signing certificate costs money. I have contacted Russell Fulton from IS Security re getting one to use. If you don't have the funds an alternative is to create your own certificate and sign your software with that. This has the disadvantage that users must manually install the certificate before using your applications, but it is probably preferable to the signed.applets.codebase_principle_support hack.

Signing extensions

Signing xpi files is non-trivial. Some tutorials I have found are listed below:

• http://www.mercille.org/snippets/xpiSigning.php
• https://www.mozdevgroup.com/docs/pete/Signing-an-XPI.html

I have also created this Guide to signing XPIs

Signing applications

To sign our zinc applications they will need to be placed in a jar file and then the jar file signed. The application can then be accessed using a URL of the form 'jar:http://certs.mozdev.org/sample.jar!/sample.xul'

I have created this Guide to signing applications

Other useful info

There is an excellent page on security with Mozilla. It is quite relevant to the discussion above: http://www.mozilla.org/projects/security/components/jssec.html