next up previous contents index
Next: 6.9.7 Summary: object caching Up: 6.9 Details of Cache Previous: 6.9.5 Negative caching and

6.9.6 Security and privacy implications


WWW browsers support various authorization mechanisms, all encoded in MIME headers exchanged between browser and server. The basic authorization mechanism involves clear-text exchange of passwords. For protection from eavesdropping, a Public Key authorization mechanism is available. Here, the server announces its own public key in clear-text, but the rest of the exchange is encrypted for privacy. This mechanism is vulnerable to IP-spoofing, where a phony server can masquerade as the desired server, but the mechanism is otherwise invulnerable to eavesdroppers. Finally, for those who want both privacy and authentication, a PGP based mechanism is available, where public key exchange is done externally.

For example, a basic authentication exchange follows the following dialog:

        Client: GET <URL> HTTP/1.0
        Server: HTTP/1.0 401 Unauthorized -- authentication failed
        Client: GET <URL> HTTP/1.0
                Authorization: <7-bit-encoded name:password>
        Server: One of:
                  Reply (authorized and authenticated)
                  401 Unauthorized (not authorized)
                  403 Forbidden (not authenticated)
                  404 Not Found

Note that the basic and public key schemes offer roughly the same degree of security as Internet rlogin. Their authentication relies on client IP addresses, which can be spoofed, and they assume that intruders do not masquerade as real servers. Their authorization relies on user names and passwords, which can be snooped.

When a server passes a 401 Unauthorized message to a cache, the cache forwards it back to the client and purges the URL from the cache. The client browser, using the desired security model, prompts for a username and password, and reissues the GET URL with the authentication and authorization encoded in the request MIME header. The cache detects the authorization-related MIME header, treats it as any other kind of non-cacheable object, returns the retrieved document to the client, but otherwise purges all records of the object. Note that under the clear-text basic authorization model, anyone, including the cache, could snoop the authorization data. Hence, the cache does not weaken this already weak model. Under the Public Key or PGP based models, neither the cache nor other eavesdroppers can interpret the authentication data.

Proxy-caching defeats IP address-based authentication, since the requests appear to come from the cache's IP address, rather than the client's. However, since IP addresses can be spoofed, we consider this liability an asset of sorts. Proxy-caching does not prevent servers from encrypting or applying digital signature to their documents, although encryption disables caching.

As a final issue, unless Web objects are digitally signed, an unscrupulous system administrator could insert invalid data into his proxy-cache. You have to trust the people who run your caches, just as you must trust the people who run your DNS servers, packet switches, and route servers.

next up previous contents index
Next: 6.9.7 Summary: object caching Up: 6.9 Details of Cache Previous: 6.9.5 Negative caching and

Duane Wessels
Wed Jan 31 23:46:21 PST 1996