12.6. Creating Signed Remote Applications
Security in Mozilla's web browser is designed to meet today's advanced scripting needs in a secure manner. Mozilla is a much more secure browser than past Netscape 4.x and Internet Explorer releases because it has a better sense of what remote scripts can and cannot do.
Because of Mozilla's approach toward potentially insecure applications, if you decide to serve up your own application remotely, remember that you will not have automatic access to the chrome in the way you do when you have a registered, locally installed Mozilla application. Unless you sign your application or have the user turn on a special preference (see Section 12.3), services like XPConnect will not be available.
In Mozilla, you can bundle any number of files into a JAR archive (which, you'll recall from Chapter 6, is just a zip file with a JAR suffix) and designate the archive as an object that can be signed. This designation makes it very easy to produce an entire signed and secure remote Mozilla application because it stores your application in a single file type that Mozilla already treats as a separate package.
This section provides an overview of the signed script technology and shows you how to create signed applications that live on the server but take full advantage of the user's local chrome, including Mozilla components.
12.6.1. certs.mozdev.org CA Certificate
Before users can load signed applications, a CA certificate must be installed into their installed copy of Mozilla. Once this certificate is installed in a browser, all MozDev-signed applications can work with this certificate. This setup makes things easier on users who access many of these signed applications because they do not have to install a new certificate for each one. Also, if the user wants to use applications from other certificate authorities, they need to install a distribution certificate from that certificate authority.
Installing the certificate is easy. Just provide the users with a regular link on a web page -- for example, http://certs.mozdev.org/certs_mozdev.cacert. When loading this page, a dialog box pops up and asks the user to install the certificate. See the Section 12.6.3.2 section later in this chapter for more information about this process.
12.6.2. Signing Certificates
As a Mozilla application developer, you can obtain a common MozDev signing certificate and release a signed application that puts your application on par with other signed MozDev applications. If you consider your application mission-critical, however, you should go to a trusted CA such as Verisign. Mozilla already supports the VeriSign Netscape Object Signing CA, and discriminating users may find it more acceptable. A few other CAs listed in Mozilla's Certificate Manager may support Netscape Object Signing, so researching these options further may be worthwhile.
To get a certs.mozdev.org/signing certificate, send email to [email protected]. In return, you will receive a .cacert file that will be used to sign your remote Mozilla application.
SignTool (part of the NSS tool sets) takes a directory of files, zips them up into a JAR archive (refer to the section Section 12.6.3.1 later in this chapter to see how to do this), and signs the archive using the certificate you specify.
 | SignTool comes with the latest release of NSS, Version 3.4.1. On http://certs.mozdev.org, limited functionality versions of NSS contain SignTool for Windows and Linux that you can use instead for the processes in this book. |
Use CertUtil to set up a database for SignTool. Next, run some commands to set up the certificate environment:
C:\NSS\bin>certutil -N -d . C:\NSS\bin>certutil -A -n "certs.mozdev.org/signing" -t ",,C" -i eric.cacert -d .
The first command creates an empty cert7.db file where certificates can be stored. The second imports your Signing Certificate into the database. SignTool can use only certificates that reside in a database, which is the reason for this process.
12.6.3. Creating and Signing the Application
When someone obtains a private key (which is part of a Signing Certificate), they can encrypt their scripts and produce a public key. The relationship of the private key and the public key is called a private-public key pair. Using this relationship, you can create a signed Mozilla application and make it available to users in three steps:
Build the application itself, including the XUL, CSS, JavaScript, and whatever else you use to create the Mozilla application.
For this section, let's assume that you already created the XUL and JavaScript for the application and have all the files and directories together.
Archive and sign the application. SignTool takes care of both steps simultaneously, putting your application files in a JAR with a digital signature to validate everything.
The signing process described next in Section 12.6.3.1 deals entirely with SignTool.
Distribute your application (see the later section Section 12.6.3.2).
12.6.3.1. Signing the application
Security is not simple. Security technologists and vendors work hard to make sure that evildoers cannot abuse their encryption schemes, keys, and other tricks. Tools like SignTool can hide some of this complexity from you. When you sign an application, you create a digital signature in the archive that is based on the relationship of the files being signed, as Figure 12-7 illustrates.
SignTool automates these steps for you, so you don't worry about them. However, knowing these processes and seeing how these transactions take place can be useful, especially since using signed applications with Mozilla doesn't always work as expected and long-term directions for signed applications in Mozilla are uncertain. This uncertainty makes long-term deployment of signed remote Mozilla applications a risky option.
To start off your remote Mozilla signed application development, you can do something as simple as place one XUL and one JavaScript file in a single directory. Then move it into a NSS bin directory such as C:\NSS\bin and issue the command:
C:\NSS\bin>signtool -d . -k"certs.mozdev.org/signing" -p"password_of_database" -Z"myapp.jar" myappfiles/
The -d option is where the certificate database resides and -k is the certificate name.
12.6.3.2. Distributing the application
Once the file is created from the -Z option (e.g., myapp.jar from the example above), you can put it online. On the application's web page, note that the application is signed and put a link to http://certs.mozdev.org/certs_mozdev.cacert so users can install the necessary MozDev certificate if they do not have it.
To access the application online, you must use a special URL format. This format looks like jar:http://certs.mozdev.org/myapp.jar!/myapp.xul and points into the JAR at the main application file. This URL is difficult to type, so it may be wise to link it for user access or set up a redirected URL to that address, as shown in Example 12-12.
12.6.4. Receiving a Signed Application
As shown in Figure 12-8, when Mozilla receives a JAR, it must check it for validity before displaying the contents. A public key in certs_mozdev.cacert must be used along with the digital signature to make sure that the contents are not tampered with and that the signature is valid.
 | //FIXME did we loose content here? |
| When you are developing a signed remote Mozilla application, clear a JAR's cache before trying to reload an updated version of it. Clearing the cache can be done most easily by restarting Mozilla. If you or your users do not do clear it, the consumer of the application will probably wind up with a blank screen. |