On Fri, Jul 11, 2014 at 08:31:05AM -0400, Ian Goldberg wrote:
On Fri, Jul 11, 2014 at 01:44:36PM +0300, George Kadianakis wrote:
Hey Nick,
this mail is about the schemes we were discussing during the dev meeting on how to protect HSes against guard discovery attacks (#9001).
I think we have some ideas on how to offer better protection against such attacks, mainly by keeping our middle nodes more static than we do currently.
For example, we could keep our middle nodes for 3-4 days instead of choosing new ones for every circuit. As Roger has suggested, maybe we don't even need to write the static middle nodes on the state file, just use new ones if Tor has restarted.
Keeping middle nodes around for longer will make those attacks much slower (it restricts them to one attack attempt every 3-4 days), but are there any serious negative implications?
For example, if you were unlucky and you picked an evil middle node, and you keep it for 3-4 days, that middle node will always see your traffic coming through your guard (assuming a single guard per client). If we assume you use a non-popular guard node (with only a few clients using it), the middle guard might be able to think "Ah, the circuit that comes from that guard node is always user X" making your circuits a bit linkable from the PoV of your middle node.
And similarly at the exit node: the exit will now know that circuits coming from the same middle are more likely to be the same client. That's a little more worrying to me than the above.
Right. Lasse and I suggested and explored the idea of layered guards when we introduced guards. There are lots of possibilities here. You can have a set of midguards per guard. Don't remember if it made it into the paper, but when Roger, Nick, Aaron, and I did the downhill paths paper we also talked about having a rotation rate for choice of middle guards that was faster than for guards but not simply a new weighted-random midnode for each circuit. Gotta run.
-Paul