Opened 9 years ago

Closed 8 years ago

Last modified 7 years ago

#3335 closed enhancement (implemented)

Remove an HS's entries in last_hid_serv_requests when a connection attempt ends

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

Description

Right now, a Tor client records its HS descriptor fetch attempts in the last_hid_serv_requests table, and it refuses to try again to fetch a descriptor from an HSDir relay if it has tried to fetch the same descriptor from the same relay within the last 15 minutes. That table serves a useful purpose: it keeps track of which HSDir relays the client has already asked for a descriptor within a connection attempt, so that the client will eventually try each of the relays responsible for the descriptor it is trying to fetch, and then stop trying to fetch the descriptor if none of the HSDirs have a working descriptor for the service.

Unfortunately, this behaviour means that if Tor fails to retrieve a working descriptor for an HS, it will not try again for up to 15 minutes, even though the HS may have published a new, working descriptor already.

The most common reason that my Tor client has run out of HSDirs to query for a descriptor is that I've sent SIGNAL NEWNYM multiple times, thereby discarding the HS descriptor and forcing Tor to refetch it, but it's possible to run out of HSDirs to try for other reasons (e.g. the HS wasn't running yet the first time). The NEWNYM case is #3309; this ticket is about not making users use NEWNYM to fix an HS problem that NEWNYM didn't cause.

Child Tickets

Change History (10)

comment:1 Changed 8 years ago by rransom

The easiest way to notice that a hidden service connection attempt has ended is to notice that:

  • a stream trying to connect to an HS has timed out without being attached to a circuit,
  • a stream trying to connect to an HS has been attached successfully, or
  • all streams trying to connect to an HS are being closed because Tor has tried an HS descriptor from each directory and still failed to open a rendezvous circuit.

There may be other cases that we should consider to 'end' an HS connection attempt. This fix should be safe enough to backport to 0.2.2.x after it has been tested on 0.2.3.x a bit.

comment:2 Changed 8 years ago by rransom

Milestone: Tor: 0.2.3.x-finalTor: 0.2.2.x-final
Status: newneeds_review

See bug3335 ( https://git.torproject.org/rransom/tor.git bug3335 ) for a fix. (This branch includes the fix for #3825, for no terribly good reason.)

comment:3 Changed 8 years ago by nickm

The XXX023 comment notation usually means a potential problem that we need to fix before 0.2.3 comes out. What's the problem with those asserts?

The documentation for the get_last_hid_serv_requests() strmap and its friends really need to get updated for the new strmap key format.

Is there any way for the new code to result in repeatedly hammering the network by trying and failing to connect to the same nonworking hs? That was one of the points of the 15 minute timeout, IIRC. What replaces that functionality now?

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

Replying to nickm:

The XXX023 comment notation usually means a potential problem that we need to fix before 0.2.3 comes out. What's the problem with those asserts?

I think we should add those asserts (i.e. uncomment them) on 0.2.3.x, but not on 0.2.2.x (if/when we merge this branch there).

The documentation for the get_last_hid_serv_requests() strmap and its friends really need to get updated for the new strmap key format.

Oops. I didn't realize the key format had been documented. Fix pushed.

Is there any way for the new code to result in repeatedly hammering the network by trying and failing to connect to the same nonworking hs? That was one of the points of the 15 minute timeout, IIRC. What replaces that functionality now?

If the user repeatedly opens new streams to a hidden service address such that (a) there is no HS with that address, (b) the HS with that address has not published its HS descriptors yet, or (c) the HS with that address has gone offline since the last time it published its HS descriptors, Tor will now contact each HS directory responsible for a descriptor ID at most once per connection attempt. I don't think this is significantly worse than the old situation.

This is actually better than the current behaviour if one of the directories responsible for a hidden service gets overloaded with CREATE cells and starts dropping them, because a client might try other HS directories on their next connection attempt rather than only having the overloaded directory left for the next 15 minutes and pounding it with a flood of CREATEs for as long as the user tries to connect to the service. Sounds like we^WI should open a new ticket for ‘give up on reaching a destination for N minutes after M failed circuits for a single stream’ in general.

See hs-fixes-2011-09-29-01 ( https://git.torproject.org/rransom/tor.git hs-fixes-2011-09-29-01 ) for a fixed #3825 and #3335 branch; see bug3335-v2 ( https://git.torproject.org/rransom/tor.git bug3335-v2 ) for a fixed and rebased version (with ‘Fix log message typo’ renamed to ‘Fix comment typo’; oops), also containing #3825 for a relatively good reason: one of the #3335-fix commits changes the rend_client_note_connection_attempt_ended function added for #3825.

comment:5 Changed 8 years ago by nickm

Okay, merged to master. Please double-check the merge commit and the followup "make it compile again" commits.

comment:6 Changed 8 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

I am guessing that you didn't find anything wrong with my merge commit here, or that you didn't see the message above. In either case, closing this for now; please reqopen if there's an issue.

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

Milestone: Tor: 0.2.2.x-finalTor: 0.2.3.x-final

Replying to nickm:

I am guessing that you didn't find anything wrong with my merge commit here, or that you didn't see the message above. In either case, closing this for now; please reqopen if there's an issue.

I replied on #3825, because the merge conflict came from that set of changes.

I'm also changing the milestone to 0.2.3.x-final, because I no longer expect you to consider merging this to 0.2.2.x (0.2.3.x should be stable soon enough).

comment:8 Changed 8 years ago by nickm_mobile

Ok. I don't see anything there atm that I should act on; please indicate there if there is anything. Else I'll continue focusing on other stuff.

comment:9 Changed 7 years ago by nickm

Keywords: tor-hs added

comment:10 Changed 7 years ago by nickm

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