Opened 7 years ago

Closed 6 years ago

Last modified 5 years ago

#2553 closed enhancement (implemented)

tor2web mode for accessing hidden services

Reported by: arma Owned by: rransom
Priority: Medium Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-hs
Cc: hellais Actual Points:
Parent ID: #2552 Points:
Reviewer: Sponsor:

Description

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) 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).

Child Tickets

Attachments (4)

tor2webmode.diff (932 bytes) - added by hellais 6 years ago.
tor2web mode configure patch
download.php?i=0bMB0Xex (129.5 KB) - added by rransom 6 years ago.
log dump
tor-info.log (997.3 KB) - added by hellais 6 years ago.
tor2web mode log
0001-Add-support-for-an-enable-tor2web-mode-DEB_BUILD_OPT.patch (1.3 KB) - added by rransom 6 years ago.
patch for the Debian package

Download all attachments as: .zip

Change History (43)

comment:1 Changed 7 years ago by arma

Component: Tor ClientTor hidden services

comment:2 in reply to:  description Changed 7 years ago by rransom

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).

comment:3 Changed 6 years ago by arma

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

comment:4 Changed 6 years ago by rransom

Owner: set to rransom
Status: newassigned

comment:5 Changed 6 years ago by rransom

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.

comment:6 Changed 6 years ago by rransom

Status: assignedneeds_review

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.

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.

comment:7 Changed 6 years ago by 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? 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?

comment:8 in reply to:  7 ; Changed 6 years ago by rransom

Cc: hellais added

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.

comment:9 in reply to:  8 ; Changed 6 years ago by 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?

comment:10 in reply to:  9 Changed 6 years ago by nickm

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.

comment:11 Changed 6 years ago by nickm

(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.)

comment:12 Changed 6 years ago by hellais

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?

comment:13 in reply to:  12 ; Changed 6 years ago by rransom

Status: needs_reviewassigned

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 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.

comment:14 in reply to:  13 Changed 6 years ago by rransom

Status: assignedneeds_review

Replying to rransom:

I plan to:

  • turn some of the changes the #2553 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.

comment:15 Changed 6 years ago by nickm

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

comment:16 Changed 6 years ago by nickm

Milestone: Tor: 0.2.3.x-final

Changed 6 years ago by hellais

Attachment: tor2webmode.diff added

tor2web mode configure patch

comment:17 Changed 6 years ago by hellais

rransom: you are awesome!

It compiles properly and appears to properly work. I will do some more thorough testing the next days.

I attach a patch for configure.in that adds the argument --enable-tor2webmode to enable at compile time tor2web.

Is it best if I push it to a branch or can you merge it from my diff?

comment:18 Changed 6 years ago by hellais

I pushed these changes to my repo: https://git.torproject.org/user/art/tor.git.

Am going to set this up on a real tor2web server and see how it works out.

We have some very basic benchmarking software, that hopefully will also provide some interesting measurements.

comment:19 in reply to:  18 Changed 6 years ago by hellais

Replying to hellais:

I pushed these changes to my repo: https://git.torproject.org/user/art/tor.git.

The branch name is feature2553-v3

Am going to set this up on a real tor2web server and see how it works out.

We have some very basic benchmarking software, that hopefully will also provide some interesting measurements.

comment:20 Changed 6 years ago by hellais

The patch does not successfully connect to HS.

The previous version of it (feature2553-v2) did work, so I believe it is something trivial.

I am not yet sure what it depends on, but any connection to a Hidden Service fails by timeout.
Nov 24 11:55:31.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit)
Nov 24 11:55:31.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit)

