Hi All,
There must be discussion of this I'm not finding so references to that are welcomed.
As I understand it there are three risk layers in each Tor node:
1) The node operator (who has r00t) 2) The data center (who has net) 3) The legal jurisdiction
I've recently started running a couple of relays on public IaaS providers. To my thinking this doesn't present significant security issues beyond a hosted physical server, largely because they are not running hidden services or using Tor to anonymize their own traffic. Presumably memory inspection on the underlying hypervisor could easily reveal that.
Most of what could be discovered from hypervisor monitoring seems liek it could also be discovered by traffic analysis available to any datacenter provider should they choose or be compeled to.
The one novel thing this may make easier is stealing the hosts private keys, which would make traffic analysis easier (but I don't thing significantly better) and allow impersonation of the node which would not otherwise be possible (well it maybe possible to steal from memory on a running system given physical access and sufficient equipment, time and expertise but nearly impossible if not actually so).
What is the consensus level of paranoia on this?
Are there threats to virtualized systems I'm not considering?
Thanks, -Jon
On Tue, Oct 01, 2013 at 04:42:53PM -0400, Jonathan D. Proulx wrote:
As I understand it there are three risk layers in each Tor node:
- The node operator (who has r00t)
- The data center (who has net)
- The legal jurisdiction
I've recently started running a couple of relays on public IaaS providers. To my thinking this doesn't present significant security issues beyond a hosted physical server,
[snip]
The one novel thing this may make easier is stealing the hosts private keys, which would make traffic analysis easier (but I don't thing significantly better) and allow impersonation of the node which would not otherwise be possible (well it maybe possible to steal from memory on a running system given physical access and sufficient equipment, time and expertise but nearly impossible if not actually so).
I'd assume that any private keys present in RAM on an IaaS cloud are disclosed to the cloud vendor, and thence to the NSA. It's a tiny matter of software to do this, and the vendors explicitly give themselves permission to do so in the ToS you agreed to, so why wouldn't they?
I'd welcome a public (and ideally legally binding) statement from an IaaS vendor that they do not disclose customer keys. A "transparency report" disclosing how many law enforcement / intelligence community (LE/IC) requests were satisfied, and how many keys were disclosed, would go a long ways towards closing the credibility gap here.
The picture with colo hardware is a little more nuanced. If you rent hardware from a vendor it probably is managed via IPMI, which is probably hooked up to a VLAN with other devices on it, which is a rat's nest of vulnerability: http://fish2.com/ipmi/how-to-break-stuff.html https://www.usenix.org/conference/woot13/illuminating-security-issues-surrou...
Even if your server cannot be compromised by an IPMI network attack, an attacker with physical access (due to a subpoena, NSL, bribery, or surreptitious insertion) can deploy a commercially available hardware attack against USB or PCIe to extract key material.
In summary, it seems likely that IaaS is pwned wholesale. Colo hardware is somewhat more expensive to attack and possibly succeeds in raising the bar from "software" to "attacker has to roll a truck to pwn me", which is my current recommendation for threat modeling.
-andy
On Tue, Oct 1, 2013 at 7:35 PM, Andy Isaacson adi@hexapodia.org wrote:
In summary, it seems likely that IaaS is pwned wholesale. Colo hardware is somewhat more expensive to attack and possibly succeeds in raising the bar from "software" to "attacker has to roll a truck to pwn me", which is my current recommendation for threat modeling.
I'd generally agree... people should treat remote nodes as tossers. You could epoxy them up, encrypt them and run your remote monitoring shell. But eventually that will drop and you must assume the possibility of physical access regardless. At least with Tor and p2p in general, the idea is more to distribute nodes widely and hopefully in enough quantity to keep the odds of whoever owns the nodes, in whatever way, in your favor.
The community should make node placement more of a process under some metrics to avoid placement collisions. 'myfamily' is a concept that spans more than just the operator.
On Wed, 2 Oct 2013 02:21:13 -0400 grarpamp grarpamp@gmail.com allegedly wrote:
The community should make node placement more of a process under some metrics to avoid placement collisions. 'myfamily' is a concept that spans more than just the operator.
An interesting, and very valid point. One drawback of the advertisement of "tor friendly" ISPs (either on the list or on the wiki) could be a tendency to cluster nodes to the detriment of the network.
Mick
---------------------------------------------------------------------
Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 http://baldric.net
---------------------------------------------------------------------
On Tue, Oct 01, 2013 at 04:35:15PM -0700, Andy Isaacson wrote:
:In summary, it seems likely that IaaS is pwned wholesale. Colo hardware :is somewhat more expensive to attack and possibly succeeds in raising :the bar from "software" to "attacker has to roll a truck to pwn me", :which is my current recommendation for threat modeling.
I'll grant all that, but what does it get an attacker over traffic analysis in and out of that data center which is already easy in software?
Again assuming the node is just a relay and not generating any traffic of its own that should be anonymised.
-Jon
On Wed, Oct 02, 2013 at 08:34:05AM -0400, Jonathan D. Proulx wrote:
On Tue, Oct 01, 2013 at 04:35:15PM -0700, Andy Isaacson wrote: :In summary, it seems likely that IaaS is pwned wholesale. Colo hardware :is somewhat more expensive to attack and possibly succeeds in raising :the bar from "software" to "attacker has to roll a truck to pwn me", :which is my current recommendation for threat modeling.
I'll grant all that, but what does it get an attacker over traffic analysis in and out of that data center which is already easy in software?
If an attacker can capture (using a fiber tap or backbone port) and decrypt (using private keys captured from an IaaS vulnerability) inter-node traffic, then they would be able to deanonymize entire flows. This would be significantly more powerful than just traffic analysis since it gives plaintext in addition to metadata.
However, I *think* (not sure) that merely capturing the Tor node's long term identity key, plus capturing all the ciphertext on the wire, does not allow decryption of sessions, because ephemeral session keys with DH key exchange saves us. The attacker needs to capture the ephemeral keys, which turns the proposed IaaS key-capture compromise into an ongoing activity rather than one-time affair.
-andy
tor-relays@lists.torproject.org
-
Andy Isaacson -
grarpamp -
Jonathan D. Proulx -
mick