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

Re: [tor-bugs] #997 [Tor Client]: Hidden services fail to load if you have a stale descriptor

#997: Hidden services fail to load if you have a stale descriptor
-------------------------+--------------------------------------------------
  Reporter:  arma        |       Owner:  karsten           
      Type:  defect      |      Status:  assigned          
  Priority:  major       |   Milestone:  Tor: 0.2.2.x-final
 Component:  Tor Client  |     Version:  0.2.1.15-rc       
Resolution:  None        |    Keywords:                    
    Parent:              |  
-------------------------+--------------------------------------------------
Changes (by arma):

  * owner:  => karsten
  * status:  new => assigned
  * priority:  minor => major


Old description:

> Using git head.
>
> In connection_ap_handshake_rewrite_and_attach(), we check
> rend_cache_lookup_entry(). If >0 (meaning we have a rend descriptor),
> we then evaluate:
>
> /** How long after we receive a hidden service descriptor do we consider
>  * it valid? */
> #define NUM_SECONDS_BEFORE_HS_REFETCH (60*15)
>       if (now - entry->received < NUM_SECONDS_BEFORE_HS_REFETCH) {
>
> and if it's stale (we got it more than 15 minutes ago), we call
>
>         log_info(LD_REND, "Stale descriptor %s. Re-fetching.",
>                  safe_str(conn->rend_data->onion_address));
>         rend_client_refetch_v2_renddesc(conn->rend_data);
>
> However, in rend_client_refetch_v2_renddesc() we don't care whether
> it's stale. Towards the top of the function we call:
>
>   if (rend_cache_lookup_entry(rend_query->onion_address, -1, &e) > 0) {
>     log_info(LD_REND, "We would fetch a v2 rendezvous descriptor, but we
> "
>                       "already have that descriptor here. Not
> fetching.");
>     return;
>   }
>
> So now that we don't try to fetch v0 rend descriptors, that means that
> Tor simply times out on all socks requests to hidden services for which
> we have a stale descriptor.
>
> Presumably this is a bug on 0.2.1.x and 0.2.0.x too.
>
> My original rend desc design was "if you have a fresh one, use it. If
> you have one but it's stale, fetch a new one; then whether you get a new
> one or no, use the one you have." We seem to have clobbered that design
> in 0.2.0.20-rc (r13540) when we added support for v0 and v2 rend descs.
> In any case, refetching after 15 minutes was cheap back in the days of
> Tor 0.0.9, but is expensive now.
>
> So the two extremes we have are:
> 1) connection_ap_handshake_rewrite_and_attach() which says "it's stale
> after 15 minutes; try to fetch a new one if it's stale" and
> 2) /** Time period for which a v2 descriptor will be valid. */
> #define REND_TIME_PERIOD_V2_DESC_VALIDITY (24*60*60)
>
> Do we want something in between?
>
> (Thanks to neoeinstein for tracking down the bug.)
>

> [Automatically added by flyspray2trac: Operating System: All]

New description:

 Using git head.

 In connection_ap_handshake_rewrite_and_attach(), we check
 rend_cache_lookup_entry(). If >0 (meaning we have a rend descriptor),
 we then evaluate:

 /** How long after we receive a hidden service descriptor do we consider
  * it valid? */
 #define NUM_SECONDS_BEFORE_HS_REFETCH (60*15)
       if (now - entry->received < NUM_SECONDS_BEFORE_HS_REFETCH) {

 and if it's stale (we got it more than 15 minutes ago), we call

         log_info(LD_REND, "Stale descriptor %s. Re-fetching.",
                  safe_str(conn->rend_data->onion_address));
         rend_client_refetch_v2_renddesc(conn->rend_data);

 However, in rend_client_refetch_v2_renddesc() we don't care whether
 it's stale. Towards the top of the function we call:

   if (rend_cache_lookup_entry(rend_query->onion_address, -1, &e) > 0) {
     log_info(LD_REND, "We would fetch a v2 rendezvous descriptor, but we "
                       "already have that descriptor here. Not fetching.");
     return;
   }

 So now that we don't try to fetch v0 rend descriptors, that means that
 Tor simply times out on all socks requests to hidden services for which
 we have a stale descriptor.

 Presumably this is a bug on 0.2.1.x and 0.2.0.x too.

 My original rend desc design was "if you have a fresh one, use it. If
 you have one but it's stale, fetch a new one; then whether you get a new
 one or no, use the one you have." We seem to have clobbered that design
 in 0.2.0.20-rc (r13540) when we added support for v0 and v2 rend descs.
 In any case, refetching after 15 minutes was cheap back in the days of
 Tor 0.0.9, but is expensive now.

 So the two extremes we have are:
 1) connection_ap_handshake_rewrite_and_attach() which says "it's stale
 after 15 minutes; try to fetch a new one if it's stale" and
 2) /** Time period for which a v2 descriptor will be valid. */
 #define REND_TIME_PERIOD_V2_DESC_VALIDITY (24*60*60)

 Do we want something in between?

 (Thanks to neoeinstein for tracking down the bug.)


 [Automatically added by flyspray2trac: Operating System: All]

--

Comment:

 Triage: it looks like we committed some code for this, into various
 branches, without writing on the bug report what we did.

 We should look into this, and figure out the current bug status.

 Marking as blocking 0.2.2.x so we be sure to get a better handle on it.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/997#comment:11>
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