It appears that there are a lot of these lines:
Nov 24 12:08:54.000 [info] connection_ap_handshake_attach_circuit(): Intro (26496) and rend (0) circs are not both ready. Stalling conn. (22 sec old)
Nov 24 12:08:54.000 [info] connection_ap_handshake_attach_circuit(): Intro (26496) and rend (0) circs are not both ready. Stalling conn. (22 sec old)
Nov 24 12:08:55.000 [info] connection_ap_handshake_attach_circuit(): Intro (26496) and rend (0) circs are not both ready. Stalling conn. (23 sec old)
Nov 24 12:08:55.000 [info] connection_ap_handshake_attach_circuit(): Intro (26496) and rend (0) circs are not both ready. Stalling conn. (23 sec old)
Nov 24 12:08:56.000 [info] connection_ap_handshake_attach_circuit(): Intro (26496) and rend (0) circs are not both ready. Stalling conn. (24 sec old)
Nov 24 12:08:56.000 [info] connection_ap_handshake_attach_circuit(): Intro (26496) and rend (0) circs are not both ready. Stalling conn. (24 sec old)
Nov 24 12:08:57.000 [info] connection_ap_handshake_attach_circuit(): Intro (26496) and rend (0) circs are not both ready. Stalling conn. (25 sec old)
Nov 24 12:08:57.000 [info] connection_ap_handshake_attach_circuit(): Intro (26496) and rend (0) circs are not both ready. Stalling conn. (25 sec old)
Nov 24 12:08:58.000 [info] connection_ap_handshake_attach_circuit(): Intro (26496) and rend (0) circs are not both ready. Stalling conn. (26 sec old)
Nov 24 12:08:58.000 [info] connection_ap_handshake_attach_circuit(): Intro (26496) and rend (0) circs are not both ready. Stalling conn. (26 sec old)
Nov 24 12:08:59.000 [info] connection_ap_handshake_attach_circuit(): Intro (26496) and rend (0) circs are not both ready. Stalling conn. (27 sec old)

and these:

Nov 24 12:08:39.000 [info] rend_client_introduction_acked(): ...Found no rend circ. Dropping on the floor.
Nov 24 12:08:42.000 [info] rend_client_introduction_acked(): ...Found no rend circ. Dropping on the floor.
Nov 24 12:08:44.000 [info] rend_client_introduction_acked(): ...Found no rend circ. Dropping on the floor.
Nov 24 12:08:49.000 [info] rend_client_introduction_acked(): ...Found no rend circ. Dropping on the floor.
Nov 24 12:09:06.000 [info] rend_client_introduction_acked(): ...Found no rend circ. Dropping on the floor.
Nov 24 12:09:08.000 [info] rend_client_introduction_acked(): ...Found no rend circ. Dropping on the floor.
Nov 24 12:09:15.000 [info] rend_client_introduction_acked(): ...Found no rend circ. Dropping on the floor.
Nov 24 12:09:15.000 [info] rend_client_introduction_acked(): ...Found no rend circ. Dropping on the floor.

Here is an extract of the info log level file:

http://pastebin.com/0bMB0Xex

Changed 6 years ago by rransom

Attachment: download.php?i=0bMB0Xex added

log dump

comment:21 Changed 6 years ago by Sebastian

An updated branch is in feature2553-v4 in my repository. It has fixup commits for two problems I found. It doesn't have the problem of the broken merge as hellais' branch. We should probably base further work on that branch

comment:22 Changed 6 years ago by rransom

My feature2553-v3 branch works correctly (when compiled with CFLAGS='-DENABLE_TOR2WEB_MODE=1'). Sebastian's feature2553-v4 branch doesn't work.

I currently suspect that the stream-isolation code added to 0.2.3.x-alpha is causing Tor to start multiple rend circs at the same time (and possibly multiple intro circs, too); this might not break HS client functionality in non-tor2web-mode Tors because those have a higher variance in circuit build times.

comment:23 Changed 6 years ago by rransom

I've pushed Sebastian's feature2553-v4 branch and some new fixup commits to my feature2553-v4 branch. The main new change is that I corrected the name of the configure option (it should be --enable-tor2web-mode, not --enable-tor2webmode).

comment:24 Changed 6 years ago by nickm

Okay, will review again once there's something rransom and Sebastian are done fixing and that hellais has tested.

comment:25 in reply to:  23 Changed 6 years ago by hellais

Replying to rransom:

Currently it does not work. It never is able to reach the rendevous.

rransom: Do you know what this might depend on? How can we fix it?

I will attach a full log dump.

Changed 6 years ago by hellais

Attachment: tor-info.log added

tor2web mode log

Changed 6 years ago by rransom

patch for the Debian package

comment:26 Changed 6 years ago by rransom

Status: needs_reviewassigned

Huh.

650 STREAM 63 NEW 0 37lnq2veifl4kar7.onion:6697 SOURCE_ADDR=127.0.0.1:54991 PURPOSE=USER ISOLATION="FLAGS=SOCKSAUTH,CLIENTADDR,SESSIONGRP,NYM_EPOCH SESSION_GROUP=FIRST_AUTO NYM_EPOCH=1 CLIENT_ADDR=127.0.
    0.1 CLIENT_PROTO_TYPE=AP_LISTENER CLIENT_PROTO_SOCKSVER=5"
