tor2web mode for accessing hidden services

When the Tor client accesses a hidden service, it makes sure to get anonymity on its side, and the hidden service makes sure to get anonymity on its side.

How much of the crappy reachability properties for hidden services is due to the client-side circuits?

We should design a mode where the client either uses a one-hop rendezvous path, or uses itself as the rendezvous point. (We could imagine leaving alone the 3-hop circuit to fetch the rendezvous descriptor and the 3-hop circuit to reach the introduction point, on the theory that they're not critical-path once the connection is established; or we could ponder cutting them down some too on the theory that connection establishment is the critical path.)

Should be a new config option and a few changes to various constants. How could it go wrong? :)

Once we have it working, we should set up an alternate hidserv torperf (a la #1944 (closed)) to see how the designs compare.

Once we have some answers, we'll want to ponder if this is really something we want to leave in for arbitrary users to shoot themselves in the foot with (cf attractive nuisance).

changed milestone to %Tor: 0.2.3.x-final

added component::core tor/tor milestone::Tor: 0.2.3.x-final owner::rransom parent::2552 priority::medium resolution::implemented status::closed tor-hs type::enhancement labels

Trac:
Component: Tor Client to Tor hidden services

Replying to arma:

Once we have some answers, we'll want to ponder if this is really something we want to leave in for arbitrary users to shoot themselves in the foot with (cf attractive nuisance).

The simplest way to prevent accidental autodepeditation due to this feature is to refuse to connect to non-hidden-service hostnames when tor2web mode is on.

We could also make this feature harder to turn on by requiring that a tor2web Tor instance be run as a published relay and indicating in the relay descriptor that it is running in tor2web, so that only minimal further information can be gained by attempting to monitor introduction points and rendezvous points (thus removing one of the risks that led us to prohibit one-hop circuits).

Doing a design here is pending on results from the #1944 (closed) and #2554 (closed) analysis.

Trac:
Owner: N/A to rransom
Status: new to assigned

See feature2553 ( git://git.torproject.org/rransom/tor.git feature2553 ) for the beginnings of an initial implementation. Currently it builds many circuits that time out too quickly (I need to force LearnCircuitBuildTimeout off for now when Tor2webMode is on), and then when it attaches a stream to the one-hop rendezvous circuit, an assertion fails because Tor isn't ever supposed to do that.

See feature2553-v2 ( git://git.torproject.org/rransom/tor.git feature2553-v2 ) for an implementation that works well enough to be performance-tested. When I tried using this branch to connect to http://duskgytldkxiuqc6.onion/ non-anonymously, Tor successfully performed the directory fetch, introduced to the HS, and opened a rendezvous circuit using single-hop circuits.

This branch is based on my bug3332-v2 branch; see #3332 (moved).

This branch produced a ‘Duplicate call to connection_mark_for_close’ warning message when I tried to connect to a non-HS hostname (compiled with --enable-bufferevents), but at least one other case produces that message as well. See #3403 (moved).

Trac:
Status: assigned to needs_review

I think I like it!

Some code issues you shouldn't have to fix:

• I find the more complicated asserts hard to read. I'll refactor them if we merge, though; my confusion is my own problem.
• directory_initiate_command_routerstatus_rend()'s interface sure is hideous, isn't it? We should do something about that. Not a problem introduced by this patch, though.

Also, the security implications of having a "don't be anonymous" mode worry me some. Can we do more to make sure that no user ever thinks that turning this on is a good idea? The check in connection_ap_rewrite_and_attach is a good start, but I worry about accidentally breaking it later. Can we have this whole feature be disabled unless the user supplies a compile-time option, for instance? (Is there any reason not to do that?)

Also, have the tor2web people tried this out?

Replying to nickm:

I think I like it!

Some code issues you shouldn't have to fix:

• I find the more complicated asserts hard to read. I'll refactor them if we merge, though; my confusion is my own problem.
• directory_initiate_command_routerstatus_rend()'s interface sure is hideous, isn't it? We should do something about that. Not a problem introduced by this patch, though.

Also, the security implications of having a "don't be anonymous" mode worry me some. Can we do more to make sure that no user ever thinks that turning this on is a good idea?

A warning-level log message at startup and/or whenever the configuration is modified/reloaded is probably appropriate.

The check in connection_ap_rewrite_and_attach is a good start, but I worry about accidentally breaking it later. Can we have this whole feature be disabled unless the user supplies a compile-time option, for instance?

Yes. The best place to put a #ifdef is in src/or/config.c; it should require that Tor2webMode be unconfigured or off when the feature is not enabled at compile time, and it should require that Tor2webMode be explicitly turned on when the feature is enabled at compile time. (Otherwise distribution packages might turn the compile-time flag on for everyone, thus defeating its purpose.)

(Is there any reason not to do that?)

I didn't do that because I don't understand GNU autotools.

Also, have the tor2web people tried this out?

Yes. I'm CC-ing hellais, who says that he has tested this branch.

Trac:
Cc: N/A to hellais

Also, the security implications of having a "don't be anonymous" mode worry me some. Can we do more to make sure that no user ever thinks that turning this on is a good idea? The check in connection_ap_rewrite_and_attach is a good start, but I worry about accidentally breaking it later. I think a very clear and scary message at start should be displayed.

If we think this is a big issue, then maybe the best solution is have the tor2web client send something to Tor (via TorCtl or a magic request to SOCKS) and if this does not happen it does not allow any connection?

Can we have this whole feature be disabled unless the user supplies a compile-time option, for instance? (Is there any reason not to do that?)

If this gets merged into trunk I would like for people who wish to run tor2web to install Tor from the official repositories and just install the tor2web package. Having to also build Tor would be a bit redundant.

Also, have the tor2web people tried this out?

Yes. I'm CC-ing hellais, who says that he has tested this branch.

Yes, I have been testing this for the past month or locally and I want to deploy it on one tor2web node.

I would like to configure something that does benchmarking so that we are able to compare the effectiveness of the reduced hop count. The idea is to have one node run with tor2web node enabled and at the same time have another one run with tor2web mode disabled. For doing so I have a few options

1. Write a patch for tor2web 2.0 to include basic measurements such as latency and connection speed (this is a bit hacky and is not "Tor" aware)

2. Base something on torperf. I wonder though if it's possible to have something that uses real user requests, so as to be a test on what actually is happening when tor2web is being used.

3. Any other suggestions?

Replying to hellais:

If this gets merged into trunk I would like for people who wish to run tor2web to install Tor from the official repositories and just install the tor2web package. Having to also build Tor would be a bit redundant.

I understand where you're coming from here, but I really and truly am not happy with the idea of giving Tor a "not anonymous" mode in its default build. If folks want a "not anonymous" mode, I am okay with making them build or download an alternate build of Tor.

(If this is going to go 0.2.3.x, I will need the requested changes soon, to meet end-of-month merge window. Otherwise, it'll have to wait.)

Would you do this by having a configure parameter?

What is the best way to do this, since the modifications are split across multiple files?

Replying to hellais:

Would you do this by having a configure parameter?

I'm about to add an ENABLE_TOR2WEB_MODE #define; nickm will add a configure parameter to make the compile-time flag slightly easier to turn on.

What is the best way to do this, since the modifications are split across multiple files?

I plan to:

• turn some of the changes the #2553 (moved) branch made to assertions into #ifndef NON_ANONYMOUS_MODE_ENABLED blocks,
• require (in src/or/config.c) that the Tor2webMode run-time torrc option be turned on when Tor is compiled with ENABLE_TOR2WEB_MODE defined, and
• add a loud warning on startup and SIGHUP.

Trac:
Status: needs_review to assigned

Replying to rransom:

I plan to:

• turn some of the changes the #2553 (moved) branch made to assertions into #ifndef NON_ANONYMOUS_MODE_ENABLED blocks,
• require (in src/or/config.c) that the Tor2webMode run-time torrc option be turned on when Tor is compiled with ENABLE_TOR2WEB_MODE defined, and
• add a loud warning on startup and SIGHUP.

See new commits on my feature2553-v2 branch; or, see feature2553-v3 ( https://git.torproject.org/rransom/tor.git feature2553-v3 ) for a rebased branch with the reverted commits deleted and the new commits moved to more appropriate places in the branch.

These branches don't seem to have a changes/ file. Also, the new commits and branch are totally untested.

Trac:
Status: assigned to needs_review

Okay, I'll try to review and hopefully merge. Hellais, will you have time to test this version?

Trac:
Milestone: N/A to Tor: 0.2.3.x-final

Trac:
tor2webmode.diff

tor2web mode configure patch