[tor-dev] Request for feedback on public hidden services: shroud

[Alan Shreve]

Hi Tor devs!

I’d like your feedback on a new system to provide public hidden services that I call "shroud”. By “public hidden services”, I mean services whose network location cannot be determined (like Tor hidden services) but are accessible by any client on the internet (like hidden services + Tor2Web). I’ve linked to what I think is pretty comprehensive documentation at the end of this message, but here’s a brief summary:

Shroud runs over Tor with zero changes to the protocol but *does not* use the Tor hidden service protocol. At a very high level, shroud creates something like a reverse ssh tunnel *over* Tor from a local service to a public proxy. You then point DNS for a domain to the public proxy servers so that internet clients can talk to it. The public proxy servers multiplex TLS connections by inspecting the SNI data and forward the connection through to the appropriate shrouded service over its reverse tunnel.

Obviously, shroud makes a number of tradeoffs compared to traditional hidden services and Tor2Web, the most important being:
- Shrouded services have real hostname addresses and look just like any “ordinary” web service.
- Shrouded services (anecdotally) have better latency characteristics than Tor hidden services
- Shrouded services provide no anonymity for clients
- Shrouded services are dependent on their public proxy servers being available
- Shrouded services rely on DNS and are at the mercy of DNS providers and registrars (excepting things like modifying your /etc/hosts)
- Public proxies can not inspect or modify the connections they proxy because they are TLS-encrypted with keys they don’t own

Shroud is still very early in development, so I’m looking for feedback from the community on all aspects of the system from overall architecture to UI. In particular, I have a number of questions that I’m researching that I could use guidance on from those of you already steeped in Tor:

1. Shrouded services open up a single long-lived connection TLS connection to their public proxy. Is this a risk that could make it easier to de-anonymize a service? Would it be more difficult for an attacker to locate the service if the service opened a new connection over a new circuit every X seconds? Would it be more difficult for an attacker if the shrouded service communicated with the public proxy over multiple connections over multiple circuits simultaneously?

2. Right now shroud only allows you to tunnel TLS connections on domains you control with the idea that it eases the burden on public proxy operators (namely me). This is kind of akin to having an exit node with a policy that it only allows TLS connections out. Am I worrying too much about the consequences proxying traffic that could be inspected?  Allowing non-TLS services would make it *far* easier to set up a shrouded service because a shrouded service provider would 1. not have to own a domain, and 2. not need to create TLS key pairs and acquire certificates.

3. Is this a useful system? I feel like tor2web validates that there are use cases that could benefit from this type of asymmetric anonymity where only the service provider is anonymous, but perhaps someone else can indicate whether this is a path worth pursuing.

Links:
Source code and documentation: https://github.com/inconshreveable/shroud
More in-depth documentation on shroud’s architecture: https://github.com/inconshreveable/shroud/blob/master/docs/ARCHITECTURE.md

Pre-built binaries (just for testing/demonstration):
Linux: http://dl.shroud.io/linux_386/dev/shroud.zip
OS X: http://dl.shroud.io/darwin_amd64/dev/shroud.zip
Windows: http://dl.shroud.io/windows_386/dev/shroud.zip

Thanks!

- alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140408/c271ef34/attachment.html>