Re: [tor-bugs] #25347 [Core Tor/Tor]: Tor keeps on trying the same overloaded guard over and over

[Tor Bug Tracker & Wiki]

#25347: Tor keeps on trying the same overloaded guard over and over
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-client, tbb-  |  Actual Points:
  usability, tbb-needs, 033-triage-20180320, |
  033-included-20180320, 031-unreached-  |
  backport, 035-removed-20180711, 032|
  -unreached-backport, 040-roadmap-proposed, |
  tor-hs, reachability   |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by asn):

 * keywords:
 tor-guard, tor-client, tbb-usability, tbb-needs, 033-triage-20180320,
 033-included-20180320, 031-unreached-backport, 035-removed-20180711,
 032-unreached-backport, 040-roadmap-proposed
 =>
 tor-guard, tor-client, tbb-usability, tbb-needs, 033-triage-20180320,
 033-included-20180320, 031-unreached-backport, 035-removed-20180711,
 032-unreached-backport, 040-roadmap-proposed, tor-hs, reachability
 * milestone:  Tor: 0.4.0.x-final => Tor: unspecified


Comment:

 Tagging as relevant to HS, and removing from 040 milestone.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25347 [Core Tor/Tor]: Tor keeps on trying the same overloaded guard over and over

[Tor Bug Tracker & Wiki]

#25347: Tor keeps on trying the same overloaded guard over and over
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  033-must, tor-guard, tor-client, |  Actual Points:
  tbb-usability, tbb-needs,  |
  033-triage-20180320, 033-included-20180320,|
  035-roadmap-proposed, 031-unreached-backport,  |
  035-removed-20180711, 032-unreached-backport,  |
  040-roadmap-proposed   |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:
 033-must, tor-guard, tor-client, tbb-usability, tbb-needs,
 033-triage-20180320, 033-included-20180320, 035-roadmap-proposed, 031
 -unreached-backport, 035-removed-20180711, 032-unreached-backport
 =>
 033-must, tor-guard, tor-client, tbb-usability, tbb-needs,
 033-triage-20180320, 033-included-20180320, 035-roadmap-proposed, 031
 -unreached-backport, 035-removed-20180711, 032-unreached-backport, 040
 -roadmap-proposed
 * milestone:  Tor: 0.4.0.x-final => Tor: unspecified


Comment:

 Hi, we don't add tickets to the 0.4.0 milestone unless we agree that we
 have time to do them.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25347 [Core Tor/Tor]: Tor keeps on trying the same overloaded guard over and over

[Tor Bug Tracker & Wiki]

#25347: Tor keeps on trying the same overloaded guard over and over
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  033-must, tor-guard, tor-client, |  Actual Points:
  tbb-usability, tbb-needs,  |
  033-triage-20180320, 033-included-20180320,|
  035-roadmap-proposed, 031-unreached-backport,  |
  035-removed-20180711, 032-unreached-backport   |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

 * milestone:  Tor: unspecified => Tor: 0.4.0.x-final


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25347 [Core Tor/Tor]: Tor keeps on trying the same overloaded guard over and over

[Tor Bug Tracker & Wiki]

#25347: Tor keeps on trying the same overloaded guard over and over
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability, tbb-needs, 033-triage-20180320, |
  033-included-20180320, 035-roadmap-proposed|
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by dmr):

 * cc: dmr (added)
 * keywords:
 031-backport, 032-backport, 033-must, tor-guard, tor-client, tbb-
 usability-website, tbb-needs, 033-triage-20180320,
 033-included-20180320, 035-roadmap-proposed
 =>
 031-backport, 032-backport, 033-must, tor-guard, tor-client, tbb-
 usability, tbb-needs, 033-triage-20180320, 033-included-20180320, 035
 -roadmap-proposed


Comment:

 Seems like `tbb-usability` is more appropriate than `tbb-usability-
 website` here.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25347 [Core Tor/Tor]: Tor keeps on trying the same overloaded guard over and over

[Tor Bug Tracker & Wiki]

#25347: Tor keeps on trying the same overloaded guard over and over
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320,|
  035-roadmap-proposed   |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by asn):

 * milestone:  Tor: 0.3.4.x-final => Tor: 0.3.5.x-final


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25347 [Core Tor/Tor]: Tor keeps on trying the same overloaded guard over and over

[Tor Bug Tracker & Wiki]

