Opened 3 years ago

Last modified 4 weeks ago

#13837 assigned defect

Mitigate guard discovery by pinning middle node

Reported by: asn Owned by: mikeperry
Priority: Medium Milestone: Tor: 0.3.3.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-hs, tor-guard, guard-discovery-prop247-controller
Cc: isis Actual Points:
Parent ID: #9001 Points:
Reviewer: Sponsor: SponsorV-can

Description

Hello,

inspired by the recent discussions on guard discovery, I went ahead
and implemented a small patch for Tor that tries to help defend
against Hidden Service guard discovery attacks.

It basically allows the operator to specify a set of nodes that will
be pinned as middle nodes in Hidden Service rendezvous circuits. The
option only affects HS rendezvous circuits and nothing else.

Of course, it doesn't fix guard discovery, it just pushes guard
discovery to the next hop, so that they need to compromise two boxes
to win.

You can find my branch in 'sticky_mids' at
https://git.torproject.org/user/asn/tor.git .

(Here it is in HTTP shape:
https://gitweb.torproject.org/user/asn/tor.git/shortlog/refs/heads/sticky_mids )

[This is the trac version of https://lists.torproject.org/pipermail/tor-dev/2014-November/007730.html]

Child Tickets

TicketStatusOwnerSummaryComponent
#23101newPredict and build specific HS purpose circuits (rather than GENERAL)Core Tor/Tor

Change History (20)

comment:1 Changed 3 years ago by asn

Milestone: Tor: 0.2.???

FWIW, ideally we would make a more robust version of my mitigation, which allows people to pin all 3 hops through the torrc.

comment:2 Changed 3 years ago by isis

Cc: isis added

comment:3 Changed 12 months ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:4 Changed 11 months ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:5 Changed 6 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:6 Changed 5 months ago by nickm

Keywords: guard-discovery added
Severity: Normal

comment:7 Changed 5 months ago by nickm

Parent ID: #9001

comment:8 Changed 5 months ago by mikeperry

Owner: set to mikeperry
Status: newassigned

I offered to take this in Wilmington, and develop it into a stem-based prototype/performance evaluator.

comment:9 Changed 5 months ago by atagar

Oh interesting. If you'd like help with any of the stem bits Mike then don't hesitate to let me know. :)

comment:10 Changed 4 months ago by nickm

Sponsor: SponsorV-can

comment:11 Changed 4 months ago by mikeperry

Just FYI - I updated asn's branch to current origin/master and renamed the option to HSLayer2Guards. It also now applies to all HS circuit purpose types (not just rends).

New branch location is mikeperry/prop247_torrc-rebased.

Adding HSLayer3Guards next. After that, we can play with stem + onionperf.

comment:12 in reply to:  11 ; Changed 4 months ago by asn

Replying to mikeperry:

Just FYI - I updated asn's branch to current origin/master and renamed the option to HSLayer2Guards. It also now applies to all HS circuit purpose types (not just rends).

New branch location is mikeperry/prop247_torrc-rebased.

Adding HSLayer3Guards next. After that, we can play with stem + onionperf.

Sounds good. Took a look at the code and looks reasonable. WRT to:

 * XXX: Hrmm.. HSDIR fetches might be CIRCUIT_PURPOSE_C_GENRAL.. How do
 * we differentiate those?

perhaps you can check for the rend_data field on the origin_circuit_t if you have access to that.

comment:13 in reply to:  12 Changed 4 months ago by mikeperry

Replying to asn:

Replying to mikeperry:

Just FYI - I updated asn's branch to current origin/master and renamed the option to HSLayer2Guards. It also now applies to all HS circuit purpose types (not just rends).

New branch location is mikeperry/prop247_torrc-rebased.

Adding HSLayer3Guards next. After that, we can play with stem + onionperf.

Sounds good. Took a look at the code and looks reasonable. WRT to:

 * XXX: Hrmm.. HSDIR fetches might be CIRCUIT_PURPOSE_C_GENRAL.. How do
 * we differentiate those?

perhaps you can check for the rend_data field on the origin_circuit_t if you have access to that.

I don't yet. What I did instead was to set a special purpose for HSDIR fetches. Was tricky, but seems to work. I pushed a couple of commits for this and am now testing it with stem.

Also, I noticed that because this patch disables cannibalization, it makes building predicted circuits for hidden services pointless. We also need to alter circuit_predict_and_launch_new() to build the correct purpose breakdown for the HS purposes we need for prediction to do anything for us here... This might impact performance of the prototype. Bleh.

comment:14 Changed 4 months ago by mikeperry

The repo for the stem-based prototype is now https://github.com/mikeperry-tor/vanguards. It requires the tor patches in https://gitweb.torproject.org/mikeperry/tor.git/log/?h=prop247_torrc-rebased

I also filed #23101 for the prediction issue, and #23100 for a CBT issue.

comment:15 Changed 3 months ago by nickm

Just skimmed the simulation code -- this looks like a plausible place to begin with the measurements. Do we have a plan to do these measurements, or should we make one?

Also, I'm assuming that this simulation isn't trying to simulate the exact way in which guard sets change over time. If it is, we need to bring it into conformance with prop271.

comment:16 in reply to:  15 Changed 3 months ago by mikeperry

Replying to nickm:

Just skimmed the simulation code -- this looks like a plausible place to begin with the measurements. Do we have a plan to do these measurements, or should we make one?

There is a rough outline of a plan in the comments of that script, but I've been thinking a bit more about it since then. Basically, I think we want to run several onionperf instances with different values for each of the NUM_LAYERN_GUARDS values. We may also want to play with cutting off various percentiles of the network (though this capability is not written in the prototype yet).

We're going to need to measure variance of these instances somehow, or ideally even capture the full performance density distribution for a given parameter set. Variance in performance over time will be the key thing that changes with the parameters. We want to minimize this variance for sane parameter values. I think what this means is that we want to scale the rotation times down, so as to capture the effect of rotation on our performance variance over time for a fixed parameter set.

Also, I'm assuming that this simulation isn't trying to simulate the exact way in which guard sets change over time. If it is, we need to bring it into conformance with prop271.

I thought about this and I don't think we want something very much like prop271 at all. prop271 has a lot of logic about trying to determine connectivity and detect and protect against various guard biasing attempts. For this code, I think we should trust the consensus completely, and have the notion of a "fallback set" and the "primary set", where we prefer the "primary set" if they are in the consensus, but fall back to members of the "fallback set" otherwise. This is kind of what the code does, but hat part is a bit wonky and could be done better.

comment:17 Changed 3 months ago by mikeperry

FYI: I will be writing a more thorough experimentation plan, a README, and looking at onionperf after I complete more work on subtickets of #9001, but this may not happen until September.

comment:18 Changed 4 weeks ago by mikeperry

Keywords: SponsorV-033 added

comment:19 Changed 4 weeks ago by mikeperry

Keywords: guard-discovery-033 added; guard-discovery SponsorV-033 removed

comment:20 Changed 4 weeks ago by mikeperry

Keywords: guard-discovery-prop247-controller added; guard-discovery-033 removed
Milestone: Tor: unspecifiedTor: 0.3.3.x-final
Note: See TracTickets for help on using tickets.