Re: [tor-bugs] #29174 [Core Tor/Tor]: Guard Node can eclipse the hidden service

[Tor Bug Tracker & Wiki]

#29174: Guard Node can eclipse the hidden service
-+-
 Reporter:  TBD.Chen |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Critical | Resolution:
 Keywords:  guard, hidden, service, security,|  Actual Points:
  041-longterm   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by TBD.Chen):

 Although this is a tradeoff, we can just add the circular detection to
 prevent that.
 The hidden service can just send a requestion to itself and check whether
 it can receive the requestion.

 Replying to [comment:11 asn]:
 > I've been thinking of closing this ticket, mainly because this is a
 ticket we are aware of, and a tradeoff we took on purpose. I'm leaving it
 open just because it could be relevant to #25754.

--
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] #29174 [Core Tor/Tor]: Guard Node can eclipse the hidden service

[Tor Bug Tracker & Wiki]

#29174: Guard Node can eclipse the hidden service
-+-
 Reporter:  TBD.Chen |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Critical | Resolution:
 Keywords:  guard, hidden, service, security,|  Actual Points:
  041-longterm   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by asn):

 * priority:  Very High => Medium


Comment:

 I've been thinking of closing this ticket, mainly because this is a ticket
 we are aware of, and a tradeoff we took on purpose. I'm leaving it open
 just because it could be relevant to #25754.

--
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] #29174 [Core Tor/Tor]: Guard Node can eclipse the hidden service

[Tor Bug Tracker & Wiki]

#29174: Guard Node can eclipse the hidden service
---+
 Reporter:  TBD.Chen   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor: 0.3.0.1-alpha
 Severity:  Critical   | Resolution:
 Keywords:  guard, hidden service  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by TBD.Chen):

 Hi, I have deeply investigate the Proposal 291(291-two-guard-nodes),
 292(292-mesh-vanguards), however, this problem is not mentioned by them.

 So, can I get a TROVE-id or CVE-id for this bug track? Which can eclipse
 hidden services stealthily :)



 Replying to [comment:3 mikeperry]:
 > Interesting. This is another argument for Proposal 291 in my mind. A
 single guard has too much power to induce DoS and other downtime signals
 like this. The vanguards addon should similarly mitigate this attack, as
 it uses 2 guards by default. The malicious guard would just cause
 introduce1 timeouts on clients, but not be able to mount a full "eclipse"
 DoS attack.
 >
 > As for path bias -- it was designed to detect circuit failures caused by
 the guard. This case is different because the circuit can become live and
 successfully used for one or more initial introduce1 cells, and thus path
 bias system will deem it successfully used. After that point, there is no
 way for a client to determine if the circuit has just gone quiet because
 no one is using the HS vs the guard simply not sending any more introduce1
 cells on the circuit.

--
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] #29174 [Core Tor/Tor]: Guard Node can eclipse the hidden service

[Tor Bug Tracker & Wiki]

#29174: Guard Node can eclipse the hidden service
---+
 Reporter:  TBD.Chen   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor: 0.3.0.1-alpha
 Severity:  Critical   | Resolution:
 Keywords:  guard, hidden service  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by TBD.Chen):

 I think using 2 guards is quiet better than the spot-check in this certain
 schema.

 Because the spot-check should balance traffic cost and the response time
 after the guard starting to drop cells. And if the spot-check failed, we
 cannot locate the bad points instantly. The bad point may be Intro-Points,
 other middle nodes, or even HSDirs.

 But if we use the 2 guards when we creating HS-IP circuit, we can avoid
 this with several additionally cost. If the attacker blocks half of the
 HS-IntroPoint circuits, the client may fail to send her INTRODUCE1 cell
 with half probability at the first, and then she will retry automatically
 until success.
 The client feels no abnormality.

 -
 At last, can I get a TROVE-id or CVE-id for this bug track? Which can
 eclipse hidden services stealthily (:
 -
 -
 Replying to [comment:5 arma]:
 > Replying to [comment:4 mikeperry]:
 > > it would not be to hard to augment it to send periodic end-to-end
 probes for introduce1 circuits
 >
 > In the original tor-design paper, we spoke of onion services doing spot-
 checks of their introduction points, to make sure that they are actually
 introducing. That approach would test a larger fraction of the system than
 just doing a liveness check within the circuit. Both are kind of messy
 though.

--
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] #29174 [Core Tor/Tor]: Guard Node can eclipse the hidden service

[Tor Bug Tracker & Wiki]

