btcpayserver-docker
btcpayserver-docker copied to clipboard
btcpayserver
Tor-only mode
I note here that:
Tor is a really tricky software to use for developers, as the slightest mistake can tear down the anonymity it provides. As BTCPay is evolving into a rather complex service and adding more and more plugins, even if we tried to route all this trafic through Tor, we couldn't guarantee that there would never be leaks of data in clear.
And here:
Using TOR for privacy in an app is even harder than making sure your wallet is not compromised. As a developer, you need to be careful that all the code paths sending HTTP requests in your application forward the request to the SOCKS proxy. Any mistake, and you are leaking DNS queries and information which can be used to expose you. And because we don’t control all plugins and third party code interacting with BTCPay, we can’t ensure any guarantee.
I'm just wondering what the BTCPayServer folks' opinion is on utilising two unique networks inside Docker. For example:
version: "3"
services:
internalService:
networks:
- internal
image: ubuntu
command: ["sleep", "1d"]
externalService:
networks:
- internal
- external
image: ubuntu
command: ["sleep", "1d"]
networks:
internal:
internal: true
external:
internal: false
Attempting to connect to the internet on any internal service fails:
$ docker-compose exec internalService apt update
Err:1 http://security.ubuntu.com/ubuntu bionic-security InRelease
Temporary failure resolving 'security.ubuntu.com'
[...etc...]
Where as the same command on the externalService works fine:
$ docker-compose exec externalService apt update
Get:1 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
[...etc...]
Finally, the two services can still communicate:
Host the server (for example a Tor socks proxy):
$ docker-compose exec externalService python3 -m http.server
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
Connect from the internal service:
$ docker-compose exec internalService curl http://externalService:8000/
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
[...etc...]
This would mitigate a large portion of risk, at least from my understanding. If Tor was configured to be the only service inside an external network and the entire rest of the suite was configured as internal services (btcpayserver & bitcoind & nginx & lnd_bitcoin, etc...) then any attempt to connect that wasn't proxied through Tor would just result in a network failure (as there would be no gateway to the internet).
Has this been considered? What is the logic behind not supporting this sort of system?
Thanks, and I love your software!
@Technifocal interesting idea indeed. However those services need to connect to internet, like BTCPay need to fetch rates from exchanges.
Maybe it is possible to autmatically route the traffic through a Tor proxy without the app knowing it, but I don't really kknow how to do.
@NicolasDorier So there's a few ways I can think about doing this, but the most reliable way would be to just configuring all the software to be SOCKS aware. Part of the configuration of opt-force-tor (or whatever) would be setting up configurations for all the software to get the correct SOCKS information.
Other options, though less reliable, would be software like Torsocks which attempts to proxy all traffic from an application through Tor. One of the benefits of running inside a docker instance with no network traffic is that if Torsocks fails, it should fail safe (I.E. no data leakage).
I'm not up to spec on BTCPayServer's code, but a lot of the applications it depends on seem to support Tor out of the box (Bitcoind, Lnd, etc...) so maybe the first option wouldn't be insanely difficult?
but the most reliable way would be to just configuring all the software to be SOCKS aware
There is like 30 different possible optional dependency (processes not libraries) and growing on btcpay, most of those project are not maintained by us, so we can't do this. This might be possible for subset though (like only btcpay + lightning + btc).