Hidden services should try harder to reuse their old intro points

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.

changed milestone to %Tor: 0.2.7.x-final

added 026-triaged-1 027-triaged-1-in. component::core tor/tor milestone::Tor: 0.2.7.x-final points::medium priority::medium research resolution::implemented sponsor::R status::closed tor-hs type::enhancement version::tor 0.2.7 labels

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.

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?

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

Trac:
Milestone: Tor: 0.2.5.x-final to Tor: 0.2.6.x-final

See also https://lists.torproject.org/pipermail/tor-dev/2014-August/007335.html

Trac:
Keywords: tor-hs deleted, tor-hs 026-triaged-1 added

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

Trac:
Keywords: tor-hs 026-triaged-1 deleted, SponsorR tor-hs 026-triaged-1 added

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

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?

Trac:
Milestone: Tor: 0.2.6.x-final to Tor: 0.2.7.x-final

Trac:
Status: new to assigned

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

Trac:
Keywords: SponsorR tor-hs 026-triaged-1 deleted, SponsorR, 026-triaged-1, tor-hs, 027-triaged-1-in added

Trac:
Points: N/A to medium
Keywords: 027-triaged-1-in deleted, 027-triaged-1-in. research added
Version: N/A to Tor: 0.2.7

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

Replying to dgoulet:

Branch under review in #4862 (moved) 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.

Merged #4862 (moved) branch.

Trac:
Resolution: N/A to implemented
Status: assigned to closed

Trac:
Keywords: SponsorR, 027-triaged-1-in. research deleted, 027-triaged-1-in., research added
Sponsor: N/A to SponsorR

closed

mentioned in issue #8864 (moved)

mentioned in issue #13699 (moved)

mentioned in issue #15463 (moved)

mentioned in issue #16120 (moved)

mentioned in issue #16260 (moved)

mentioned in issue #16387 (moved)

mentioned in issue #24313 (moved)

mentioned in issue #31561 (moved)

moved to tpo/core/tor#8239 (closed)

mentioned in issue tpo/core/tor#16120 (closed)

mentioned in issue tpo/core/tor#16387 (closed)