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.