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 cypherpunks2):

 Replying to [comment:31 asn]:
 > 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?

 Yes, the problem is that [comment:13 clients do not mark an intro point as
 having failed] when the only evidence that it has failed is that the
 corresponding rendezvous point is not working.  And we know that, from the
 perspective of a client, the failure of a rendezvous point is symptomatic
 of [comment:27 the case in which an onion service does not hear from the
 corresponding intro point in the first place].  For a client to mark an
 intro point as having failed in this circumstance, it would need to
 maintain some kind of pointer between a rendezvous point and its
 corresponding intro point, for example as described in [comment:20
 Proposal B], such that the client will correctly mark the intro point as
 having failed and re-fetch the onion service descriptor as required.

 > 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.

 It is a useful attack if the adversary wants to degrade the performance of
 onion services network-wide by making them inaccessible from clients that
 would otherwise need to re-fetch the descriptor for onion services.  If a
 client extends to a buggy or malicious intro point of the type described
 here, then it will not re-fetch the descriptor, or at least not until its
 time-based expiration, since from its perspective the intro point is
 working.  Considering that the need to re-fetch the descriptor prior to
 its time-based expiration is a necessary and expected part of normal
 operation for a client, the ability for an intro point to behave this way
 constitutes:

 * a significant denial-of-service attack for onion services that expect
 multiple visits from the same client, and

 * unnecessary network load and possible degredation of anonymity to
 clients who establish many circuits in rapid succession as they continue
 to attempt to reach the onion service without re-fetching its descriptor
 first.

 So this is not benign.

 > 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.

 It is not true that the only possible fix is to have the client wait for
 the end-to-end ACK from the service.  The client could reach out to the
 rendezvous point optimistically, and then if it does not hear an ACK from
 the service via the intro point within a particular period of time, it
 could re-fetch the descriptor for the service.  That is the essence of
 [comment:20 Proposal A] and ultimately my recommendation for a long-term
 solution.

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