Authentication and Squid

Listen Print

by Jennifer Vesperman
08/09/2001

About HTTP authentication

HTTP authentication uses the same basic protocols for HTTP web servers and HTTP proxy servers. These protocols have two authentication modes: basic and digest mode. In basic mode, the client passes the user name and the password to the server as a single base64-encoded block. In digest mode, the server encodes the password with a different key in a unidirectional function and the client decodes the function using the password, then returns the key. This proves that the client knows the password, without actually transmitting the password at any point.

To the server (web or proxy), HTTP authentication is stateless. To most clients, it is not -- within a given session, most clients retain user name/password pairs for host names and paths (more accurately, for HTTP realms) that have previously requested authentication.

If the client already has a user name/password pair for a URL, it sends them the page request. If the client does not send the authentication data with a request for a page that requires authentication, the server sends an authentication challenge before sending the page. The client receives the challenge and asks the user for the user name/password pair to send.

The usual method for preventing another user with the same client from using your user name and password is to close the client. This ends the session, and most clients then discard existing user name/password pairs.

Some browsers are persistent and exist for the duration of the desktop being active. Some versions of these will discard user name/password pairs when the HTTP browser is closed, but some versions appear not to.

Because the protocol is stateless for the server, the server cannot (within the protocol) block authentication from multiple clients using the same user name, or log a user out. Patches to server software can be written to force logout-like behavior in a client, or to block multiple clients based on IP addresses, but these are not supported by the protocol and may be ineffective or risky.

Squid has a configuration option (authenticate_ip_ttl) to make authentication "sticky" to the IP address for a period of time. The default is 0 seconds, which is not sticky and therefore correct to the protocol.

Proxy authentication

Related articles:

Using Squid on Intermittent Connections

Installing and Configuring Squid

Share your experiences using ACLs in Squid.
Post your comments

Proxy server authentication uses the same protocols and techniques as web server authentication, but sends a challenge with the proxy-authenticate field rather than the www-authenticate field. Digest mode is written into the protocol, but proxy authentication is currently unsupported in many browsers and most HTTP proxy and cache servers.

In a chain of proxies, proxy authentication is consumed by the proxy closest to the client which requires authentication, and the authentication information is then not passed to parent proxies. Note that proxies that do not require authentication are not guaranteed to pass proxy authentication further up the chain.

User to proxy authentication

Squid user authentication is set up in $SQUID-HOME/etc/squid.conf. The sections that must be configured are:

The realm
The access control list
The authentication module

You must also compile and install your authentication module.

The realm

The realm is configured with the line proxy_auth_realm.

The user sees the realm in the user name/password request dialog. The default is Squid proxy-caching web server, but you may want to change it from the default as user authentication is done against the realm.

# realm example
proxy_auth_realm Squid proxy-caching web server

Pages: 1, 2, 3