Re: [tor-dev] Proposal: The move to two guard nodes
Roger Dingledine: > On Sat, Mar 31, 2018 at 06:52:51AM +, Mike Perry wrote: > > 3.1. Eliminate path restrictions entirely > > > I'm increasingly a fan of this option, the more I read these threads. > > Let's examine the two attacker assumptions behind two of the attacks > we're worried about. > > Attack one: the client's local ISP collects coarse netflow logs, and these > logs aren't detailed enough to allow a traffic volume detection attack on > an existing long-lived TLS flow, so the connection to that first guard > is safe; but a connection to that second guard will be unusual and not > multiplexed and at exactly the time of the adversary-controlled circuit > that triggered it, so that second guard, because it is used so rarely, > is dangerous to use. > > Attack two: if the client uses its guard as the first hop of its circuit > and also the adversary-requested fourth hop, then the guard can do > pairwise traffic correlation attacks on all of its circuits and realize > that these two circuits it has are really two pieces of the same circuit. > > This second attack seems weird to me. One reason is because in attack > one we're brushing aside the traffic analysis as hard, whereas in attack > two we're assuming it's trivial and perfect. But the simpler reason is: > if your guard is going to participate in a traffic correlation attack > against you, then it could just as easily team up with some other relay > that the adversary picked. That is, avoiding reusing your guard on the > other end of the circuit isn't going to save you if your guard is out > to get you. I agree. I am not concerned about attack two. But we're not choosing between just these two attacks. > To be clear, the design I've been considering here is simply allowing > reuse between the guard hop and the final hop, when it can't be avoided. I > don't mean to allow the guard (or its family) to show up as all four > hops in the path. Is that the same as what you meant, or did you mean > something more thorough? By all path restrictions I mean for the last hop of the circuit and the first (though vanguards would be simpler if we got rid of them for other hops, too). But I do mean all restrictions, not just guard node choice. The adversary also gets to force you to use a second network path whenever they want via the /16 and node family restrictions. And it happens naturally all the time. We're not using one guard in the current Tor. We're using two, and the second one is only used for unmultiplexed activity. That is one property I don't like about our "let's pretend to use one guard" status quo. The second thing I don't like is that one guard is fragile, which enables confirmation attacks when it can be made to go down. > I think "can't be avoided" means HSDir, IP, RP -- which I note are all > onion service related circuits. > > I'd like to hear more about the "cleverly crafted exit policy" attack, and > I wonder if we can't solve that differently. For example, if it's about > making you do a request to a port that only one exit relay allows, and > ha ha whoops your guard was on the same /16 as that exit relay... maybe > it's time for the dir auths to not advertise super rare ports? This was > one of the topics in the users-get-routed paper too. Yes that is the one I was talking about. However, another way to do this type of exit rotation attack is to cause a client to look up a DNS name where you control the resolver, and keep timing out on the DNS response. The client will then retry the stream request with a new exit. The same thing can also be done by timing out the TCP handshake to a server you control. Both of these attacks can be done with only the ability to inject an img tag into a page. You repeat this until an exit is chosen that is in the same /16 or family as the guard, and then the client uses a second network path for an unmultiplexed request at a time you control. > One non-starter idea would be to move onion-service-related Tors to two > guards, and leave other Tors at one guard. It's a non-starter because of > course advertising which you are to your local network is no good. But > that idea gave me a different perspective on this discussion: I wonder > how much this design decision comes down to making all Tors use two > guards in order to protect the onion-service-related Tors, which are > the only ones who actually need it? Our path restrictions also cause normal exiting clients to use a second guard for unmultiplexed activity, at adversary controlled times, or just at periodically at random. > > However, while removing path restrictions will solve the immediate > > problem, it will not address other instances where Tor temporarily opts > > use a second guard due to congestion, OOM, or failure of its primary > > guard, and we're still running into bugs where this can be adversarially > > controlled or just happen randomly[5]. > > I continue to think we need to fix these. I'm glad to see
Re: [tor-dev] Notes from 12 April 2018 Simple Bandwidth Scanner Meeting
> Good question! > > While I didn't necessarily work on sbws while at my place of work, I > couldn't rationalize that it is unrelated to my day job. Thus I need to > get permission from my employer in order to release sbws. > > I've already submitted that paperwork and expect to get it back in about > 2 weeks. > > It is licensed under CC0 and is therefore in the public domain (or will > be... depending on how you want to interpret the situation). > > Fun side note: little-t-tor itself had to go through the same process. > > Sorry for the inconvenience. A! Mystery solved. Makes complete sense - thanks Matt! ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Notes from 12 April 2018 Simple Bandwidth Scanner Meeting
On 4/13/18 12:26, Damian Johnson wrote: >> https://github.com/pastly/simple-bw-scanner/blob/master/docs/source/specification.rst >> (ask Pastly for access) > > Hi Matt, why is this repo read restricted? I was idly curious to see > the code of sbws and was surprised it's effectively closed source. Good question! While I didn't necessarily work on sbws while at my place of work, I couldn't rationalize that it is unrelated to my day job. Thus I need to get permission from my employer in order to release sbws. I've already submitted that paperwork and expect to get it back in about 2 weeks. It is licensed under CC0 and is therefore in the public domain (or will be... depending on how you want to interpret the situation). Fun side note: little-t-tor itself had to go through the same process. Sorry for the inconvenience. Matt ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Notes from 12 April 2018 Simple Bandwidth Scanner Meeting
> https://github.com/pastly/simple-bw-scanner/blob/master/docs/source/specification.rst > (ask Pastly for access) Hi Matt, why is this repo read restricted? I was idly curious to see the code of sbws and was surprised it's effectively closed source. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Notes from 12 April 2018 Simple Bandwidth Scanner Meeting
Thanks Tom! There's a few more things that I think we need to figure out before we take you up on this offer. I'll keep you in mind though, because I think having sbws and torflow running side by side is something that should happen very soon. Stay tuned! And thanks for your help obtaining torflow data recently. Matt On 4/12/18 21:50, Tom Ritter wrote: > I'm happy to run a sbws alongside my torflow. It will let us compare bw > numbers apples to apples too. My only difficulty is being unable to > spend significant time to diagnose why it doesn't work, if it doesn't work. > > If it's at the point I should give it a shot, point me at some > instructions :) > > -tom > ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal: The move to two guard nodes
On Sat, Mar 31, 2018 at 06:52:51AM +, Mike Perry wrote:
> The main argument for switching to two guards is that because of Tor's
> path restrictions, we're already using two guards, but we're using them
> in a suboptimal and potentially dangerous way.
>
> Tor's path restrictions enforce the condition that the same node cannot
> appear twice in the same circuit, nor can nodes from the same /16 subnet
> or node family be used in the same circuit.
>
> Tor's paths are also built such that the exit node is chosen first and
> held fixed during guard node choice, as are the IP, HSDIR, and RPs for
> onion services. This means that whenever one of these nodes happens to
> be the guard[4], or be in the same /16 or node family as the guard, Tor
> will build that circuit using a second "primary" guard, as per proposal
> 271[7].
>
> Worse still, the choice of RP, IP, and exit can all be controlled by an
> adversary (to varying degrees), enabling them to force the use of a
> second guard at will.
I agree with you that we should do something about this bug, where Tor
clients will switch to a rarely used guard in some situations. Our fix
from ticket #14917 was not a good fix. More on that below in Section 3.1.
> Not surprisingly,
> the two guard adversary gets to compromise clients roughly twice as
> quickly, but the timescales are still rather large even for the 10%
> adversary: they only have 50% chance of success after 4 rotations, which
> will take about 14 months with Tor's 3.5 month guard rotation.
Three thoughts here:
(A) You're right, 14 months doesn't sound bad here.
(B) This calculation was ignoring churn, right? That is, guards going
away before you wanted to rotate from them. So another way to phrase that
would be "once eight of your guards have gone away, you're in bad shape"?
Looking at it that way, it seems like two guards is more than twice
as scary as one, since *either* of them going away moves you one step
closer on the path. Not the end of the world, but worth noticing. And
maybe partially solvable by your "when one of your two goes away, stick
to the remaining one" design; more on that below.
(C) Similarly, we should be sure to remember the network adversary
here too. I don't know a simple way to reason about it well. Using more
guards over time could be *less* than twice as scary, because sometimes
the network paths overlap so you don't expose as much new surface area
as you might have. And using more guards over time could be *more*
than twice as scary, if the question is whether your traffic ever goes
over that one bad place, since you have an exponentially low chance to
*never* pick a guard where your traffic to/from that guard travels over
the bad place. It really depends on your location, the guard locations,
the Internet topology, and a bunch of other confusing factors.
> Furthermore, our use of separate directory guards (and three of them)
> means that we're not really changing the situation much with the
> addition of another regular guard. Right now, directory guard use alone
> is enough to track all Tor users across the entire world.
Shit, you're right. The guard set fingerprint issue remains right now,
because we never solved the directory guard side of it. :(
> While the directory guard problem could be fixed[12] (and should be
> fixed), it is still the case that another mechanism should be used for
> the general problem of guard-vs-location management[9].
The part that freaks me out about all the designs I've seen here is the
attack where the local adversary advertises a series of local wireless
addresses, first to make you keep generating new guard contexts (similar
to forcing quick guard rotation), or second to guess-and-check whether
you've already got a guard context for some wireless address in the next
city over. Maybe it can be solved by proper UI ("we'll just delegate
the decision to the user"), but hoo boy. But that's a separate proposal
fortunately. :)
> 3.1. Eliminate path restrictions entirely
>
I'm increasingly a fan of this option, the more I read these threads.
Let's examine the two attacker assumptions behind two of the attacks
we're worried about.
Attack one: the client's local ISP collects coarse netflow logs, and these
logs aren't detailed enough to allow a traffic volume detection attack on
an existing long-lived TLS flow, so the connection to that first guard
is safe; but a connection to that second guard will be unusual and not
multiplexed and at exactly the time of the adversary-controlled circuit
that triggered it, so that second guard, because it is used so rarely,
is dangerous to use.
Attack two: if the client uses its guard as the first hop of its circuit
and also the adversary-requested fourth hop, then the guard can do
pairwise traffic correlation attacks on all of its circuits and realize
that these two circuits it has are really two pieces of the same circuit.
This second attack
