Opened 3 months ago

Last modified 9 days ago

#29174 new defect

Guard Node can eclipse the hidden service

Reported by: TBD.Chen Owned by:
Priority: Very High Milestone: Tor: 0.4.1.x-final
Component: Core Tor/Tor Version: Tor: 0.3.0.1-alpha
Severity: Critical Keywords: guard, hidden service
Cc: mikeperry Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (8)

comment:1 Changed 3 months ago by TBD.Chen

Version: Tor: unspecifiedTor: 0.3.0.1-alpha

comment:2 Changed 2 months ago by nickm

Cc: mikeperry added

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

comment:3 Changed 2 months ago 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.

comment:4 in reply to:  2 ; Changed 2 months ago by mikeperry

Replying to 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).

comment:5 in reply to:  4 ; Changed 2 months ago by arma

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

comment:6 in reply to:  5 Changed 2 months ago by TBD.Chen

I think using 2 guards is 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 arma:

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

Last edited 2 months ago by TBD.Chen (previous) (diff)

comment:7 in reply to:  3 Changed 8 weeks ago 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 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.

comment:8 Changed 9 days ago by nickm

Milestone: Tor: 0.4.1.x-final
Note: See TracTickets for help on using tickets.