650 STREAM 65 NEW 0 77.245.18.28.$702B004EE4DCE9C477B2D7BAADE53390BD30B7DF.exit:443 SOURCE_ADDR=(Tor_internal):0 PURPOSE=DIR_FETCH ISOLATION="FLAGS=SESSIONGRP SESSION_GROUP=DIRCONN NYM_EPOCH=0 
    ORIGINAL_DEST_ADDRESS=77.245.18.28 CLIENT_ADDR=??? CLIENT_PROTO_TYPE=DIR_LISTENER"
650 CIRC 97 LAUNCHED BUILD_FLAGS=ONEHOP_TUNNEL,NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=1322269569,711184
650 CIRC 97 EXTENDED $702B004EE4DCE9C477B2D7BAADE53390BD30B7DF=digitalmortician1 BUILD_FLAGS=ONEHOP_TUNNEL,NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=1322269569,711184
650 CIRC 97 BUILT $702B004EE4DCE9C477B2D7BAADE53390BD30B7DF=digitalmortician1 BUILD_FLAGS=ONEHOP_TUNNEL,NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=1322269569,711184
650 STREAM 65 SENTCONNECT 97 77.245.18.28.$702B004EE4DCE9C477B2D7BAADE53390BD30B7DF.exit:443 ISOLATION="FLAGS=SESSIONGRP SESSION_GROUP=DIRCONN NYM_EPOCH=0 ORIGINAL_DEST_ADDRESS=77.245.18.28 CLIENT_ADDR=?
    ?? CLIENT_PROTO_TYPE=DIR_LISTENER"
650 STREAM 65 SUCCEEDED 97 77.245.18.28.$702B004EE4DCE9C477B2D7BAADE53390BD30B7DF.exit:443 ISOLATION="FLAGS=SESSIONGRP SESSION_GROUP=DIRCONN NYM_EPOCH=0 ORIGINAL_DEST_ADDRESS=77.245.18.28 CLIENT_ADDR=???
     CLIENT_PROTO_TYPE=DIR_LISTENER"
650 STREAM 65 CLOSED 97 77.245.18.28.$702B004EE4DCE9C477B2D7BAADE53390BD30B7DF.exit:443 REASON=END REMOTE_REASON=DONE ISOLATION="FLAGS=SESSIONGRP SESSION_GROUP=DIRCONN NYM_EPOCH=0 ORIGINAL_DEST_ADDRESS=
    77.245.18.28 CLIENT_ADDR=??? CLIENT_PROTO_TYPE=DIR_LISTENER"
650 CIRC 98 LAUNCHED BUILD_FLAGS=ONEHOP_TUNNEL,IS_INTERNAL,NEED_CAPACITY,NEED_UPTIME PURPOSE=HS_CLIENT_REND HS_STATE=HSCR_CONNECTING TIME_CREATED=1322269572,434417
650 CIRC 99 LAUNCHED BUILD_FLAGS=ONEHOP_TUNNEL,IS_INTERNAL,NEED_CAPACITY,NEED_UPTIME PURPOSE=HS_CLIENT_INTRO HS_STATE=HSCI_CONNECTING TIME_CREATED=1322269572,434999
650 CIRC 99 EXTENDED $318468966E328B1312D114A1C564CD42706F8363=kryptonit BUILD_FLAGS=ONEHOP_TUNNEL,IS_INTERNAL,NEED_CAPACITY,NEED_UPTIME PURPOSE=HS_CLIENT_INTRO HS_STATE=HSCI_CONNECTING REND_QUERY=
    37lnq2veifl4kar7 TIME_CREATED=1322269572,434999
650 CIRC 99 BUILT $318468966E328B1312D114A1C564CD42706F8363=kryptonit BUILD_FLAGS=ONEHOP_TUNNEL,IS_INTERNAL,NEED_CAPACITY,NEED_UPTIME PURPOSE=HS_CLIENT_INTRO HS_STATE=HSCI_CONNECTING REND_QUERY=
    37lnq2veifl4kar7 TIME_CREATED=1322269572,434999
650 CIRC 98 EXTENDED $64186650FFE4469EBBE52B644AE543864D32F43C=PsychoOnion3 BUILD_FLAGS=ONEHOP_TUNNEL,IS_INTERNAL,NEED_CAPACITY,NEED_UPTIME PURPOSE=HS_CLIENT_REND HS_STATE=HSCR_CONNECTING REND_QUERY=
    37lnq2veifl4kar7 TIME_CREATED=1322269572,434417
