Assuming the supernode is running on an isolated host running only bitcoind plus armorydb, can you think of any security risks from allowing internet connections to armorydb (More specifically, to the http proxy that is used)?
That's the kind short question that leads to a very long answer.
As far the HTTP daemon is concerned, that stuff is pretty solid. Most attacks around these are not directed at the daemon directly but rather but trying to hijack the domain name registration (that won't happen since you're using IP directly), DDoS the service (that's what load balancing and DDoS protection are for), or hijacking the service running behind the daemon. In this case that would be ArmoryDB.
Ultimately ArmoryDB only handles public data. It receives public data from the clients and returns processed blockchain data. In that sense, any hijacking of the DB would effectively result in a DoS attack, not a leak of private keys.
There's a couple caveat to this:
1) The communication layer between the DB and clients is not encrypted, and you can't just shove HTTPS on top of it as it stands. It's therefor easy for an attacker to gather user addresses (on top of the service itself) by sniffing the service's traffic. In contrast, consider that users who would rather resort to such service instead of synchronizing the blockchain themselves either do not understand what financial privacy means or do not value it.
This boils down to a question of ethics then: do I offer a bad service to bad users?
2) Bad users probably don't use follow security practices. Most likely, they use hot private keys, on the same machine they are connecting to the WAN with. This now creates an alley for an attacker to try and access private keys from people connecting to the supernode service. Granted, the attacker would have to somehow hijack the supernode, and then try to hijack the Armory client instance of each individual he is trying to attack. Not an easy task, but then again I have no idea how vulnerable that layer is. Again, Armory was not designed with that use case in mind, it's supposed to operate in a friendly environment (connecting to your own DB over your own encrypted VPN).
Can you offer any kind of guidance as to what the bandwidth usage would be like, both upload and download?
1~100KB both ways at initial connection and per new block, depending on the size of the user's wallets.
What you should be concerned about is mostly the DB bootstrap. That code is not really optimized so it will be slow and resource intensive to sync it the first time around.
Show Posts
