Opened 5 years ago

Closed 2 years ago

Last modified 2 years ago

#8239 closed enhancement (implemented)

Hidden services should try harder to reuse their old intro points

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: 0.2.7.x-final
Component: Core Tor/Tor Version: Tor: 0.2.7
Severity: Keywords: tor-hs, 026-triaged-1, 027-triaged-1-in., research
Cc: n8fr8 Actual Points:
Parent ID: Points: medium
Reviewer: Sponsor: SponsorR

Description

The current hidden service behavior is that when Tor loses its intro circuits, it chooses new intro points and makes new circuits to them -- which means anybody who has the old hidden service descriptor is going to be introducing herself to the wrong intro points.

If our intro circuits close, but it was because our network failed and not because the intro points failed, we should reestablish new intro circuits to the *old* intro points.

Nathan wants this for running hidden services on Orbot, since Orbot users change networks (and thus lose existing circuits) quite often.

I expect the main tricky point to be distinguishing "network failed" from "intro point failed". I wonder if some of our CBT work is reusable here.

Child Tickets

Change History (17)

comment:1 in reply to:  description ; Changed 5 years ago by rransom

Replying to arma:

If our intro circuits close, but it was because our network failed and not because the intro points failed, we should reestablish new intro circuits to the *old* intro points.

This would make a hidden service's intro-point relays appear to ‘be responsible for’ the hidden service. The fact that reopening an intro point with the same ‘address’ as a previous one is possible is a bug in Tor's protocol.

Also, merely reusing introduction points would not make HSes on flaky connections work significantly less badly. Their clients would still have to rebuild their rendezvous circuits.

The right way to help Tor clients with flaky connections maintain long-term circuits and streams is to add a circuit-resumption feature to the Tor protocol.

comment:2 in reply to:  1 ; Changed 5 years ago by arma

Replying to rransom:

Also, merely reusing introduction points would not make HSes on flaky connections work significantly less badly. Their clients would still have to rebuild their rendezvous circuits.

I'm focusing on the fact that clients will fetch (or just re-use) the old hidden service descriptor, which lists the old introduction points, and be introducing themselves to the wrong place.

Unless I misunderstand your misunderstanding?

comment:3 in reply to:  2 Changed 5 years ago by rransom

Replying to arma:

Replying to rransom:

Also, merely reusing introduction points would not make HSes on flaky connections work significantly less badly. Their clients would still have to rebuild their rendezvous circuits.

I'm focusing on the fact that clients will fetch (or just re-use) the old hidden service descriptor, which lists the old introduction points, and be introducing themselves to the wrong place.

If a hidden service chooses new intro points after its Internet connection fails, its clients will try the old intro points and find that they no longer work, then fetch a new HS descriptor, then successfully reconnect to the HS.

If a hidden service reuses its old intro points after its Internet connection fails, its clients will try the old intro points and find that they no longer work, then try to fetch a new HS descriptor and find that there isn't one, then fail completely.

If a hidden service could resume its OR connections or circuits at the entry-guard end, its clients wouldn't have to do anything to reconnect to the HS, and they probably wouldn't notice a disruption at all. (This is not only better for performance, but also better for the HS's anonymity.)

comment:4 Changed 4 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.6.x-final

comment:6 Changed 3 years ago by asn

FWIW, it's also worth mentioning that making HSes more stubborn towards old IPs might also allow guard discovery attacks from the IP. That is the IP kills incoming circuits, till a compromised middle node is selected, and since the HS is stubborn it will keep on establishing new circuits.

This was mentioned by waldo here:
https://lists.torproject.org/pipermail/tor-dev/2014-May/006843.html

Last edited 3 years ago by asn (previous) (diff)

comment:7 Changed 3 years ago by arma

Keywords: SponsorR added

comment:8 in reply to:  6 ; Changed 3 years ago by arma

Replying to asn:

FWIW, it's also worth mentioning that making HSes more stubborn towards old IPs might also allow guard discovery attacks from the IP. That is the IP kills incoming circuits, till a compromised middle node is selected, and since the HS is stubborn it will keep on establishing new circuits.

That's why you should only stick to your intro point when it's your network that failed (that is, the connection between you and your guard), not the intro circuit. (This is what I meant in the body of the bug in the 'main tricky point' sentence.)

comment:9 in reply to:  8 Changed 3 years ago by asn

Replying to arma:

Replying to asn:

FWIW, it's also worth mentioning that making HSes more stubborn towards old IPs might also allow guard discovery attacks from the IP. That is the IP kills incoming circuits, till a compromised middle node is selected, and since the HS is stubborn it will keep on establishing new circuits.

That's why you should only stick to your intro point when it's your network that failed (that is, the connection between you and your guard), not the intro circuit. (This is what I meant in the body of the bug in the 'main tricky point' sentence.)

Hm, indeed. Distinguishing network down events has been annoying also for entry guard security (https://lists.torproject.org/pipermail/tor-dev/2014-August/007346.html).
I wonder if this is an easier case though.

How many ways are there for an IP to terminate the intro circuit? Are they enumerable?

If the IP closes the connection to its previous hop, will the other hops report that it was the IP's fault that the circuit was destroyed?

Can the IP send an unexpected cell to the guard node, and force the guard node to tear down the circuit? So that it looks like it's the fault of the guard node?

comment:10 Changed 3 years ago by nickm

Milestone: Tor: 0.2.6.x-finalTor: 0.2.7.x-final

comment:11 Changed 3 years ago by nickm

Status: newassigned

comment:12 Changed 3 years ago by nickm

Keywords: 027-triaged-1-in added

Marking some tickets as triaged-in for 0.2.7 based on early triage

comment:13 Changed 3 years ago by isabela

Keywords: 027-triaged-1-in. research added; 027-triaged-1-in removed
Points: medium
Version: Tor: 0.2.7

comment:14 Changed 3 years ago by dgoulet

Branch under review in #4862 fixes this ticket.
(bug4862_027_02 - commit: b8bce969a4b930c3a3819f01f2efd7c657a95e43)

comment:15 in reply to:  14 Changed 3 years ago by asn

Replying to dgoulet:

Branch under review in #4862 fixes this ticket.
(bug4862_027_02 - commit: b8bce969a4b930c3a3819f01f2efd7c657a95e43)

Note: IIUC the commit does not suffer from the guard discovery issue because it limits the reuse attempts to 3 tries.

comment:16 Changed 2 years ago by nickm

Resolution: implemented
Status: assignedclosed

Merged #4862 branch.

comment:17 Changed 2 years ago by dgoulet

Keywords: SponsorR removed
Sponsor: SponsorR
Note: See TracTickets for help on using tickets.