650 CIRC 98 BUILT $64186650FFE4469EBBE52B644AE543864D32F43C=PsychoOnion3 BUILD_FLAGS=ONEHOP_TUNNEL,IS_INTERNAL,NEED_CAPACITY,NEED_UPTIME PURPOSE=HS_CLIENT_REND HS_STATE=HSCR_CONNECTING REND_QUERY=
    37lnq2veifl4kar7 TIME_CREATED=1322269572,434417
650 CIRC2 98 PURPOSE_CHANGED $64186650FFE4469EBBE52B644AE543864D32F43C=PsychoOnion3 BUILD_FLAGS=ONEHOP_TUNNEL,IS_INTERNAL,NEED_CAPACITY,NEED_UPTIME PURPOSE=HS_CLIENT_REND HS_STATE=HSCR_ESTABLISHED_IDLE 
    REND_QUERY=37lnq2veifl4kar7 TIME_CREATED=1322269572,434417 OLD_PURPOSE=HS_CLIENT_REND OLD_HS_STATE=HSCR_CONNECTING
650 CIRC2 99 PURPOSE_CHANGED $318468966E328B1312D114A1C564CD42706F8363=kryptonit BUILD_FLAGS=ONEHOP_TUNNEL,IS_INTERNAL,NEED_CAPACITY,NEED_UPTIME PURPOSE=HS_CLIENT_INTRO HS_STATE=HSCI_INTRO_SENT 
    REND_QUERY=37lnq2veifl4kar7 TIME_CREATED=1322269572,434999 OLD_PURPOSE=HS_CLIENT_INTRO OLD_HS_STATE=HSCI_CONNECTING
650 CIRC 98 CLOSED $64186650FFE4469EBBE52B644AE543864D32F43C=PsychoOnion3 BUILD_FLAGS=ONEHOP_TUNNEL,IS_INTERNAL,NEED_CAPACITY,NEED_UPTIME PURPOSE=HS_CLIENT_REND HS_STATE=HSCR_ESTABLISHED_IDLE REND_QUERY=
    37lnq2veifl4kar7 TIME_CREATED=1322269572,434417 REASON=DESTROYED REMOTE_REASON=TORPROTOCOL
650 CIRC2 99 PURPOSE_CHANGED $318468966E328B1312D114A1C564CD42706F8363=kryptonit BUILD_FLAGS=ONEHOP_TUNNEL,IS_INTERNAL,NEED_CAPACITY,NEED_UPTIME PURPOSE=HS_CLIENT_INTRO HS_STATE=HSCI_DONE REND_QUERY=
    37lnq2veifl4kar7 TIME_CREATED=1322269572,434999 OLD_PURPOSE=HS_CLIENT_INTRO OLD_HS_STATE=HSCI_INTRO_SENT
650 CIRC 99 CLOSED $318468966E328B1312D114A1C564CD42706F8363=kryptonit BUILD_FLAGS=ONEHOP_TUNNEL,IS_INTERNAL,NEED_CAPACITY,NEED_UPTIME PURPOSE=HS_CLIENT_INTRO HS_STATE=HSCI_DONE REND_QUERY=
    37lnq2veifl4kar7 TIME_CREATED=1322269572,434999 REASON=FINISHED
650 CIRC 100 LAUNCHED BUILD_FLAGS=ONEHOP_TUNNEL,IS_INTERNAL,NEED_CAPACITY,NEED_UPTIME PURPOSE=HS_CLIENT_REND HS_STATE=HSCR_CONNECTING TIME_CREATED=1322269577,283810
650 CIRC 101 LAUNCHED BUILD_FLAGS=ONEHOP_TUNNEL,IS_INTERNAL,NEED_CAPACITY,NEED_UPTIME PURPOSE=HS_CLIENT_INTRO HS_STATE=HSCI_CONNECTING TIME_CREATED=1322269577,284410

The rend circ is dying with REASON=DESTROYED REMOTE_REASON=TORPROTOCOL. This is not what I had expected based on hellais's first log dump.

comment:27 Changed 6 years ago by rransom

$64186650FFE4469EBBE52B644AE543864D32F43C=PsychoOnion3 is running Tor 0.2.2.34; I also had a rend circ to $F97F3B153FED6604230CD497A3D1E9815B007636=noiseexit01a die in the same way, and that relay is running Tor 0.2.3.7-alpha.

comment:28 in reply to:  27 Changed 6 years ago by hellais

Replying to rransom:

