Re: [tor-bugs] #25882 [Core Tor/Tor]: clients not detecting stale onion service introduction points

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#25882: clients not detecting stale onion service introduction points
-------------------------------------------------+-------------------------
 Reporter:  cypherpunks                          |          Owner:  dgoulet
     Type:  defect                               |         Status:
                                                 |  assigned
 Priority:  High                                 |      Milestone:  Tor:
                                                 |  unspecified
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-hs, 034-deferred-20180602        |  Actual Points:
  035-removed reachability                       |
Parent ID:  #22455                               |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by asn):

 Replying to [comment:27 cypherpunks2]:
 > So, two thoughts: what is the mechanism by which the set of introduction
 points known to a client is kept synchronised with the set of "live"
 introduction points maintained by an onion service?  Note that a
 descriptor held by a client may become outdated, a descriptor held by the
 database may become outdated, and circuits maintained by the onion service
 may stop working...
 >

 Hm. A descriptor held by a client can become outdated indeed. A client is
 supposed to re-fetch a descriptor if all intro points fail (see
 `send_introduce1()`). From what I remember in this bug, we sometimes don't
 mark an intro point as failing, so we don't refetch the desc?

 > Also, what is to stop a malicious (or buggy) introduction point from
 sending an ACK to a client but never reaching out to the onion service?

 Nothing. This is indeed a protocol issue. A potential protocol fix here
 would be to require an end-to-end ACK all the way to the client from the
 service.

 Doing that will rule out the above malicious case (which does not seem
 very useful from an adversary PoV), and also help us debug bugs like this.
 However, it will not help with issues like the outgoing rendezvous circuit
 timing out or failing on the service-side (probably what's happening
 here), and it will also slightly delay ''all'' rendezvous circuit setups
 because the ACK has to be end-to-end.

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