Security and Proxies

Since their introduction, proxy caches have proved to be a very valuable resource:

• Permit access to the Web to machines behind a firewall.
• Decrease access times through use of caching proxies.

Proxy caches provide a significant challenge to the design of a Web security scheme. It is important to send any information that will assist a proxy and not compromise security.

A proxy may be a trusted or an untrusted agent. In the same transaction a proxy may be trusted by one party but not the other. A proxy may also be used to provide authentication and privacy enhancements.

Using a firewall proxy to add or modify security.

In many cases an organisation will not wish to have unreadable traffic on its internal network. Such channels might be used to export confidential information without authorisation or might be used to conceal malicious use.

It may also be convenient to concentrate security administation effort with respect to external organisations at a single point. Making the firewall proxy responsible for adding and validating external signatures allows certificate maintenance to be dealt with in a centralised manner.

For the purposes of argument let us consider a case in which the private network is insecure and the proxy is responsible for providing security.

The security enhancing proxy model is also appropriate in cases where the internal network is encrypted. For performance reasons the most practical scheme to maintain such a network would routinely employ symmetric key encryption and authentication. The symetric keys being distributed at regular intervals (eg 1 day) via a public key scheme. In such a case the firewall proxy would validate and remove the private key encryption and replace with public key encryption for external use.

Caching through an untrusted proxy.

In many cases a document may be stored on a server that is not trusted to authenticate it. A typical document for which this would be the case is a standard issued by an organisation. The standard is a public document and so it is a proper item to be cached. It may also have an expiry date and so the authenticity must be checked for each transaction.

It is suggested that an additional conditional request tag be introduced to handle this situation, If-Modified: Digest. This tag would be analogous to the If-Modified-Since: tag except that a message digest would be provided. The existing tag is unsuitable since it causes the last access date of the object in question to be revealed.

If the proxy received a request for a document in cache then it would send a conditional request to the trusted server. If the document was unchanged the server would send the response code Not Modified 304 as usual but with a signed digest for the header as if the document had been sent. The untrusted proxy would then use this header to assemble a message with the signed header and body.

The Need for the Digest-Boundary Tag.

The need to pass requests through proxies means that a header may in certain circumstances be signed multiple times. In this case each signature may incorporate different data. In addition the URL request and response code may vary as the message is passed from server to server. These constraints make it impractical to incorporate the method line or status response in the digest envelope.

The envelope of a Digest-Head tag is from the corresponding Digest-Boundary up to and including the CRLF pair preceeding the tag. Thus header lines placed after the tag are not authenticated. This mechanism allows proxy servers to sign requests as they are passed on without affecting the digest value.