$64186650FFE4469EBBE52B644AE543864D32F43C=PsychoOnion3 is running Tor 0.2.2.34; I also had a rend circ to $F97F3B153FED6604230CD497A3D1E9815B007636=noiseexit01a die in the same way, and that relay is running Tor 0.2.3.7-alpha.

Is there something I can do to help you debug this?

The problem is most definitely cased by some changes that occurred between 0.2.2.x and 0.2.3.x, since the patch for 0.2.2.x (feature2553-v2) worked fine.

comment:29 Changed 6 years ago by nickm

Should I be expecting a finished, tested, working branch here soon? If not, it's no disaster to push this back to 0.2.4.x.

comment:30 Changed 6 years ago by Sebastian

afaik, the current state is that we believe the branch works, but there's an as-of-yet unknown bug that we introduced somewhere in 0.2.3.x that makes hidden services more flaky for clients. So this branch blocks on finding the other bug

comment:31 Changed 6 years ago by nickm

Reviewing the code again, I am pretty happy with its current *appearance*. rransom, hellais: I will defer to you about whether I merge it today or in 0.2.4.x. Please let me know what you think.

comment:32 Changed 6 years ago by rransom

Merging this branch today will not hurt anyone who doesn't turn tor2web mode on. (Merging it at all, even after the bug that broke it is fixed, might hurt people who do turn it on. I know that I forgot that I was using tor2web mode at least once while I was testing it.)

I think I've just finished the main script for a tool that will test whether a Tor build has the bug that broke this branch; I should be able to start bisecting and find that bug tonight.

comment:33 in reply to:  32 ; Changed 6 years ago by nickm

Replying to rransom:

Merging this branch today will not hurt anyone who doesn't turn tor2web mode on.

Okay, I think I'll merge it then. Can we close this ticket and opening a new one for the the remaining issue?

(Merging it at all, even after the bug that broke it is fixed, might hurt people who do turn it on. I know that I forgot that I was using tor2web mode at least once while I was testing it.)

Can you think of any way to solve the "oops I forgot this was a tor2web build" issue? I *think* only developers should run into that one. One option, I guess, would be to change the binary name when we're building for tor2web. But that won't do anything in the case where you start it running, then forget about it.

comment:34 Changed 6 years ago by hellais

Replying to nickm:

Reviewing the code again, I am pretty happy with its current *appearance*. rransom, hellais: I will defer to you about whether I merge it today or in 0.2.4.x. Please let me know what you think.

Unfortunately it is currently broken. I am unable to connect to *any* hidden service. It should be a bug related to something introduced in 0.2.3.x that was not present in 0.2.2.x.

nickm: are you able to spot it, or can you imagine what it might be? I am willing to spend some time to debug it, but I would need some pointer as to where in the code to look and for what.

comment:35 in reply to:  32 Changed 6 years ago by hellais

Replying to rransom:

I think I've just finished the main script for a tool that will test whether a Tor build has the bug that broke this branch; I should be able to start bisecting and find that bug tonight.

What do you mean by "the build that has the bug that broke this branch"? Are you saying that at one point in the development of 0.2.3.x something broke?
Is there something that is related to building one hop circuits that is not working as it should?

comment:36 in reply to:  33 Changed 6 years ago by rransom

Resolution: implemented
Status: assignedclosed

Replying to nickm:

Replying to rransom:

Merging this branch today will not hurt anyone who doesn't turn tor2web mode on.

Okay, I think I'll merge it then. Can we close this ticket and opening a new one for the the remaining issue?

See #4641.

(Merging it at all, even after the bug that broke it is fixed, might hurt people who do turn it on. I know that I forgot that I was using tor2web mode at least once while I was testing it.)

Can you think of any way to solve the "oops I forgot this was a tor2web build" issue? I *think* only developers should run into that one. One option, I guess, would be to change the binary name when we're building for tor2web. But that won't do anything in the case where you start it running, then forget about it.

I can't think of any solution to that problem, other than ‘don't test tor2web mode again’.

comment:37 Changed 6 years ago by hellais

I just wanted to add that I have tested this and it works perfectly.
Thank you Robert :)

You may also be interested in a few ideas for improving Tor HS: https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/HiddenServices

I created two tickets for those two open probem to discuss them:
#4849
#4850

comment:38 Changed 5 years ago by nickm

Keywords: tor-hs added

comment:39 Changed 5 years ago by nickm

Component: Tor Hidden ServicesTor
Note: See TracTickets for help on using tickets.