Secure Web Testbed
18 Aug 1997
The Secure Web Test Bed focused on the issues of:
Web user/client authentication - how do we know who the user is?
Web server authentication - how do we know who the server is?
Web access control - how to limit access to content to the intended
user or groups of users.
Secure transactions - how to protect content, authentication, and
access controls, from "snooping" while they transit the network.
Client software - which browsers are available for achieving these goals?
Server software - which servers are available for achieving these goals?
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:
- Protection of the information (and service) from unauthorized
modification or destruction. This can not only lead to embarrassing
situations like that experienced by the Department of Justice and the
Central Intelligence Agency, but could result in dangerous denial
of service of the release of misinformation.
- Checking the validity of information - was is "signed" by a
- Controlling access to information so that only the appropriate
individuals can retrieve it (and, so as not to deny access to individuals
who should have access).
- Protecting information from disclosure while in transit between a
Web browser and Web server.
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
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.
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.
- 05 June 97, Apache 1.2.0 was released
- 25 June 97, SSLeay 0.8.0 was released
- 29 June 97, ssl_1.7 for Apache 1.2.0 was released
- 05 July 97, ssl_1.8 for Apache 1.2.0 was released (bugfix)
- 05 July 97, Apache 1.2.1 was released (bugfix)
- 18 July 98, SSLeay 0.8.1 was released (bugfix)
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
Web server sites can usually learn a lot about a user that comes to
them via their browser. For an example, visit
Methods of browsing anonymously have been
devised, but are not yet widely available. The best known such service
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
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
Communications" by Netscape.
VeriSign has an excellent discussion of the hows and why of