3

I read about the Silk Road incident and wondered if it's possible for Tor relays to physically host services and distribute the load of executing the service across the network, while the service and the operator's identity remain anonymous.

That way, the service is decentralized and does not lead to the person's real identity.

I would like to create a PoC, but I'm not completely sure if it's theoretically secure enough to accomplish this, so I'd like to run it by this forum.

Hosting "web" hidden services with static files (such as html, css, js, etc) would be the easy part; it's exactly like p2p file sharing, but

how could it be possible for Tor relays to execute the application code?
how can the web application hold stateful information for users?
can data be tampered by one of the many clients hosting the web service?
is it possible for Tor to support the load balancing?
how can the website be updated by the developer?
is there any other problem that I'm not aware of?

Kindest Regards

Improve this question
8
  • ...encrypt all data with PGP... Who will own the encryption and decryption keys? ...the web service's application logic can be reverse engineered... You want to obscure the application somehow? How do you want to do it? --- I am not sure if this post is on-topic here. It does not seem to be specific to Tor. The same problem can be solved on other anonymization networks.
    – pabouk - Ukraine stay strong
    Commented Oct 21, 2013 at 21:55
  • @pabouk user data will be encrypted with pgp. When a user saves personal database information, they encrypt it with their own pub key and access it with their private key. I don't think obscurity is the right choice. Maybe there could be a main server that contains a message digest of all website applications so users can first check webapp hasn't been tampered. I understand why this could be off-topic, but it could be specific to TOR; wouldn't it have to behave hand-in-hand with TOR? For example, the load balancing problem.
    – user646658
    Commented Oct 22, 2013 at 1:51
  • As I can see this schema of encryption allows only 2 accessibility classes of data: public and user's private. I think this will limit the applications a lot. Many applications need to allow certain users to access some private data (added by other users) or derivatives of the data.
    – pabouk - Ukraine stay strong
    Commented Oct 22, 2013 at 2:02
  • @pabouk I didn't think of that. A sort of group encryption would be the solution, but I don't know of an existing one
    – user646658
    Commented Oct 22, 2013 at 2:51
  • This discussion would perhaps be more on topic on tor-talk, liberation-tech or...
    – adrelanos
    Commented Oct 22, 2013 at 4:03

4 Answers 4

Reset to default
3

You could store the state in something similar to BitMessage or Kademlia DHT.

Use some kind of a distributed database (like FreeNet) to store the static content (images, html templates, scripts and such).

Then you would need a client program that is basically a local server to retrieve the data, and process it (in a way that ensures the scripts don't leak or do anything otherwise nefarious, so no network access or access to local information). You can stick it in some kind of a virtual environment/jail. And finally make it accessible to a browser by hosting it locally (this browser should probably have the javascript turned off, or itself be a virtual environment).

If you want the data to be publicly writeable then you would probably want to setup some kind of anonymous public/private key signing.

The main problem is the time. BitCoin takes up to 10 minutes to authenticate a transfer. So there would be a while for your state change to propagate through the distributed network.

You also have to protect against spam. How do you ensure that I don't create a billion accounts and clog up the network. You could require proof-or-work similar to NameCoin. Or alternatively use a subscription based service (my node will only process and store content of users I'm interested in, FreeNet does something like that except its based on content accessed).

Improve this answer
7
  • Storing state quickly is the hardest part. Differencing snapshots of VMs start small, but get larger as more stuff changes. CounterMail and secure VPN services provide an interesting model. Servers are read-only, booting static LiveCDs with integrity verification. They access remote storage via secure channels for credentials and storing state. Remote storage could be distributed and redundant, with strong access control. It may be prudent to use local servers, to limit impacts of compromise. But they'd be read-only and signed, and would only connect to the network after verification.
    – mirimir
    Commented Oct 25, 2013 at 0:07
  • Edit: I don't know where CounterMail and secure VPN services get static images. They might netboot. But that would be harder to secure, unless the source were local. Even then, LiveCDs are harder to compromise if they're locked to hardware..
    – mirimir
    Commented Oct 25, 2013 at 0:17
  • I wouldn't recommend storing actual vm snapshots since there would be a lot of uneeded crap in them. Just store the data itself and the scripts that know how to process that data. If you have a chain of your changes you can retrieve the chain state change by state change as deltas. But it probably makes more sense to follow what Git does and hash everything, store snapshots of everything but lightweight ones based on the hashes. You could do a little of both delta and snapshots to save on space or just forget the histroy.
    – David C. Bishop
    Commented Oct 25, 2013 at 3:59
  • @David Thanks. I'll look more into BitMessage and Kademlia DHT. As for the spamming, I was thinking of monitoring services by cpu, memory, disk, network consumption along with users' demand for the service. Kind of like what an OS does to make sure processes don't hog the system
    – user646658
    Commented Oct 25, 2013 at 4:05
  • @mirimir I thought I read somewhere that machines that teleport don't allow snapshots (including src & dest) so I was wondering if I could clone and distribute a VDI (with Talhoe-LAFS) instead and then I found out about immutable images. They seem ideal. It can be reused by multiple vm's, and it starts from scratch when it reboots. With snapshots, the operator can have a type of version control which sounds really cool! Would really like to hear your thoughts about this approach
    – user646658
    Commented Oct 25, 2013 at 4:14
