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)⁴.