Opened 5 months ago

Last modified 3 weeks ago

#29174 new defect

Onion service can do self-reachability tests to detect overwhelmed guards

Reported by: TBD.Chen Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.3.0.1-alpha
Severity: Normal Keywords: guard, hidden, service, security, 041-longterm
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 (13)

comment:1 Changed 5 months ago by TBD.Chen

Version: Tor: unspecifiedTor: 0.3.0.1-alpha

comment:2 Changed 4 months ago by nickm

Cc: mikeperry added

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

comment:3 Changed 4 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 4 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 4 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 4 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 4 months ago by TBD.Chen (previous) (diff)

comment:7 in reply to:  3 Changed 4 months 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 2 months ago by nickm

Milestone: Tor: 0.4.1.x-final

comment:9 Changed 5 weeks ago by nickm

Keywords: security added

comment:10 Changed 5 weeks ago by nickm

Keywords: 041-longterm added

Marking tickets that I think are valuable but which are likely to need more work in 0.4.2.

comment:11 Changed 4 weeks ago by asn

Priority: Very HighMedium

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.

comment:12 in reply to:  11 Changed 4 weeks ago 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 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.

comment:13 Changed 3 weeks ago by asn

Milestone: Tor: 0.4.1.x-finalTor: unspecified
Severity: CriticalNormal
Summary: Guard Node can eclipse the hidden serviceOnion service can do self-reachability tests to detect overwhelmed guards

Renaming ticket appropriately after the final comment. Also a bit of triaging.

Note: See TracTickets for help on using tickets.