#29174: Guard Node can eclipse the hidden service
---+
 Reporter:  TBD.Chen   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor: 0.3.0.1-alpha
 Severity:  Critical   | Resolution:
 Keywords:  guard, hidden service  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by arma):

 Replying to [comment:4 mikeperry]:
 > it would not be to hard to augment it to send periodic end-to-end probes
 for introduce1 circuits

 In the original tor-design paper, we spoke of onion services doing spot-
 checks of their introduction points, to make sure that they are actually
 introducing. That approach would test a larger fraction of the system than
 just doing a liveness check within the circuit. Both are kind of messy
 though.

--
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] #29174 [Core Tor/Tor]: Guard Node can eclipse the hidden service

[Tor Bug Tracker & Wiki]

#29174: Guard Node can eclipse the hidden service
---+
 Reporter:  TBD.Chen   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor: 0.3.0.1-alpha
 Severity:  Critical   | Resolution:
 Keywords:  guard, hidden service  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by mikeperry):

 Replying to [comment:2 nickm]:
 > mikeperry, is this the kind of thing that pathbias is meant to solve?

 If we want the path bias system to check for cases like this, it would not
 be to hard to augment it to send periodic end-to-end probes for introduce1
 circuits, fwiw. We should consider if we want to to that for other
 circuits too.

 I was hopeful that Proposal 295 (or 261 or similar) would allow us to
 remove the path bias code, as crypto tagging attacks would be prevented by
 that. However, circuit choking attacks would not be; we would need
 liveness probes to detect them. End-to-end liveness probes might also help
 with conflux (to more quickly detect when a circuit branch has collapsed
 to build another path).

--
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] #29174 [Core Tor/Tor]: Guard Node can eclipse the hidden service

[Tor Bug Tracker & Wiki]

#29174: Guard Node can eclipse the hidden service
---+
 Reporter:  TBD.Chen   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor: 0.3.0.1-alpha
 Severity:  Critical   | Resolution:
 Keywords:  guard, hidden service  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by mikeperry):

 Interesting. This is another argument for Proposal 291 in my mind. A
 single guard has too much power to induce DoS and other downtime signals
 like this. The vanguards addon should similarly mitigate this attack, as
 it uses 2 guards by default. The malicious guard would just cause
 introduce1 timeouts on clients, but not be able to mount a full "eclipse"
 DoS attack.

 As for path bias -- it was designed to detect circuit failures caused by
 the guard. This case is different because the circuit can become live and
 successfully used for one or more initial introduce1 cells, and thus path
 bias system will deem it successfully used. After that point, there is no
 way for a client to determine if the circuit has just gone quiet because
 no one is using the HS vs the guard simply not sending any more introduce1
 cells on the circuit.

--
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] #29174 [Core Tor/Tor]: Guard Node can eclipse the hidden service

[Tor Bug Tracker & Wiki]

#29174: Guard Node can eclipse the hidden service
---+
 Reporter:  TBD.Chen   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor: 0.3.0.1-alpha
 Severity:  Critical   | Resolution:
 Keywords:  guard, hidden service  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

 * cc: mikeperry (added)


Comment:

 mikeperry, is this the kind of thing that pathbias is meant to solve?

--
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] #29174 [Core Tor/Tor]: Guard Node can eclipse the hidden service

[Tor Bug Tracker & Wiki]

#29174: Guard Node can eclipse the hidden service
---+
 Reporter:  TBD.Chen   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor: 0.3.0.1-alpha
 Severity:  Critical   | Resolution:
 Keywords:  guard, hidden service  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by TBD.Chen):

 * version:  Tor: unspecified => Tor: 0.3.0.1-alpha


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

[tor-bugs] #29174 [Core Tor/Tor]: Guard Node can eclipse the hidden service

[Tor Bug Tracker & Wiki]

#29174: Guard Node can eclipse the hidden service
---+--
 Reporter:  TBD.Chen   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Very High  |  Component:  Core Tor/Tor
  Version:  Tor: unspecified   |   Severity:  Critical
 Keywords:  guard, hidden service  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 For the current Tor protocol, hidden services connect into Tor network
 only through one Guard node (Vanguard is not running on default).
 As a result, all the HS-IntroPoint circuit of the hidden service are all
 using one guard.
 As we all know, the HS-IntroPoint is quite special on its cell sequence,
 so the malicious guard relays can drop all the incoming cells of HS-
 IntroPoint until the hidden service rebuild its HS-IntroPoint circuit.
 And the malicious guard can attack the new circuits again.
 Because the incoming cells of HS-IntroPoint circuit (introduce1 cells) are
 all droped, so the hidden services cannot be accessed by any user, and
 eclipsed by its Guard relay.

 This mater is appearing after reduce the number of guards to one, and if
 the hidden service not run the vangard, the hidden service has the risk of
 being eclipsed.

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