[tor-dev] Potential projects for SponsorR (Hidden Services)

[David Stainton]

Any Twisted application written in a network endpoint agnostic manner
may be used with the txtorcon hidden service endpoint...
For instance serving files from a Tor hidden service can be done with
Meejah's one-liner:
pip install txtorcon && twistd -n web --port "onion:80" --path ~/public_html

However I see the current txtorcon design (without 12911 resolved) as
lacking security isolation since tor is launched as the same user as
the python process. Using the control port to create hidden services
seems like the obviously better way to do this.

Currently Tahoe-LAFS is used with torsocks and manually configured Tor
hidden services in order to hide the the identity of the tahoe client
and server operators. We'd like for Tahoe-LAFS to have native Tor
integration... Using the txtorcon endpoint would greatly simplify
deployment for Tahoe-LAFS storage operators wishing to hide their
identity/location.


David

On Tue, Oct 28, 2014 at 10:40 PM, meejah <meejah at meejah.ca> wrote:
> Nick Mathewson <nickm at torproject.org> writes:
>> On Mon, Oct 20, 2014 at 9:37 AM, George Kadianakis <desnacked at riseup.net> wrote:
>
>>> this is an attempt to collect tasks that should be done for
>>> SponsorR. You can find the SponsorR page here:
>>> https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR
>
> I see that #11291 is not on that list. I think it should be.
>
>> * Get somebody who wants to access hidden services over the controller
>> API to explain what they want to build.  Then design an API as needed
>> to support it.
>
> Currently, at least the way Tor is deployed on Debian, you cannot add a
> new hidden-service to a running Tor if you're "just" in the right group
> (in this case, debian-tor). #11291 would fix this, and is pretty close;
> dawuud has a branch that's got more utests etc (*not* asking for more
> review yet ;) )
>
>> * Look at what somebody might want to do with hidden services via the
>> controller API; then design an API to expose that.
>
> One issue with hidden services and the overall controller API, is that
> they are the only "special" thing that has multi-line configuration
> where order matters. So controllers have to do "non-trivial" things to
> make hidden serivces "go".
>
> Unfortunately, I don't have a concrete suggestion here, beyond "take a
> ground-up look at the controller API", which I'm guessing is
> out-of-scope? Basically, something more structured might make sense?
> *However* since hidden services are the only thing that actually makes
> order important (as far as I recall), perhaps re-thinking those alone
> within the existing framework would be much less disruptive *and*
> simplify controller logic (i.e. eliminate the "order is important" bit).
>
> The only concrete use-case I can offer is carml's "pastebin" command,
> which would like to add and delete hidden services from a running
> Tor. Currently, it always launches a new Tor instance (so "add" is
> launch, and "delete" is kill). Perhaps this is the best way anway,
> separation-wise...?
>
> I can imagine that adding the equivalent of add/delete for
> authorize-client lines would be a Good Thing, too.
>
> Just brainstorming here, but could both the above be accomplished with
> some sort of "change configuration" command? That is, instead of forcing
> controllers to remember enough to make a SETCONF work, the opportunity
> to add or delete things exists? (And perhaps only for hidden services,
> since they're the only "special" things currently anyway?) This probably
> implies an ID for each hidden service...
>
> This also would map fairly well to most UIs, which then just have to
> remember what the user did (e.g. "clicked delete on the 3rd line, then
> clicked add with options X, Y, and Z").
>
> --
> meejah
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev