Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#3309 closed defect (fixed)

SIGNAL NEWNYM should clear the last_hid_serv_requests table

Reported by: rransom Owned by: rransom
Priority: High Milestone: Tor: 0.2.2.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-hs
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Tor clients record (HS descriptor ID, HSDir relay, time) tuples in a table (last_hid_serv_requests), and refuse to query an HSDir relay for an HS descriptor ID if it has already done so within the last 15 minutes. I thought clearing this table on SIGNAL NEWNYM would be unnecessary in most cases, and would put more load than appropriate in HSDir relays. I was wrong about it being unnecessary -- I've run out of HSDirs to query at least three times while testing whether one of my hidden services was running.

Child Tickets

Change History (11)

comment:1 Changed 8 years ago by rransom

Status: newneeds_review

See bug3309 ( git://git.torproject.org/rransom/tor.git bug3309 ).

comment:2 Changed 8 years ago by Sebastian

It seems that you're trying to use signal newnym as a hack to work around an unrelated issue here. I'm not crazy about doing that, because it means we overload newnym with yet more functionality. Is there an actual linkability issue here without it?

comment:3 in reply to:  2 Changed 8 years ago by rransom

Replying to Sebastian:

It seems that you're trying to use signal newnym as a hack to work around an unrelated issue here. I'm not crazy about doing that, because it means we overload newnym with yet more functionality. Is there an actual linkability issue here without it?

There is a minor linkability issue without clearing this state, but if I thought it could be exploited, I would have cleared it in my #3000-fix branch.

But this state-purge is needed to keep SIGNAL NEWNYM from breaking Tor's functionality, so I don't see any reason to not do it on SIGNAL NEWNYM or to allow users to trigger it separately. (Pounding on the HS directories more often is a bit rude, but less so than using SIGNAL NEWNYM repeatedly, or restarting one's Tor client as a workaround for this issue.)

comment:4 Changed 8 years ago by Sebastian

The situation I want to avoid is that we hear advice like "oh, hs doesn't work for you? Just newnym for good measure" because we should only advice newnym usage when the user actually wants a new nym.

comment:5 in reply to:  4 Changed 8 years ago by rransom

Replying to Sebastian:

The situation I want to avoid is that we hear advice like "oh, hs doesn't work for you? Just newnym for good measure" because we should only advice newnym usage when the user actually wants a new nym.

We already use NEWNYM to stop using a circuit whose exit node is flaky, misconfigured, evil, or otherwise broken, and to clear ‘enough’ client state between tests in a Torperf run. Having NEWNYM break users' Tor clients will not make us stop recommending that users use it for reasons other than making future Tor streams unlinkable to previous streams.

See #3335 for a ‘never make users use NEWNYM to fix this if NEWNYM didn't break it’ ticket, but this change is still needed because (a) it is definitely simple enough to be merged directly to maint-0.2.2, (b) it is needed to keep NEWNYM from breaking things, and (c) it is needed for a hidden-service analogue of Torperf.

comment:6 in reply to:  4 Changed 8 years ago by nickm

Replying to Sebastian:

The situation I want to avoid is that we hear advice like "oh, hs doesn't work for you? Just newnym for good measure" because we should only advice newnym usage when the user actually wants a new nym.

I think rransom's argument here is that if we _don't clear last_hid_serv_requests on NEWNYM, then our other NEWNYM fix (where we clear the hidserv descriptor cache on newnym) can break hidden service requests, if we have fetched the descriptor from every viable hsdir too recently. So this is less about the linkability issue and more about the fact that our other linkability fix broke robustness.

Have I got that right? And does it make sense?

comment:7 Changed 8 years ago by nickm

On review,it looks like the patch will correctly do what it says on the label. So if we agree that it's the right thing to do, we should merge it.

comment:8 Changed 8 years ago by Sebastian

Ahh, that makes more sense. Thanks for explaining.

comment:9 Changed 8 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

With sebastian's objection withdrawn, merging.

comment:10 Changed 7 years ago by nickm

Keywords: tor-hs added

comment:11 Changed 7 years ago by nickm

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