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
Every entry in
allowedClients can be an IP address, for example
‘18.104.22.168’ 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 ‘22.214.171.124/24’ or
‘2001:660:116::/48’. Typical uses of ‘allowedClients’
allowedClients = 127.0.0.1, ::1, 126.96.36.199/24, 2001:660:116::/48
or, for an IPv4-only version of Polipo,
allowedClients = 127.0.0.1, 188.8.131.52/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
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)4.
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.