#25347: Tor keeps on trying the same overloaded guard over and over
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320,|
  035-roadmap-proposed   |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by asn):

 * keywords:
 031-backport, 032-backport, 033-must, tor-guard, tor-client, tbb-
 usability-website, tbb-needs, 033-triage-20180320,
 033-included-20180320
 =>
 031-backport, 032-backport, 033-must, tor-guard, tor-client, tbb-
 usability-website, tbb-needs, 033-triage-20180320,
 033-included-20180320, 035-roadmap-proposed


Comment:

 Triaging this out of 034 to 035 since it's not on the roadmap and it's
 complicated. However we should figure out what to do here sooner than
 later.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25347 [Core Tor/Tor]: Tor keeps on trying the same overloaded guard over and over

[Tor Bug Tracker & Wiki]

#25347: Tor keeps on trying the same overloaded guard over and over
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by asn):

 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.4.x-final


Comment:

 Triaging this out of 033 since there is not much we can do in such a short
 timeframe. Please move it back in if we think otherwise.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25347 [Core Tor/Tor]: Tor keeps on trying the same overloaded guard over and over

[Tor Bug Tracker & Wiki]

#25347: Tor keeps on trying the same overloaded guard over and over
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Replying to [comment:34 arma]:
 > (2b) Do we have any reason to believe that the calculation in
 have_room_for_onionskin() is at all accurate?

 I filed #25716 for this question.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25347 [Core Tor/Tor]: Tor keeps on trying the same overloaded guard over and over

[Tor Bug Tracker & Wiki]

#25347: Tor keeps on trying the same overloaded guard over and over
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 More thoughts while pondering this discussion:

 (1) It is really surprising to me that s7r could have been experiencing
 this bug (as currently described) for 7 hours. I think it was probably
 some other bug if it was really that long. For example, one of the ones
 where we mark things down and stop trying them, or one of the ones like
 #21969. asn says he only looked at a tiny fraction of the logs of the 7
 hours, so let's be careful jumping to conclusions about what bug (or
 combination of bugs) he actually experienced.

 (2) If a relay sends you a destroy cell with reason resourcelimit, it
 means that the relay has so many create cells on its queue that it thinks
 it won't get to this one in the next 1.75 seconds (MaxOnionQueueDelay
 default). So that's some real overload right there -- especially since
 even if you send another one and you don't get a destroy back, it means
 you squeaked into the queue, but you still have all those other creates
 ahead of you.

 (2b) Do we have any reason to believe that the calculation in
 have_room_for_onionskin() is at all accurate? That is, are we sometimes
 sending this response when there are only 0.25 seconds worth of create
 cells in our queue? Or are we sometimes not sending them even though there
 are 5 seconds of cells queued?

 (3) It would be nice to find a way for the dir auths to scale back the
 consensus weights of relays that are overloaded like this. That is, it
 would sure be swell if we could make this something that the dir auths
 solve for all the users, not something that each user has to encounter and
 then adapt to. But while I see why we want that, we should be realistic
 and realize that we won't get it: the dir auths act on a time schedule of
 hours, so they will catch perenially overloaded relays (say, relays that
 genuinely have a wildly wrong weighting or are just simply broken), but
 they won't be able to catch transient hotspots (including hotspots induced
 by bad people).

 (4): I think we really need to figure out how how often this happens in
 practice. That means scanning relays over time. Now, it happens that
 pastly's sbws might be able to collect this data for us. Also, the
 torperfs and onionperfs of the world could have this data already too, if
 they collect it. Do they? Noticing it in sbws has the slight added
 advantage that if we can figure out how to use it in computing weights,
 it's all ready to be used.

 (5) I would be a fan of a feature where we track the destroy-resource-
 limit responses we receive over time, and if there have been (say) 30
 different seconds recently where we got at least one destroy-resource-
 limit, and none of our attempts worked, we call the guard down. We
 shouldn't call it down in response to just one hotspot though (e.g. "I
 sent twenty create cells and I got twenty destroy-resource-limit
 responses"), since they're correlated with each other, that is, if you got
 one then it's not surprising that you'll get a second right after. And we
 might want to retry a guard that we mark down this way sooner than the 30
 -minute-later default from prop271.

 (6) I agree with asn that making it too easy to force a client to rotate
 guards is scary. The pool of 60-or-so guards from prop271 is a huge pool,
 and the only way to use that design securely imo is to have it be the case
 that some of those 60 guards are very hard to push clients away from.

 (7) I agree with Mike that the confirmation attack ("send a bunch of
 create cells to each guard one at a time and see when your target onion
 service stops responding") is worrisome. But would a bandwidth congestion
 attack work there too? I guess it would be more expensive to pull off with
 the same level of reliability.

 (7b) In a two guard design, I wonder if we should be even more reluctant
 to abandon a guard due to a 

Re: [tor-bugs] #25347 [Core Tor/Tor]: Tor keeps on trying the same overloaded guard over and over

[Tor Bug Tracker & Wiki]

#25347: Tor keeps on trying the same overloaded guard over and over
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by mikeperry):

 If this behavior is infrequent, then it is probably a good idea not to
 rotate guards unless we get a *lot* of destroys.

 I don't like the fact that by not doing anything about this, we're
 allowing a confirmation/search attack where an adversary can DoS guards
 until a hidden service becomes (mostly) unreachable, and I would argue
 that such an attack is worse than moving to a different guard, but that
 attack could also be mitigated by just having two guards instead of one
 (since it is harder to keep pairs of guards offline simultaneously during
 a search for such a confirmation).

 So I accept the NACK of the patch (and the second commit in #25705), but I
 think we should not forget what this decision means wrt DoS and
 confirmation.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25347 [Core Tor/Tor]: Tor keeps on trying the same overloaded guard over and over

[Tor Bug Tracker & Wiki]

#25347: Tor keeps on trying the same overloaded guard over and over
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by s7r):

 It is not happening that often in order to make user experience that bad
 in order to force us to take a decision that might degrade security /
 anonymity. If that would be the case we would have hundreds of reports by
 now. I an not sure how often and bad it affect popular onion services that
 run in anonymous mode, but it looks like it can wait slightly more.

 The behavior to switch guard on first `DESTROY` cell received as a client
 sounds terrible to me, I say we should NACK it. A proper behavior would be
 for clients to only relax a little bit after receiving say 10 `DESTROY`
 cells triggered by `RESOURCELIMIT` in a row, not switch the overloaded
 guard entirely just yet, then increase the time wait period between
 circuit retries so that we preserve as much as possible Tor's guard
 rotation period interval.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25347 [Core Tor/Tor]: Tor keeps on trying the same overloaded guard over and over

