Access control - The Polipo Manual
Description: The Polipo Manual

Previous: Client connections, Up: Client connections

#### 3.1.1 Access control

By making it possible to have Polipo listen on a non-routable address (for example the loopback address ``127.0.0.1`'), the variable `proxyAddress` provides a very crude form of access control: the ability to decide which hosts are allowed to connect.

A finer form of access control can be implemented by specifying explicitly a number of client addresses or ranges of addresses (networks) that a client is allowed to connect from. This is done by setting the variable `allowedClients`.

Every entry in `allowedClients` can be an IP address, for example ``134.157.168.57`' or ``::1`'. It can also be a network address, i.e. an IP address and the number of bits in the network prefix, for example ``134.157.168.0/24`' or ``2001:660:116::/48`'. Typical uses of ``allowedClients`' variable include

         allowedClients = 127.0.0.1, ::1, 134.157.168.0/24, 2001:660:116::/48

or, for an IPv4-only version of Polipo,

         allowedClients = 127.0.0.1, 134.157.168.0/24

A different form of access control can be implemented by requiring each client to authenticate, i.e. to prove its identity before connecting. Polipo currently only implements the most insecure form of authentication, HTTP basic authentication, which sends usernames and passwords in clear over the network. HTTP basic authentication is required when the variable `authCredentials` is not null; its value should be of the form ``username:password`'.

Note that both IP-based authentication and HTTP basic authentication are insecure: the former is vulnerable to IP address spoofing, the latter to replay attacks. If you need to access Polipo over the public Internet, the only secure option is to have it listen over the loopback interface only and use an ssh tunnel (see Parent proxies)1.

#### Footnotes

[1] It is not quite clear to me whether HTTP digest authentication is worth implementing. On the one hand, if implemented correctly, it appears to provide secure authentication; on the other hand, and unlike ssh or SSL, it doesn't make any attempt at ensuring privacy, and its optional integrity guarantees are impossible to implement without significantly impairing latency.