At Ablative we make an effort to minimize the amount of data we need to store about our customers and the amount of meta-data needed to manage the service. As we use Cryptocurrency instead of taking card payments we don’t need to be PCI compliant but we are concerned that there is a meta-data trail between every Bitcoin transaction (and Monero transaction if an adversary acquires your private keys) and you.
Ablative Hosting needs to monitor our servers and microservices for any strange or malicious behaviour, in certain cases we also need to be able to send logs across the Internet without exposing a link between the servers in question and our attributed infrastructure. To prevent either side of a log transmission event from knowing too much about each other and provide end-to-end transport encryption as well we can use Tor.
Ablative Hosting has several servers distributed around the globe in various data centers from various vendors, it is very important that any potential adversary not be able to identify that these servers are part of the infrastructure. There are three key points of correlation for these servers; Orchestration connections from the Ansible hosts Inter-host service communication polling (e.g. the cryptocurrency microservices connecting to our Bitcoin or Monero nodes) Metrics from the various servers Protecting Ansible using Tor Thankfully Ansible natively supports using SSH options so the host inventory uses .
One of the key elements of Ablative Hosting is that it will primarily use cryptocurrencies so it can’t have it’s funding sources pulled as happened to FetLife. Bitcoin transactions are entirely public, ZCash has issues when moving funds between shielded and normal addresses so for the customer who demands the utmost privacy the obvious choice is Monero. When I first set about implementing support for generating Monero addresses (and monitoring transactions to the that address) I had standardised on using nginx to reverse proxy connections to various daemons.