[Tor Bug Tracker & Wiki]

#25347: Tor keeps on trying the same overloaded guard over and over
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Replying to [comment:28 asn]:
 > Replying to [comment:25 mikeperry]:
 > > 2. Roger's point G is scary. I like the solution in E, though, and I
 think it actually fixes G. I would implement E by setting an is_predicted
 flag in circuit_predict_and_launch_new(), and then check that flag in
 select_entry_guard_for_circuit() to completely ignore the is_reachable
 status there if it is set. Then if any of those predicted circuits
 succeed, entry_guards_node_success() will get called, which will clear the
 is_uneachable flag and allow us to resume using the guard. For guards that
 fail only a non-zero but small portion of their circuits, this should
 allow us to keep using them rather than rotating away. I am a fan of this
 plan, and could write a patch for it if we like it.
 > >
 >
 > Hmm, I can see how the solution of E can help with G, by making Alice
 try her primary guards more aggressively in cases of predicted circuits,
 but if Alice is a busy hidden service (like Roger describes in E) most of
 her circs are not gonna be predicted.
 >
 > Furthermore, I wonder if it can completely address the problem in
 actually ''mischievous'' scenarios, where the adversary overloads all 3
 primary guards of Alice (targeting them using guard discovery attacks) to
 make her switch to other guards in her sampled set.

 FWIW, I discussed the above ''mischievous'' case with Nickm and discussed
 whether we should handle this "attacker can make you switch guards"
 congestion-attack case specially. Nick pointed out that this is the reason
 that the max sample size mechanism of prop271 was introduced (so that it's
 impossible for an adversary to make you try all the guards). If we are
 unhappy with how the sampled set of prop271 works we should refactor that
 instead of engineering special solutions for this ticket.

 tl;dr: I think we should be OK with switching guards in the case of
 `RESOURCELIMIT`, and rely on prop271 to defend against malicious attacks
 of this type. If we don't like the prop271 behavior, we should improve
 prop271.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25347 [Core Tor/Tor]: Tor keeps on trying the same overloaded guard over and over (was: Tor stops building circuits, and doesn't start when it has enough directory information)

[Tor Bug Tracker & Wiki]

#25347: Tor keeps on trying the same overloaded guard over and over
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs