Mitigate guard discovery by pinning middle node
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]
Activity
changed milestone to %Tor: 0.3.3.x-final
Trac:
Parent: N/A to #9001 (moved)
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.
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_datafield on theorigin_circuit_tif you have access to that.-
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_datafield on theorigin_circuit_tif 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.
-
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 (moved) for the prediction issue, and #23100 (moved) for a CBT issue.
-
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.
-
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.
-
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 (moved), but this may not happen until September.