[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #3825 [Tor Hidden Services]: Hidden service unavailable even though I know its up

#3825: Hidden service unavailable even though I know its up
---------------------------------+------------------------------------------
 Reporter:  atoruser             |          Owner:  rransom           
     Type:  defect               |         Status:  needs_review      
 Priority:  major                |      Milestone:  Tor: 0.2.2.x-final
Component:  Tor Hidden Services  |        Version:  Tor: unspecified  
 Keywords:                       |         Parent:                    
   Points:                       |   Actualpoints:                    
---------------------------------+------------------------------------------
Changes (by rransom):

  * milestone:  => Tor: 0.2.2.x-final


Comment:

 Replying to [comment:7 nickm]:
 > Hm.  So walk me through the new timeout logic?  If an intro point always
 times out, we could try it every single time that we get a request to
 connect to a hidden service, and never conclude that it's broken.  Is that
 right?

 Yes.  I assume that timeouts are almost always transient failures, usually
 on the client side, and that the client's circuit-build timeout is short
 enough that if every intro point really is broken, the client will try all
 of them and either successfully connect to the service or fail and fetch a
 new descriptor for it.

 If you don't approve of that timeout behaviour, there are at least two
 other options (not mutually exclusive) for handling introduction circuit
 timeouts:
  * Count the number of times we have timed out while trying to reach an
 intro point, and remove the intro point after three timeouts while trying
 to reach it.  This change would fit right in on this branch, but I don't
 expect it to help clients.
  * Allow an introduction circuit to continue trying to reach and use an
 intro point even if the circuit times out.  This change would belong on
 the #1297 branch, because it involves mucking with circuit purposes, and
 so will the other remaining changes for #1297.

 > The rest of this looks right to me.

 It wasn't.  `rend_client_refetch_v2_renddesc` assumed that any HS
 descriptor a client had in its cache was still usable, and this branch
 invalidated that assumption.  (I've checked the other callers of
 `rend_cache_lookup_entry` now, and they didn't make that assumption.)

 See [https://gitweb.torproject.org/rransom/tor.git/shortlog/refs/heads/hs-
 fixes-2011-09-29-01 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
 [https://gitweb.torproject.org/rransom/tor.git/shortlog/refs/heads/bug3825a-v5
 bug3825a-v5] ( `https://git.torproject.org/rransom/tor.git bug3825a-v5` )
 for a #3825-only branch with âRefetch an HS's desc if we don't have a
 usable oneâ rebased to the beginning of the branch.

 I still think we will need to apply this branch to 0.2.2.x after it has
 been tested for a while on 0.2.3.x -- currently, when one of atoruser's
 hidden services attracts too many circuits to one of its intro points, its
 would-be clients DoS that intro-point relay with a flood of EXTEND cells
 until their users either give up on connecting to the HS or flush their
 Tor clients' HS descriptor cache.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3825#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs