listen only on loopback if restricted to localhost

[dneuge]

To improve security, installations which only allow access by host-local IPs should by default be restricted to loopback interface.

There should be an option to bind to all interfaces. When disabling that option, user should be asked for confirmation if any remote IPs have been listed. When adding a remote IP user should be asked if option should be automatically enabled. Changing the option will require a server restart.

On config migration check previous IP list and set default accordingly.

[dneuge]

This turns out to be a bit more difficult to handle:

• each HTTP server instance can only bind to a single address but it may be needed to support both IPv4 (with exotic addresses) and IPv6
• previous default configuration allowed access from 127.0.0.1 and ::1
• when using a fixed IPv4 address of 127.0.0.1 it may not match the loopback address used on some more exotic configurations which use some other address from 127.0.0.0/8
• when using a fixed IPv6 address of ::1 users might try to access 127.0.0.1 instead of localhost which would fail
• InetAddress#getLoopbackAddress() returns either some address from 127.0.0.0/8 (which again may not match the user's expectation) or ::1 (no choice given on API)
• InetAddress#getLocalHost() could in theory return some IP address that is not from a loopback device (depending on how users set up their system) and thus may provide a false impression of security

While most users probably should be fine with just 127.0.0.1 it seems that it cannot be implemented easily without causing confusion for some users. Implementing it only for new users (blank configuration) could be an option but it might still confuse users who simply reset their configuration.

When introducing a restriction to loopback addresses it may be best to notify users with a dialog on first start to inform them and interactively ask for a decision to either keep the old behaviour or confirm to restrict access. A silent migration probably would only cause trouble.

The current whitelisting approach means the only attack vector would be a critical error in Apache HTTP Core before the whitelisting can deny access. As the proxy only reformats public data from fixed addresses there currently appears to be no risk for any information leak (unless an error in HC would open up access that is not provided otherwise). This temporary tool's user base is a rather closed community whose majority can be easily notified in case of any issues. Thus, spending the extra time needed to implement a solution as described above seems out of proportion.