Judson D. Weeks
Adam Cain
Briand Sanderson
The multifaceted issue of security is inexorably entangled in the World Wide Web. To make manageable the complex task of "securing the Web," we may (imperfectly) divide the issue into four interrelated components [17]:
While all of these security components are extremely important, most recent Web security development efforts have been aimed at improving the authentication and confidentiality aspects of communications on the Web. In fact, multiple solutions have been offered to address these needs. Secure-HTTP (S-HTTP) [16], as well as systems using Message Digest Authentication[10] and Kerberos-based approaches [4], provide application-layer solutions. Meanwhile, the Secure Socket Layer (SSL) [8], Private Communication Technology (PCT) [1], and DCE-Web [14] systems all address similar needs by providing security closer to the network layer. Despite the difference in approach, the main goals of all of these technologies are the same: to secure Web communications by authenticating Web clients and servers and to cryptographically protect the data exchanged between them.
How do we, both as developers and regular users, deal with this proliferation of Web security schemes? Having a diversity of security technologies is indeed desirable, as we would like to be able to quickly switch from one to another in case of, for instance, a new potentially catastrophic weakness discovered in a particular protocol, algorithm or implementation [11]. However, we would prefer to not have to install multiple browsers and servers for this purpose alone. And, from the developer's point of view, the dreaded "browser bloat" phenomenon will probably make supporting all desired security mechanisms infeasible.
A few systems have been proposed to allow for the peaceful coexistence of the Web security schemes. The Spyglass Security Plug-in Module (SPM) architecture [9] describes a new communication interface between a Web browser and multiple security "modules." The World Wide Web Consortium (W3C) is currently developing HTTP extensions to allow for more flexible negotiation of security parameters. Also, new "portable-code" languages, such as Sun's Java [12], have been suggested as technologies useful for easily adding browser support for various Web security schemes. Currently, none of these systems are in widespread use.
As a novel approach to dealing with this dilemma, we look to the Common Client Interface (CCI) as a means to providing application-layer support for Web security features. By so doing, we hope to enable authenticated and/or signed Web communications in a way that is easily supported by any browser with a general-purpose interface similar to CCI. Additional advantages of this design include the graceful handling of documents which are themselves signed and/or encrypted, and the ability of browsers with no native capabilities for encryption to employ the design. This design will greatly ease the process of international distribution, as all security functionality is completely divorced from the Web browser.
Rather than implement all necessary security features needed by the CCI application from scratch, we make use of the popular Pretty Good Privacy (PGP) software [7] to handle data encryption, signature verification, key management, etc. In essence, the PGP-CCI application is a GUI-based front end to PGP which communicates with the Web browser via CCI.
To demonstrate the feasibility of this scheme, we present the PGP-CCI protocol which can be used to allow the signing and/or encryption of HTTP messages. Similar to S-HTTP in design, this protocol uses HTTP extensions, new HTML anchor attributes, and advanced CCI features. The simpler "PGP-POST" scheme is also described, which uses the PGP-CCI application to encrypt and/or sign HTML FORM submissions and does not require modified web servers or advanced CCI functions.
Before jumping into the mechanics of the PGP-CCI and PGP-POST designs, we first clarify the utility of handling signed and or encrypted documents, as opposed to applying similar security enhancements to HTTP messages or communication channels. Next we review the relevant characteristics of CCI, PGP, and previous work combining PGP with the Web. The function and features of the PGP-CCI application are then described, followed by details of how to use this application to handle the viewing of PGP-enhanced documents. We then explain the PGP-CCI protocol and the PGP-POST system, giving example HTTP messages resulting from use of these schemes. Finally, we discuss the security protections offered by these new systems, as well as some security considerations for the use of CCI.
Throughout this paper we assume that the reader has a working knowledge of the World Wide Web, HTML, the HTTP Protocol, and the basics of cryptography and digital signatures.
The distinctions between security of channels, messages, and documents are subtle but crucial. Schemes such as SSL [8] and PCT [1] address the need for secure channels in the form of authenticated, encrypted socket connections which may be used by Web applications. S-HTTP [16] and the PGP-CCI protocol described below, allow for HTTP messages that are signed and/or encrypted. Both of these approaches to secure communications have their strengths and weaknesses, and each will probably have a place in the grand Web security context. However, thus far there has been minimal attention paid to the handling of documents which are security-enhanced. Such documents may be signed and/or encrypted using a variety of security applications in wide use today, such as PGP.
What's the difference? Consider the example of a web site run by a government organization distributing documents which are important, but not secret (1). Documents of this type may be digitally signed by the organization as a matter of course. In any case, a browser viewing such a document on the web may wish to know that the document itself is authentic and has not been modified in transit. Furthermore, it may not matter at all from which web server the document was retrieved or what encryption mechanisms were employed to secure the channel. All that matters is that the document was signed by the government organization in question.
Channel-oriented security schemes can only authenticate the parties on either end of the connection and provide an encrypted channel for the data. Using these systems alone, there is no possibility for signed messages or documents, and thus non-repudiation is not achievable. In other words, these schemes cannot, by themselves, provide signed data which can be stored and used later to prove that the signing party committed to a particular action. This is simply a consequence of putting the "security smarts" below the application layer.
With message-based security enhancements, we can obtain signed or encrypted HTTP messages. This achieves authentication of, and private communications between, the two message sources: the web server and the user of the web browser. Such messages could be stored (although this function is not usually implemented) and used to prove that a particular document was served by a particular web server. However, this is not the same as having a document signed by the information provider. To understand the difference, consider the case in which our governmental organization wishes to distribute an important document using many other organizations' web servers. We would like the document to bear the signature of the organization authoring it; the authentication of the particular web server used to serve the document may be of no interest at all.
Currently, Web applications do not deal well with signed/encrypted documents. A browser user certainly can fetch and view a digitally-signed text file, for example; but to verify the document's signature, the user would have to save the file locally and manually run PGP (or the user's preferred security program) with the local file as input. An improvement in usability is offered in [13] although a GUI-based scheme with tighter browser coupling would be preferable.
Given the relative strengths and weaknesses of sockets-layer security and application-layer security, we have adopted an application-layer security scheme that takes advantage of message-based security enhancements while making provisions for handling signed and/or encrypted documents as well. To this end, we exploit of the flexibility of the Common Client Interface combined with the power of the Pretty Good Privacy encryption package.
The Common Client Interface, or CCI(2) is a client-side API (Application Programmer Interface) that is designed to expand the functionality of browsers without having to alter the code of the browsers themselves. While there are many variations of CCIs (e.g. Spyglass' SDI [3]), they all provide a means for Web browsers to communicate with other applications that reside on the client, henceforth referred to as CCI applications.
The CCI is a two-way communication protocol with functions that drive the browser (such as OpenURL() [3], which tells the browser to load in a document at a specific URL, and Post() [17], which tells the browser to submit an HTTP Post of escaped data to a specific URL) and functions that re-route output from the browser to the CCI application (such as SendOutput() [17], which routes server responses with certain Content-types to the CCI application rather than having them viewed by the browser). These functions allow application developers to easily integrate a wide range of functionality with the features of a Web browser. For more information on CCIs, see [15], [3], and [18].
Note: While there is at least one CCI which enables communication between the browser and applications running elsewhere on the network, we assume that browsers supporting such CCIs are configured to communicate only with local applications. This is necessary in order to obtain a more secure link between the Web browser and the PGP-CCI application.
To explore the feasibility of CCI-based Web security features without building all necessary cryptographic tools from scratch, we chose to design a CCI application which would act as a frontend to the popular cryptographic software package known as "Pretty Good Privacy," or PGP.
PGP, originally designed by Phillip Zimmerman, is a sophisticated program to handle the bulk of security needs for documents and message-passing systems. PGP is a public-key cryptographic package that provides protection of documents and messages using symmetric or asymmetric encryption for confidentiality and digital signatures for authenticity and integrity. For further information on PGP see [7] and [19].
Besides providing the tools to secure Web documents and communication, PGP has several other advantages. First, it is freely available in various forms worldwide. Also, it is widely used on the net already, allowing for easy adoption. Next, it has a distinctive trust model in which each user decides how much they wish to trust the public keys of others. In essence, the user becomes his or her own certificate authority and is not forced to rely upon validation by some global authority. To accomplish this, each PGP user maintains his or her own keyring, which is a list of the public keys of others with an associated trust level for each key. As PGP encounters unrecognized public keys, PGP warns the user and asks whether he or she wants to add the key to his or her public keyring and if so, what trust level should be assigned to the key. Under this model, individuals sign the public keys of trusted entities and exchange these with other trusted entities, to build a "web of trust". This allows PGP to be used now, while the certification infrastructure is in its infancy, and then be integrated with the infrastructure as it develops.
Using these functions, we are able to construct a protocol that will allow clients and servers to authenticate each other, provide document access control, keep messages and data confidential as they travels across unsecured networks, and even verify the integrity of documents stored on unprotected servers.
While the use of a user-friendly CCI application as an interface between PGP and Web browsers is new, the idea of combining Web applications with external cryptography packages like PGP is not. In fact, simple external function calls, or hooks, were added to XMosaic and NCSA httpd to allow each to run PGP or PEM for handling encrypted, signed HTTP messages [2]. This was effectively a proof of concept implementation which lacked provisions for key management, secure passphrase handling, and other features essential for a valid Web security scheme.
Of special note is the fact that an early version of the Secure HyperText Transfer Protocol, S-HTTP [16], partially defined support for PGP-enhanced messages. The details of using PGP with S-HTTP were not fully specified, and an implementation of this mechanism was never created. In the current S-HTTP specification [16], the PGP-related definitions have been dropped altogether.
The PGP-CCI work described here builds on the previous PGP/PEM hooks, adding flexibility and user friendliness (via GUI-based CCI application), while avoiding the requirements that all keys be exchanged out of band and that cleartext passphrases be stored in scripts. This work follows a scheme similar to S-HTTP, although the protocol is considerably simpler than S-HTTP and may be implemented via CCI without native support for cryptography built into the browser.
The PGP-CCI application is essentially a link between the Web browser and the functions provided by PGP. The CCI application itself may be implemented as a GUI shell to a command-line interface for PGP, or as a complete application built using the PGP source code or even the upcoming PGP API. The PGP-CCI application also functions as a viewer for documents that have been encrypted or signed by PGP (see "Viewing PGP-Enhanced Documents via CCI" below). The security issues for the PGP-CCI application fall into two categories: those issues connected to the interactions between the PGP-CCI application, the browser and the server and those issues connected to the user interface of the application itself. The security issues with the interactions between the PGP-CCI application, the browser, and the server are detailed in the PGP-CCI protocol below. The user interface issues are as follows.
Given the potential for security breaches that automation can provide, the PGP-CCI application must display the following information to the user:
All of these items are necessary to ensure that the user is properly informed about the security status of the messages or documents that are being handled. The third item is particularly important as neglecting to check this kind of certificate information can potentially allow certain types of spoofing attacks (although PGP's trust model makes such attacks less likely to succeed).
One of the cornerstones of PGP security is the importance attached to signing or decrypting a document. Each of these activities requires the use of the user's private key and therefore must be handled with great care. Accordingly, PGP defaults to prompting the user for a pass phrase on every such occasion. Given the frequency with which either of the activities will occur in a Web environment, the PGP-CCI application could optionally cache the user's pass-phrase after he or she enters it the first time; thereafter, the user is merely prompted whether he or she wishes to sign or decrypt. However, if this approach is used, it is very important that adequate measures be taken to insure that an unattended system cannot be abused (e.g. time-out features, periodic flushes of the pass-phrase to prevent recovery of the pass phrase from the cache or user-sloppiness).
Given the amount of HTTP messages and responses that normal web-surfing creates, running every HTTP request through the PGP-CCI application, as detailed in the PGP-CCI protocol below, can become quite a performance hindrance. For performance reasons, the PGP-CCI should be equipped with a feature to easily enable or disable the routing of HTTP requests to the CCI application from the browser. Note that even when the handling of HTTP requests is disabled, the PGP-CCI application should be able to handle the viewing of PGP-enhanced documents.
As outlined above (see "Where Do I Sign?"), viewing security-enhanced Web documents is a highly useful but often neglected function. However, using CCI makes the implementation trivial. No changes have to be made to the code of either the client or the server; all that is necessary is the addition of a new MIME type.
Documents signed and/or encrypted with PGP usually have filenames ending with .pgp or .asc, the latter extension signifying that the data is encoded in ASCII-armored (text) format. For transfer of PGP-enhanced documents, we propose the use of the following MIME type:
Content-type: application/x-pgp
Therefore, the only requirement of the web daemon serving such documents is to map the appropriate file extensions to this new content type (3). Usually this process involves adding a new line to the mime.types file on the web server, such as the following:
application/x-pgp pgp asc
That's all there is to it for the server! Even web daemons oblivious to PGP or any other sort of cryptography may serve PGP-enhanced documents by this method.
On the client side, the PGP-CCI application registers as a viewer for the application/x-pgp type during its initialization. Thereafter, whenever the browser requests and receives a document of this type, the received data is sent to the PGP-CCI application, which passes the document on to PGP. By processing the output of PGP, the browser can obtain all the information it must display to the user. This includes taking appropriate action in the case of an invalid signature or a failed decryption. Also, if the document turns out to be encrypted using the client's public key, the CCI application should prompt the user before resubmitting the document to PGP along with the user's passphrase, as outlined above (see "PGP-CCI Application Description").
The elegance of this handling of PGP-enhanced documents is that after decrypting or verifying the document signature, the PGP-CCI application tells the browser to display the document. This should work equally well if the document is text, HTML, graphics, or any other media the browser can recognize.
In addition to handling all application/x-pgp content-types, the PGP-CCI application registers with the browser to receive all requests for URLs with the http protocol and to handle all application/x-www-pgp-response content-types. When doing this, the CCI application specifies that the browser give it the full HTTP messages involved in these actions, as well the anchor attributes for http URLs.
Hyperlinks pointing to documents to be retrieved using PGP-CCI contain special anchor attributes giving the server's public Key ID, as well as other optional information such as whether the HTTP request should be signed, encrypted, or both. Any requests for a HTTP hyperlinkthat do not contain these attributes will be passed from the CCI application to the browser, to be fetched normally.A request for a hyperlink containing the PGP-CCI-related attributes proceeds as follows:
Below is a more detailed description of this protocol. Note that as this is an experimental scheme, the exact names and syntax are subject to change.
In order to allow for pre-enhancement of HTTP requests, including encryption, there must be additional information in the hyperlink for the URL. For greater compatibility and flexibility, we use anchor attributes for this purpose, rather than defining an entirely new protocol ("pgp-http", for example). Note that the anchor attributes defined may be useful for other PGP-related schemes besides PGP-CCI.
Example: PGPPUBKEYID="E9B2BB1D"
Example: PGPUSER="Topsecret Web Server <www@topsecret.org>"
Example:
PGPKEYBLOCK="Version: 2.6.2
Example: PGPPUBKEYSRC="http://www.topsecret.org/pubkey.asc"
Examples:
PGPMODE="request-signed,request-encrypted"
PGPMODE="request-signed"
PGPMODE="body-only"
The latter example refers to the PGP-POST scheme described below, and it signifies that PGP-enhancements should be applied only to the data in the body of the HTTP request (the query string, in the case of a post).
A typical hyperlink might look like the one below. Note that the order of the attributes is not important.
<A HREF="http://www.topsecret.org/wherever/whatever.html"
PGPUSER="Topsecret Web Server <www@topsecret.org>"
PGPPUBKEYID="E9B2BB1D"
PGPPUBKEYSRC="http://www.topsecret.org/pubkey.asc"
PGPMODE="request-signed,request-encrypted"
> Click here for the secret formula </A>
While the function names and syntax differ across different implementations of CCI-like interfaces, most of the interfaces have commands which are semantically equivalent. Since many implementations are similar to Spyglass' Software Development Interface, we describe the commands used by PGP-CCI in terms of advanced functions based on the specification for Spyglass' SDI [3].
To use the PGP-CCI scheme, the server must have compiled support. The server's PGP-related information (such as its PGP username, the location of the PGP executable, keyrings, etc.) is specified in configuration files. When launching the server, the administrator enters the server's passphrase, which is stored in memory and then used for any decryption or signing operation (automatic means for specifying the pass-phrase are available, though not recommended).
Using .htaccess files, or equivalent means, the server may be configured to require PGP-CCI authentication/encryption for accessing certain Web documents. Particular entities, or groups of entities, may be specifically allowed access by referring to their PGP usernames. Furthermore, the necessary enhancements for the HTTP request and the corresponding response may be specified by "require" lines in these configuration files. An example ".htaccess" file for a document directory might look as follows:
AuthType PGP-CCI AuthUserFile /etc/httpd/keyrings/pubring.pgp AuthGroupFile /etc/httpd/.htgroup.pgp require user "John Doe <doe@foo.org>" "Ted Tedman <tt@bar.edu>" require request-encrypted require response-signed
Note that any "require user" lines imply that the HTTP request be signed. Also note that the appearance of a "response-encrypted" line implies that the request also be encrypted (in order to send the session key used to encrypt the response).
Assume that the browser user has clicked on a hyperlink like the example link given above (in "Hyperlink Attributes for PGP-CCI"). The PGP-CCI application adds a few lines to the HTTP request before signing/encrypting it with PGP. The resulting plaintext HTTP request might look like:
GET wherever/whatever.html HTTP/1.0
Date: Thu, 05 Oct 1995 16:57:05 GMT
Accept: */*
User-Agent: NCSA_Mosaic/2.7 libwww/2.12 modified
Extension: PGPMODE=response-signed,response-encrypted
Extension: PGPENCKEY=keyname1,mr18YmNIc+sU0tGpZyE3
The PGP-CCI application adds the Date header, if not already present. The PGPENCKEY must be a 20-character radix-64 encoded string representing a 120-bit random number generated using a secure random number generator [6]. Note that PGP uses the hash of this string to create a 128-bit session key for use in performing the encryption (5). The PGPMODE parameters are optional, and they are set according to user preferences on the PGP-CCI application. The web server should accommodate the client's requests for security enhancements specified in the PGPMODE, as long as they are not explicitly forbidden in the server's configuration file (via a "require response-unencrypted" line in the .htaccess file, for example).
After the request is processed by PGP, it is encapsulated within a generic HTTP request. The result might look as follows:
GET / HTTP/1.0 Authorization: PGP-CCI Content-type: application/x-www-pgp-request -----BEGIN PGP MESSAGE----- Version: 2.6.2 pwhjT53Ue2c2cv+mAAAIX+PUGxKzA4mRODt0PnRQyqTwKOHmj81Q90aAuJX7 E8bNEU5OW+r413/ZwpEUiIlkCewco+61ufR7y5yvwoNn383eMM2AdcArGh28 HuYxPCSlxqRHlzFwOZNdhcfA2aPi8gduBBu2guPC7Vtbfg4n9K9PCmYXQPh6 =VSGG -----END PGP MESSAGE-----
The Authorization line is set to "PGP-CCI" to indicate to the server that PGP-CCI scheme should be followed.
If the enhancements on the client request match the server's requirements for the requested document, the request is considered valid. The server then prepares a HTTP response as it normally would and this response is encrypted and/or signed using PGP. The result is prepended with additional headers, and the result might look like:
HTTP/1.0 200 Document follows
Date: Mon, 11 Sep 1995 14:23:32 GMT
Server: NCSA/1.5
Extension: PGPENCKEY=keyname1
Content-type: application/x-www-pgp-response
Content-length: 874
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
hGxuwKXyEBAwCkj3VdDLVnCDAqUy28gqK7R0GlVej3L5b+x7C6FN4s4gdf
PUiZ4AkCewco+61ufR7y5D4ogWWtY6w3zI7BWfCexxNHvHBRO9e+cQZhLg
i6cE8bNEU5OW+r413/ZwpEUiIlnzaJblq9xx4r12wEYlQlexjs1ThUTvXS
HzTCSlxqRHlzFwOZNdhcfA2aPi8gduBBu2guPC7Vtbfg4n9K9PCmYXQPh6
=VSGG
-----END PGP MESSAGE-----
In this case, the encapsulated message has been encrypted using the session key named "keyname1"; the client supplied this name in the request and may use it to look up the value of the session key for decrypting the server's response. The server may also include its public keyblock in the body of the response, and PGP can use it for signature verification (in case the public key was not found already during the preparation of the HTTP request). Note that the content-type application/x-www-pgp-response causes the data to be sent by the browser to the PGP-CCI application.
If the proper security enhancements were not applied to the request, as in the case where the user types in the URL by hand, the server sends back a 401 response. A hyperlink for the requested URL, including the relevant anchor attributes, is contained in the message body, so that a client may resubmit the request properly. The entire HTTP response might look as follows:
HTTP/1.0 401 Unauthorized
Date: Thu, 05 Oct 1995 03:09:19 GMT
Server: NCSA/1.5.1
Content-type: text/html
WWW-Authenticate: PGP-CCI
<HEAD>
<TITLE>Authorization Required</TITLE>
</HEAD>
<BODY>
<H1>Authorization Required</H1>
Browser not authentication-capable or authentication failed. <P>
This document requires that you enhance the request using PGP.
<H2> Try requesting this document again, using the link below, after
you have launched your PGP-CCI application </H2>
<A HREF="http://www.topsecret.org/wherever/whatever.html"
PGPUSER="Topsecret Web Server <www@topsecret.org>"
PGPPUBKEYID="E9B2BB1D"
PGPPUBKEYSRC="http://www.topsecret.org/pubkey.asc"
PGPMODE="request-signed,request-encrypted"
> Click here to resubmit your request </A>
</BODY>
We now describe a simpler version of the PGP-CCI Protocol that, while limited, can be deployed without having to upgrade to a PGP-aware server. This method is used with HTTP POSTs only and is a variant of the general PGP-CCI protocol described above. Its purpose is simply to allow strong encryption and/or signing of form data.
The main difference between the PGP-POST and the standard PGP-CCI protocol is that in PGP-POST only the data in the query string, and not the whole HTTP message, gets signed and/or encrypted. In this mode, the PGP-CCI application has to make sure that the important data that would normally be in the signed/encrypted portion of the message headers gets escaped and prepended to the query string of the POST data. For example the Date field would be:
Date=Sat+07+Oct+1995+16:57:05+GMT
The fields that have to be handled this way are precisely the headers from the standard protocol that have to be encrypted, namely:
These fields are supplied by the PGP-CCI application
On the server side, instead of having the PGP functionality built in to the server or communicating with the server through interprocess communication, PGP actually resides in (or is launched by) a CGI script. Under PGP-POST, the CGI script is responsible for checking the date stamp and optionally keeping track of the PGPENCKEY values to detect replay. While this processing increases the workload of the CGI programmer, it does provide added flexibility in implementation. As with the PGP-CCI protocol, the PGPENCKEY, if present, is used to encrypt the response, which should then have a applicationlication/x-pgp MIME-type.
Given the dangers inherent in CGI scripts, we must point out that if the CGI developer wishes to use the PGP-POST method, certain precautions must be taken. First, we recommended that the CGI script be written in a compiled rather than interpreted language with the pass phrase(s) either embedded in the script or in a file that only the CGI program can access. Second, note that the permissions on the CGI script are set so only root or other authorized users can access the script.
The primary differences of the PGP-POST method on the client side have to do with the way in which the document containing the form launches the HTTP POST in question. The author has an option of embedding the necessary information (such as PGPMODE, PGPPUBKEYID, et cetera--see above for further details) in the FORM attributes as was done for the PGP-CCI method described above. Alternatively, the author could embed this information in the name-value pairs of hidden fields within the form. The latter alternative is supplied mostly for compatibility with current browsers that might not have the advanced CCI features to trap attribute values. Either way, if the author intends to use the PGP-POST method of encryption, he or she must include an extra field in the PGPMODE attribute/name: "body-only". This field tells the PGP-CCI application that only the body of the HTTP POST, and not the entire HTTP message, is to be encrypted and/or signed. Before encryption, the query string would look something like:
query-string="name=John+Doe&CC=Master+Card&... &PGPPUBKEYID=E9B2BB1D &PGPMODE=request-encrypted,request-signed, body-only" &Date=Sat+07+Oct+1995+16:57:05+GMT &PGPENCKEY=a4d83e1c80af9ce02e5d3f230dc5e63b
This example assumes that the user is embedding the PGP relevant fields as hidden data elements within the form.
Since the PGP-POST method can only function with HTTP POSTs, the PGP-CCI application could trap only the POSTs instead of all HTTP requests. This is assuming, of course, that the CCI that the application is using supports trapping HTTP POST requests from the browser.
While a complete analysis of the security provisions and concerns for the PGP-CCI and PGP-POST schemes is outside the scope of this document, we do consider some of the more important threats and the protections offered against them. Potential attacks may be divided into two categories: network-based attacks relating to the security protocols, and attacks on the CCI communications between the browser and the PGP-CCI application.
Assume that the browser user starts with a trusted document containing hyperlinks for PGP-CCI-protected pages (if an attacker has fooled the user with a bogus starting page, all is already lost). Thus, the public Key ID's of the servers in the hyperlink attributes are also trusted. Now let's say the user clicks on a PGP-CCI hyperlink. At this point, any attacker who attempts to impersonate the desired Web server will either be detected before the request is sent or will be easily identified after the response is received. To decrypt an encrypted request, or to provide a signed or encrypted response, the attacker would have to posses the private key corresponding to the public Key ID in the hyperlink. If the attacker intercepts a request for the Web server's public keyblock (using the PGPPUBKEYSRC attribute) and interject the attacker's public key, the PGP-CCI application will immediately notice that the Key ID for the key received does not match the one in the anchor and will abort the exchange.
The main weakness of this scheme is probably the handling of "401 -- Unauthorized" server responses. An attacker could intercept a PGP-enhanced request and return a 401 message with the attacker's Key ID in the re-submission anchor. However, the fact that the entity issuing the responses is not the desired web server should be obvious to the user. This aspect would be clearif the user noticed the different Key ID (and most likely the PGP username as well) displayed in either the 401 message's HTML source, or in the PGP-CCI application's display of the security information for the attacker's next response. A solution to this weakness could be to have the PGP-CCI application also register as a viewer for all text/html responses; it could then detect the 401 and respond appropriately (any other text/html responses would be sent back to the browser for viewing). This change would require a modified PGP-CCI protocol, and could have a significant performance impact. Another solution would involve changing the Common Client Interface to include routing of messages based on Authorization headers.
The main defense mechanism against these types of attacks is PGP's handling of public keys. If an attacker attempts to fool the client into using the attacker's public key which is not on the user's keyring, the PGP-CCI application demands that the user acknowledge that this is an untrusted key before continuing. Also, if an attacker's key already exists on the user's keyring, then the user is assumed to recognize the identity of the keyholder and thus immediately detects any attempted masquerades.
Since there is the communication link between the browser and the CCI application, either in the form of message passing, or in our case, storing data in temporary files, security is highly dependent upon the security of the operating system as a whole. These concerns are beyond the scope of this paper.
In developing these CCI-based security systems, it has become clear that current CCI implementations were not designed with security as a major priority. For instance, many of the schemes have undefined behaviors when more than one CCI application tries to register with the browser. The main threats of interest, however, involve attacks where the adversary attempts to force the PGP-CCI application to inadvertently sign or decrypt attacker-chosen data using the client's private key. To guard against this, the processes of signing or decrypting data with the user’s private key should be explicitily performed by the user. Also, in CCI protocols where communication can take place across machine, it is essential that care is taken to only communicate with CCI applications on the same machine as the browser.
An important aspect of this type of design is the set of performance tradeoffs involved, and these have yet to be tested and quantified. We also hope to consider schemes for handling multiple simultaneous security-oriented CCI applications; this might be possible using one "master" security CCI application which routes data between the browser and several other CCI applications. Additionally, we would like to investigate the applicability of new mail object security proposals, such as MOSS (MIME Object Security Services) and Secure-MIME, to the CCI-based security approach.
The systems described in this document demonstrate the feasibility of using a security package like PGP with the general-purpose Common Client Interface in order to achieve strong authentication and encryption of Web communications. The PGP-CCI and PGP-POST schemes may be lacking in simplicity and elegance, due primarily to the constraints of CCI and HTTP. We hope that the new protocol extension features proposed for HTTP 1.2, along with next-generation browser interfaces combining elements of both CCI and the Spyglass SPM architecture, will help to rectify this situation.
Finally, we feel that the ability to handle document-level security enhancements, via CCI or other products, will be of increasing interest in the near future. As the World Wide Web grows to include commercial digital publishing, online electronic commerce, and wide-spread caching, we suspect that document security will become at least as important as the security of channels and messages.
Note: the current version of this spec can be found at http://sdg.ncsa.uiuc.edu/~jweeks/www4/paper/current_rev
Adam Cain [
http://www.ncsa.uiuc.edu/People/acain]
acain@ncsa.uiuc.edu
Briand Sanderson [
http://sdg.ncsa.uiuc.edu/~briand/]
briand@ncsa.uiuc.edu
Software Development Group
National Center for Supercomputing Applications
152 Computing Applications Building
605 E. Springfield Ave.
Champaign, IL 61820