1

This is the way to go, I think. Data and servers hidden in meatspace are clearly dead roads. Tor hidden services are only hidden until adversaries find the servers while they're running ;)

Also, porting standard Internet systems to networks of hidden services is painful. Better would be building normal networks among hidden services, using aggregated links that are fast and fault-tolerant. Data would be stored in fragmented and redundantly-distributed filesystems such as Tahoe-LAFS. Servers would be light and mobile VMs, able to migrate (or die and be reborn) across the network to handle load, and to respond to threats. Also, servers would be generic, pulling their configuration and data from the distributed filesystems, and updating state in real time.

Given fragmentation and redundant distribution, individual hidden services would hold only encrypted pieces of various components. That provides strong plausible deniability, much like running a Tor relay.

Only the first piece of this is on-topic for tor.se, and it's arguable that it's largely so as a threat like BitTorrent ;) You can find me at 0x17C2E43E.

Improve this answer
4
  • Tahoe-LAFS sounds great. I'll look more into it. Also, from the link you gave me in the comments to my question, I learned about Freesites. I guess it's easy to host a serverless, dynamic web page with pure javascript, but can it handle "state"? Can the website process transactions? I commented about running a webapp in a stateful, serverless environment would require too much code change from the developer. I think I'm starting to lean towards a solution of a web technology stack that provides state and consists of public/private key encryption, javascript and Tahoe-LAFS.
    – user646658
    Commented Oct 22, 2013 at 8:01
  • I'm thinking of moving running VMs over networks. Tahoe-LAFS filesystems could provide the required shared storage. The networks would be virtual and private.
    – mirimir
    Commented Oct 22, 2013 at 10:01
  • I think I understand now. Teleportation sounds interesting. Would this mean the webapp has to work as if it was running on multiple servers? And the developer would have to setup his own VM with the proper environment? That would sound ideal, but I wonder how well it'll perform. Did I understand you correctly? if so, then I stand corrected, this is not Tor specific.
    – user646658
    Commented Oct 22, 2013 at 18:52
  • I don't (yet) know the specifics of using teleporting VMs as webservers. I do gather that teleporting is typically used within data centers, with low latency and high bandwidth. So maybe it's unworkable over the Internet, let alone over Tor. Maybe there is a way to implement your idea directly on Tor. That would be on topic here. But it would probably be harder than for generic networks, and not reusable even if it worked.
    – mirimir
    Commented Oct 23, 2013 at 6:46
1

The sixth Immutable Law of Security states, "A computer is only as secure as the administrator is trustworthy," so it is theoretically unsafe to host a service in a Tor relay, especially if you don't know the administrator. Actually, the same goes for any hosting service provider -- you never know who is working there -- but I'd be more worried trusting a Tor relay.

It's possible to execute encrypted code with "Homomorphic Encryption." This is still under research and development and has been for the past decades, but there has been huge progress this year with its performance. Fujitsu thinks it can have commercial applications ready by 2015.

http://www.fujitsu.com/global/news/pr/archives/month/2013/20130828-01.html

To my knowledge, homomorphic encryption can only protect confidentiality, so you'd still have to trust the administrator with integrity. The same problem remains though: if your IP is unmasked, your service can be physically taken down and your real identity is at huge risk (especially if you once logged in with your real IP or paid the host provider with your credit card.) A decentralized, peer-to-peer network would help in this case, but I think Tor shouldn't be involved. This deserves its own network.

How it should be implemented is a difficult question to answer. David C. Bishop's suggestion is one way of doing it (see his answer), but as mentioned, it is off-topic and not related to Tor, just anonymity.

I would like to further discuss the possibility of creating an anonymous p2p host providing network. If anyone can suggest the appropriate place to take this discussion, please say.

& Thank you to mirimir and David C. Bishop. Your answers were very helpful. :)

Improve this answer
0

You could run a Tahoe-LAFS grid inside Tor to have a distributed, plausible-denial filesystem. To serve this filesystem(s) over out-of-the-box webservers you might be interested in https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2144 .

Improve this answer
2
  • Could you provide any instructions or reference on how to actually accomplish this?
    – Andrew Lott
    Commented Dec 28, 2013 at 18:57
  • This doesn't answer the question of how to "execute" code on strangers' web servers, yet my question is very unclear -- not even I know what I'm asking. I'll try to clarify the question and after much research, answer it as well. Thank you
    – user646658
    Commented Dec 29, 2013 at 2:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .