I think we need to discuss ways to implement limitations on the client side. The current version of boringproxy allow for a tunnel to be set up to any address/port connected to the client device. This essentially extend the LAN network of the client device to the cloud server.
Having the ability to create a tunnel to a device on the LAN of the client device is useful. It allows for docker containers to use boringproxy and it also allows connection to devices that can’t run boringproxy like CCTV cameras. Therefore I am not saying boringproxy should be limited to localhost, but even on localhost there should be limitations on the ports accessible via boringproxy.
For users that own their own server and set it up securely, this should not be a problem. You essentially have an always on VPN between a cloud device that you own and your local network. The biggest issue comes in for shared servers. Since the tokens are stored in plain text on the server, the admin (or anyone with access to the server) can obtain the token for clients [encrypting tokens on the server is a future discussion]. They can then create additional tunnels to devices on the client network.
I suggest we change the default of the client to only allow boring to localhost port 80. If the user want to allow access to additional ports/hosts it needs to be added with a whitelist flag. The client will then check the whitelist before making the tunnel and if the host/port requested by the server is in the whitelist, the tunnel is established otherwise it errors out.
The goal would be to create a whitelist (or blacklist) with sufficient functionality, while also keeping the implementation simple.
Some of the things to discuss:
- Should default be
block all
,block most
orallow all
? - If default is
block most
, what do we allow? Perhaps onlylocalhost:80
or entirelocalhost
? - Should we create multiple flags with increased complexity that override each other. The basic flag can be
localhost-only: yes/no
with additional flags includingwhitelist: ["192.168.0.4:80","192.168.0.5:5432","localhost:22"]
. A basic user can then use thelocalhost-only
flag to choose between local only and entire LAN, where an advanced user can add thewhitelist
flag that would override thelocalhost-only
flag and only allow tunnels to hosts:ports in whitelist?
Please give your thoughts. I haven’t written any code of this, I think its a good idea to first discuss it to find the balance between complexity and usability. We don’t want to sacrifice functionality in the pursuit of simplicity, but it also does not help if we create an overcomplicated system that no one can use.