Secure Web Testbed

18 Aug 1997

Phillip Dykstra, Army Research Laboratory

Purpose

The Secure Web Test Bed focused on the issues of:

Background

The World Wide Web has exploded as a major vehicle for the dissemination of information between and within organizations. For the Federal government, the Web represents a way to communicate information to the general public, as well as an opportunity to increase information sharing and collaboration between agencies. Many of our business processes are changing, and the web is a key part of that new information infrastructure.

The high visibility and increasingly critical role of the web has made concern for its security all the more important. There are several roles and reasons for security in the context of the web:

Relationship to other test beds

Some web security mechanisms depend on digital IDs or certificates. Public Key Infrastructure, or PKI, is the wider context in which such certificates are proposed to be managed (issued, accessed, changed, etc.). In this sense the developments in PKI and the PKI Test Bed are of great importance to Web Security.

To the extent that Web pages can contain sign and encrypted objects, the Secure Messaging Test Bed is exploring areas of interest.

Authentication is an important step in Web Security, and thus the work of the Advanced Authentication Test Bed, and the Kerberos Test Bed, are relevant.

Fortezza can be used for authentication and encryption. Fortezza mechanisms for both have been added to versions of the Netscape browser and server. These however were left to the Fortezza Test Bed to explore.

Activities of the Secure Web Test Bed

Client Software (browsers)

When this test bed began (July 1996) there were still a large number of web clients or browsers in use. Early on, considerable work was put into testing recent alpha and beta release of NCSA's client and server. The reasons for this is because they were available at no charge in source code form, and NCSA had put considerable work into experimental security mechanisms. They had a working implementation of S-HTTP, and experimental PGP and S/MIME mechanisms. You could also use SSL with their software if you licensed an SSL toolkit.

During the latter part of 1996, it became clear that two dominant clients had emerged: the Netscape browser known as "Navigator" (and now "Communicator"), and Microsoft's "Internet Explorer" (IE). Netscape claimed 85% of the browser market a year ago, with many others taking the rest. Today Netscape claims about 70%, with Internet Explorer taking up most of the rest. The latest rounds of this battle was the release of IE 4.0 on XXX, which still costs nothing to download and use, and the unbundling of Navigator 4.0 from the Communicator Suite on 18 Aug 97, which now makes it available to individuals for $39 (and has offered free use to most home users).

The emergence of Navigator and IE as the dominant browsers, coupled with NCSA's decision to cease browser development around XXX of 1996, led our testbed to quit experimentation with unique client security mechanisms. It was then decided that any security mechanisms that we could employ HAD to interoperate with Navigator and IE. Where the features of these browsers differ, and organization could choose to standardize on one of the other, but from a federal multiagency perspective that was not practical. Our software recommendation became (and remains): use Navigator or IE as your client/browser.

There was a downside of this market change however. Security mechanisms that were not supported by Navigator or IE would no longer be pursued. This means that S-HTTP is effectively dead (giving way to SSL), even though it could do some things that SSL can't. It is also harder now to work with Kerberos authentication on the web, because the clients don't have any built in support. PGP and S/MIME authentication, while is could still be done as plugins and CGI programs, is probably no longer worth pursuing.

Server Software

The web server market is a lot more open than the client market is. As discussed under client software, this testbed originally focused on the NCSA server code, because it had incorporated a lot of security mechanisms. When NCSA ceased development, a switch was made to the Apache server. Apache is available at no cost in source code form. With freely available patches, and crypto libraries known as SSL from Australia, it is possible to build a freely available SSL capable web browser. Apache also had a dominant share of the web server market (while still true, it has been reducing over the past year).

If one wishes to build a freely available web server, from source code, for a Unix platform, our recommendation is based on Apache. A lot of things happened in June/July of 1997 that is excellent news for the world of free, source code available, secure web servers.

Where to find all of the code:

For commercial servers, we can recommend either Stronghold (which is a commercial version of Apache), or the Netscape Commerce Server. One testbed participant also used and recommended the Microsoft server. All of these servers are capable of doing SSL with server certificates, and to varying degrees handle client certificate authentication.

Client and Server Certificates

Certificates or Digital ID's for web clients and servers are central to the use of SSL. There are several commercial sources of these certificates, e.g. VeriSign and Thawte. See e.g. the VeriSign Digital ID Center. VeriSign claims that over 16000 web servers have Digital ID's issued by them. As of 14 Aug 97, only 302 organization had purchased "Class 3" Digital ID's, their highest level of assurance. None of those were federal agencies.

VeriSign has also claims to have issued over 750000 client certificates. This number is large because their "Class 1" certificates are available over the net at no cost. This shows that perhaps 3% of web users have gotten client certificates. Their actual use is still very limited, though this may begin to change as these Digital ID's get used for S/MIME secure email.

Jeff Schiller of MIT demonstrated a system of issuing client certificates based on a different form of authentication. In his case it was Kerberos. If the user can present their Kerberos principal name and password to a certificate server, it will return a signed client certificate that can be used for web browsing for a certain period of time. This scheme could be used with any form of authentication, and we feel that it has a lot of promise where large deployments of technologies like Kerberos or Fortezza are in use.

Privacy

Web server sites can usually learn a lot about a user that comes to them via their browser. For an example, visit this URL. Methods of browsing anonymously have been devised, but are not yet widely available. The best known such service is the Anonymizer.

What's missing?

Encrypted SSL sessions are not yet widely used. They tend to be restricted to specialized information, such as the submission of billing or other sensative information. There is a penalty for its use, in terms of additional computing cycles for the encryption on the client and server sides. This may be an issue for a server under high load. It is not an issue for clients, which usually spend more time waiting for data transmission than they do in processing the results. We feel that far more use of encrypted sessions for all web access would be beneficial. It provides some privacy to the end user (the contents of their web transaction can not be snooped), and authenticates the information provider (server).

The use of client certificates is still in its infancy. We feel that client certificate access control is the most promising technology for securing the web, while still making it easy to use. To date however people are still struggling with issues of certificate import and export from browsers, interoperability between Netscape and Internet Explorer certificates, the lack of widely available software for issuing and managing client certificates, interoperability with certificates for secure email, etc. Not all web servers support client certificate access control mechanism well yet either. More maturity of PKI would likely help in these areas.

The next steps

Over the next several months we expect to see the maturity of SSL based client certificate authentication, both in the Apache-SSL and other servers. Support for clients certificates is also improving in the latest browser releases. While all of the participants in this test bed believe that this is the most promising technology to pursue, none of us have yet experienced wide scale deployment of this technology within our respective agencies, nor has it beed used on an interagency basis. We view such a deployment as a valuable next phase in this testbed. There are lessons to be learned about issuing and managing large numbers of client certificates (including across agencies), and about user education and reaction to this technology.

The other promising area to pursue is the automated issuance of client certificates based on other, possibly already existing, agency authentication mechanisms, e.g. Kerberos, Fortezza, etc. Demonstrations of this type of capability by Jeff Schiller of MIT and others is exciting. An early version of this code was used in this testbed, but the creation of a portable system for doing this is not yet complete.

References and Notes

For studies on the growth of the web, see one.
For an excellent compilation of web security issues, know bugs, and common questions, see the The WWW Security FAQ.
For a good discussion of SSL, client and server certificates, etc., see the paper "Securing Communications" by Netscape.
VeriSign has an excellent discussion of the hows and why of Digital IDs.