Re: [tor-dev] Setting NumEntryGuards=2

[David Goulet]

On 22 Mar (17:13:40), Mike Perry wrote:
> David Goulet:
> > On 22 Mar (13:46:36), George Kadianakis wrote:
> > > Mike Perry  writes:
> > > 
> > > > Arguments in favor of switching to two entry guards:
> > > >
> > > > 1. One guard allows course-grained netflow confirmation attacks
> > > >
> > > > The counterargument based on #14917 above also has an additional
> > > > wrinkle: an adversary watching a suspect list of clients can easily
> > > > observe the "temporarily use a second guard" activity using just
> > > > connection-level ISP/AS netflow logs. To a large-scale netflow
> > > > adversary, the use of a second guard only when the guard is chosen as
> > > > the RP confirms not only guard choice, but the IP address of the onion
> > > > service itself.
> > > 
> > > Devil's advocate: I'm not sure how big the suspect list we are thinking
> > > about is, or what kind of threat models we are considering here, and I
> > > think this matters quite a bit. Because if the suspect list is not big,
> > > and the threat models allows the attacker to cause the victim to build
> > > circuits, then the attacker could succeed even with simple traffic
> > > signals (or shutting down the internet) and traffic monitoring.
> > > 
> > > Also, this whole point relies on our suboptimal fix to #14917. We could
> > > improve the situation here by doing more advanced fix like the one
> > > suggested above.
> > 
> > Agree with George here. I think 1 or 2 Guards here won't matter much in this
> > attack as mentionned where Alice can just keep injecting traffic pattern on
> > both Guards for identification at the netflow records level.
> 
> I strongly disagree. Dumping more traffic onto an already existing,
> otherwise in-use connection is not the same as the ability to force a
> new connection that is only used for a single request at a very specific
> time. These are completely different data retention resolutions, and if
> the netflow padding works as intended, dumping traffic onto an existing
> connection will be rolled up into all other traffic during that hour, or
> longer. At large scale, routers will likely be recording flows at just
> the connection level only, if that.
> 
> What this means in practice is the ability for an adversary to go to
> large ISPs and say "Hey, give me connection logs you already have/can
> easily generate for these IPs during this specific time period" instead
> of "Hey, install this custom black box monitoring equipment for me and
> let me get arbitrary reports from it whenever I want". I know ISPs that
> have received and refused the black box request case because it was too
> intrusive. I also know ISPs that have given records over in the
> connection-level case.

Hmm, that is a very good point. I haven't thought in terms of the forcing
a new connection vs shoving traffic in an existing connection.

David

-- 
hgJe5VGAkZPnC/W4iPXnCuf1HcG2evYQqVjeb8Ugb4Y=


signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Setting NumEntryGuards=2

[grarpamp]

On Thu, Mar 22, 2018 at 1:13 PM, Mike Perry  wrote:
> I strongly disagree. Dumping more traffic onto an already existing,
> otherwise in-use connection is not the same as the ability to force a
> new connection that is only used for a single request at a very specific
> time. These are completely different data retention resolutions, and
> if the netflow padding works as intended, dumping traffic onto an existing
> connection will be rolled up into all other traffic during that hour, or
> longer. At large scale, routers will likely be recording flows at just
> the connection level only, if that.
>
> What this means in practice is the ability for an adversary to go to
> large ISPs and say "Hey, give me connection logs you already have/can
> easily generate for these IPs during this specific time period" instead
> of "Hey, install this custom black box monitoring equipment for me and
> let me get arbitrary reports from it whenever I want". I know ISPs that
> have received and refused the black box request case because it was too
> intrusive. I also know ISPs that have given records over in the
> connection-level case.

Yes it's important to distinguish specific "netflow" style of records
analysis, from more general statistical traffic analysis of packets
flowing through a network, even if only from a limited to degenerate
number (2) of observation / targeting points. Even the simplest of
overlay networks could be considered at least a start against
the former. While the latter is a hard problem for nearly all of todays
networks and why few if any can claim to have resistance to anything
resembling GPA / GAA. Listing proposed solutions to the latter,
and why adoption of any of them into any overlay (or base layer)
network be it existing or new,  doesn't seem to really be happening
yet... a fine topic for another thread.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Setting NumEntryGuards=2

[Mike Perry]

George Kadianakis:
> David Goulet  writes:
> > On 22 Mar (13:46:36), George Kadianakis wrote:
> >> Mike Perry  writes:
> >> > Roger suggested that I enumerate the pros and cons of this increase on
> >> > this mailing list, so we can discuss and consider this switch. So here
> >> > is my attempt at that list. Let's start with a more in-depth recap of
> >> > the one-guard arguments, along with some recent observations that change
> >> > things.
> >> >
> >> > Arguments for staying with just one guard:
> >> >
> >> > 1. One guard means less observability.
> >> >
> >> > As Roger put it in the above blog post: "I think the analysis of the
> >> > network-level adversary in Aaron's paper is the strongest argument for
> >> > restricting the variety of Internet paths that traffic takes between the
> >> > Tor client and the Tor network."
> >> > http://freehaven.net/anonbib/#ccs2013-usersrouted
> >> >
> >> > Unfortunately, we have since learned that Tor's path selection has the
> >> > effect of giving the adversary the ability to generate at least one
> >> > additional observation path. We first became aware of this in
> >> > https://trac.torproject.org/projects/tor/ticket/14917, where the change
> >> > to one guard allowed an adversary to discover your guard by choosing it
> >> > as a rendezvous point and observing the circuit failure. After the fix
> >> > for #14917, the onion service will build a connection to a second guard
> >> > that it keeps in reserve. By using this attack (as well as a similar but
> >> > more involved attack with unique exit policies and carefully chosen /16
> >> > exit node subnets), the adversary can force clients to be observed over
> >> > two paths whenever they like.
> >> >
> >> > So while we may get benefit for moving from three guards to two guards,
> >> > we don't get much (or any) benefit from moving to two guards to one
> >> > guard against an active adversary that either connects to onion
> >> > services, or serves content to clients and runs exits.
> >> >
> >> 
> >> Hmm, that's a fair point. However, the fact that this behavior exists
> >> currently does not mean that it's the best we can do with what we have.
> >> 
> >> Example of what we can do to stop this bad behavior: instead of using
> >> our second guard when our "exit" conflicts with our first guard like
> >> this: [G2 -> M1 -> G1], we could instead make a 4-hop circuit as
> >> follows: [G1 -> M1 -> M2 -> G2]. This would stop us from using our
> >> second guard and would hide the obvious signal you are worrying about.
> >> (I see that dgoulet also suggested that in the ticket comment:7)
> >
> > For hidden service, I think you meant [G1 -> M1 -> M2 -> *G1*] considering
> > that G1 is the chosen RP. But also, I think my comment was very wrong 3 
> > years
> > ago, a service already builds a 4 hops to the RP so it should then be this 
> > in
> > your example?: [G1 -> M1 -> M2 -> M3 -> G1]
> 
> Yep, you are right in everything here.
> 
> > This makes it VERY easy for a Guard node to learn that it is the guard of a
> > specific .onion but considering an evil guard of a .onion, there are other
> > effective methods to learn it so I'm not convinced that this path will be
> > worst, just maybe bad for performance.
> 
> Why bad for performance? It will be the same length as currently.
> 
> > But also this would violate tor protocol of "never having the same hop in 
> > the
> > path" so overall making an exeception for this makes me worry a bit :S.
> 
> I think this is your main objection to this approach, and I understand
> it, but I'm not sure how well-enforced this tor protocol "rule" is, or
> how much we should respect it given that this is an important security
> edge-case that we can solve.
> 
> > I do agree with Mike on this one that we don't get benefit here from 1 to 2
> > because the code right now is basically a two guard system where the second
> > guard is used rarely. Not only that but an attacker can force you to use 
> > that
> > second Guard at will.
> 
> I don't think this is true anymore, if we accept
> [G1 -> M1 -> M2 -> M3 -> G1] as a reasonable solution.

Even if we allow this case, we still run up against other path
restrictions that enable the adversary to force the same new connection
behavior though. If we allow the same guard in multiple points in the
same circuit, new connections can be forced for the case where the RP is
in the same /16 or same family as the guard. This is not the same level
of info, but I still believe that the ability to force a new entry
connection is an extremely bad property. We can only avoid that by
abandoning all circuit restrictions for the RP/exit, or by having two
guards.

I feel vaguely uncomfortable abandoning all of Tor's path restrictions
for certain circuits, but I don't have a good argument against doing
that.

However, given the other benefits from having two dedicated guards
(especially traffic analysis and DoS 

Re: [tor-dev] Setting NumEntryGuards=2

[Mike Perry]

David Goulet:
> On 22 Mar (13:46:36), George Kadianakis wrote:
> > Mike Perry  writes:
> > 
> > > Arguments in favor of switching to two entry guards:
> > >
> > > 1. One guard allows course-grained netflow confirmation attacks
> > >
> > > The counterargument based on #14917 above also has an additional
> > > wrinkle: an adversary watching a suspect list of clients can easily
> > > observe the "temporarily use a second guard" activity using just
> > > connection-level ISP/AS netflow logs. To a large-scale netflow
> > > adversary, the use of a second guard only when the guard is chosen as
> > > the RP confirms not only guard choice, but the IP address of the onion
> > > service itself.
> > 
> > Devil's advocate: I'm not sure how big the suspect list we are thinking
> > about is, or what kind of threat models we are considering here, and I
> > think this matters quite a bit. Because if the suspect list is not big,
> > and the threat models allows the attacker to cause the victim to build
> > circuits, then the attacker could succeed even with simple traffic
> > signals (or shutting down the internet) and traffic monitoring.
> > 
> > Also, this whole point relies on our suboptimal fix to #14917. We could
> > improve the situation here by doing more advanced fix like the one
> > suggested above.
> 
> Agree with George here. I think 1 or 2 Guards here won't matter much in this
> attack as mentionned where Alice can just keep injecting traffic pattern on
> both Guards for identification at the netflow records level.

I strongly disagree. Dumping more traffic onto an already existing,
otherwise in-use connection is not the same as the ability to force a
new connection that is only used for a single request at a very specific
time. These are completely different data retention resolutions, and if
the netflow padding works as intended, dumping traffic onto an existing
connection will be rolled up into all other traffic during that hour, or
longer. At large scale, routers will likely be recording flows at just
the connection level only, if that.

What this means in practice is the ability for an adversary to go to
large ISPs and say "Hey, give me connection logs you already have/can
easily generate for these IPs during this specific time period" instead
of "Hey, install this custom black box monitoring equipment for me and
let me get arbitrary reports from it whenever I want". I know ISPs that
have received and refused the black box request case because it was too
intrusive. I also know ISPs that have given records over in the
connection-level case.

I will reply to the discussion of other options for the #14917 fix in
the other branch of this thread.

-- 
Mike Perry


signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Setting NumEntryGuards=2

[George Kadianakis]

David Goulet  writes:

> [ text/plain ]
> On 22 Mar (13:46:36), George Kadianakis wrote:
>> Mike Perry  writes:
>> 
>> > [ text/plain ]
>> > Back in 2014, Tor moved from three guard nodes to one guard node:
>> > https://blog.torproject.org/improving-tors-anonymity-changing-guard-parameters
>> > https://trac.torproject.org/projects/tor/ticket/12206
>> >
>> > We made this change primarily to limit points of observability of entry
>> > into the Tor network for clients and onion services, as well as to
>> > reduce the ability of an adversary to track clients as they move from
>> > one internet connection to another by their choice of guards.
>> >
>> > At the time, I was in favor of two entry guards but did not have a
>> > strong preference, and we ended up choosing one guard. After seeing
>> > various consequences of using only one entry guard, I think a much
>> > stronger case can now be made for bumping back up to two.
>> >
>> 
>> 
>> 
>> > Roger suggested that I enumerate the pros and cons of this increase on
>> > this mailing list, so we can discuss and consider this switch. So here
>> > is my attempt at that list. Let's start with a more in-depth recap of
>> > the one-guard arguments, along with some recent observations that change
>> > things.
>> >
>> >
>> > Arguments for staying with just one guard:
>> >
>> > 1. One guard means less observability.
>> >
>> > As Roger put it in the above blog post: "I think the analysis of the
>> > network-level adversary in Aaron's paper is the strongest argument for
>> > restricting the variety of Internet paths that traffic takes between the
>> > Tor client and the Tor network."
>> > http://freehaven.net/anonbib/#ccs2013-usersrouted
>> >
>> > Unfortunately, we have since learned that Tor's path selection has the
>> > effect of giving the adversary the ability to generate at least one
>> > additional observation path. We first became aware of this in
>> > https://trac.torproject.org/projects/tor/ticket/14917, where the change
>> > to one guard allowed an adversary to discover your guard by choosing it
>> > as a rendezvous point and observing the circuit failure. After the fix
>> > for #14917, the onion service will build a connection to a second guard
>> > that it keeps in reserve. By using this attack (as well as a similar but
>> > more involved attack with unique exit policies and carefully chosen /16
>> > exit node subnets), the adversary can force clients to be observed over
>> > two paths whenever they like.
>> >
>> > So while we may get benefit for moving from three guards to two guards,
>> > we don't get much (or any) benefit from moving to two guards to one
>> > guard against an active adversary that either connects to onion
>> > services, or serves content to clients and runs exits.
>> >
>> 
>> Hmm, that's a fair point. However, the fact that this behavior exists
>> currently does not mean that it's the best we can do with what we have.
>> 
>> Example of what we can do to stop this bad behavior: instead of using
>> our second guard when our "exit" conflicts with our first guard like
>> this: [G2 -> M1 -> G1], we could instead make a 4-hop circuit as
>> follows: [G1 -> M1 -> M2 -> G2]. This would stop us from using our
>> second guard and would hide the obvious signal you are worrying about.
>> (I see that dgoulet also suggested that in the ticket comment:7)
>
> For hidden service, I think you meant [G1 -> M1 -> M2 -> *G1*] considering
> that G1 is the chosen RP. But also, I think my comment was very wrong 3 years
> ago, a service already builds a 4 hops to the RP so it should then be this in
> your example?: [G1 -> M1 -> M2 -> M3 -> G1]
>

Yep, you are right in everything here.

> This makes it VERY easy for a Guard node to learn that it is the guard of a
> specific .onion but considering an evil guard of a .onion, there are other
> effective methods to learn it so I'm not convinced that this path will be
> worst, just maybe bad for performance.
>

Why bad for performance? It will be the same length as currently.

> But also this would violate tor protocol of "never having the same hop in the
> path" so overall making an exeception for this makes me worry a bit :S.
>

I think this is your main objection to this approach, and I understand
it, but I'm not sure how well-enforced this tor protocol "rule" is, or
how much we should respect it given that this is an important security
edge-case that we can solve.

> I do agree with Mike on this one that we don't get benefit here from 1 to 2
> because the code right now is basically a two guard system where the second
> guard is used rarely. Not only that but an attacker can force you to use that
> second Guard at will.
>

I don't think this is true anymore, if we accept
[G1 -> M1 -> M2 -> M3 -> G1] as a reasonable solution.
___
tor-dev mailing list
tor-dev@lists.torproject.org

Re: [tor-dev] Setting NumEntryGuards=2

[David Goulet]

On 22 Mar (13:46:36), George Kadianakis wrote:
> Mike Perry  writes:
> 
> > [ text/plain ]
> > Back in 2014, Tor moved from three guard nodes to one guard node:
> > https://blog.torproject.org/improving-tors-anonymity-changing-guard-parameters
> > https://trac.torproject.org/projects/tor/ticket/12206
> >
> > We made this change primarily to limit points of observability of entry
> > into the Tor network for clients and onion services, as well as to
> > reduce the ability of an adversary to track clients as they move from
> > one internet connection to another by their choice of guards.
> >
> > At the time, I was in favor of two entry guards but did not have a
> > strong preference, and we ended up choosing one guard. After seeing
> > various consequences of using only one entry guard, I think a much
> > stronger case can now be made for bumping back up to two.
> >
> 
> Hello Mike,
> 
> thanks for writing this post. Thinking about entry guards is extremely
> important since guards and path selection is pretty much the whole
> security of Tor.
> 
> However we should think hard here before flapping from one conf to
> another.  In the grand scheme of things, I see the positives of moving
> to two guards but also the positives of staying with one guard; I think
> we need more data to decide what's best and for which threat models.
> 
> In general, the main argument for me to stay with one guard is to
> minimize client exposure to guards over a period of time. If we choose
> two guards instead of one, clients will expose themselves to double the
> amount of guards over time (not to take into account flaky unreachable
> guards). Perhaps we could compensate that by increasing the lifetime of
> guards if we switch to two guards... I think simulations and graphs here
> to show exposure of guards per number of guards would be useful, and we
> have some of those already for prop247.
> 
> OTOH the main arguments for me to switch to two guards is not so much
> security but performance improvements and reducing congestion of guard
> nodes.
> 
> > Roger suggested that I enumerate the pros and cons of this increase on
> > this mailing list, so we can discuss and consider this switch. So here
> > is my attempt at that list. Let's start with a more in-depth recap of
> > the one-guard arguments, along with some recent observations that change
> > things.
> >
> >
> > Arguments for staying with just one guard:
> >
> > 1. One guard means less observability.
> >
> > As Roger put it in the above blog post: "I think the analysis of the
> > network-level adversary in Aaron's paper is the strongest argument for
> > restricting the variety of Internet paths that traffic takes between the
> > Tor client and the Tor network."
> > http://freehaven.net/anonbib/#ccs2013-usersrouted
> >
> > Unfortunately, we have since learned that Tor's path selection has the
> > effect of giving the adversary the ability to generate at least one
> > additional observation path. We first became aware of this in
> > https://trac.torproject.org/projects/tor/ticket/14917, where the change
> > to one guard allowed an adversary to discover your guard by choosing it
> > as a rendezvous point and observing the circuit failure. After the fix
> > for #14917, the onion service will build a connection to a second guard
> > that it keeps in reserve. By using this attack (as well as a similar but
> > more involved attack with unique exit policies and carefully chosen /16
> > exit node subnets), the adversary can force clients to be observed over
> > two paths whenever they like.
> >
> > So while we may get benefit for moving from three guards to two guards,
> > we don't get much (or any) benefit from moving to two guards to one
> > guard against an active adversary that either connects to onion
> > services, or serves content to clients and runs exits.
> >
> 
> Hmm, that's a fair point. However, the fact that this behavior exists
> currently does not mean that it's the best we can do with what we have.
> 
> Example of what we can do to stop this bad behavior: instead of using
> our second guard when our "exit" conflicts with our first guard like
> this: [G2 -> M1 -> G1], we could instead make a 4-hop circuit as
> follows: [G1 -> M1 -> M2 -> G2]. This would stop us from using our
> second guard and would hide the obvious signal you are worrying about.
> (I see that dgoulet also suggested that in the ticket comment:7)

For hidden service, I think you meant [G1 -> M1 -> M2 -> *G1*] considering
that G1 is the chosen RP. But also, I think my comment was very wrong 3 years
ago, a service already builds a 4 hops to the RP so it should then be this in
your example?: [G1 -> M1 -> M2 -> M3 -> G1]

This makes it VERY easy for a Guard node to learn that it is the guard of a
specific .onion but considering an evil guard of a .onion, there are other
effective methods to learn it so I'm not convinced that this path will be
worst, just maybe bad for 

Re: [tor-dev] Setting NumEntryGuards=2

[George Kadianakis]

Mike Perry  writes:

> [ text/plain ]
> Back in 2014, Tor moved from three guard nodes to one guard node:
> https://blog.torproject.org/improving-tors-anonymity-changing-guard-parameters
> https://trac.torproject.org/projects/tor/ticket/12206
>
> We made this change primarily to limit points of observability of entry
> into the Tor network for clients and onion services, as well as to
> reduce the ability of an adversary to track clients as they move from
> one internet connection to another by their choice of guards.
>
> At the time, I was in favor of two entry guards but did not have a
> strong preference, and we ended up choosing one guard. After seeing
> various consequences of using only one entry guard, I think a much
> stronger case can now be made for bumping back up to two.
>

Hello Mike,

thanks for writing this post. Thinking about entry guards is extremely
important since guards and path selection is pretty much the whole
security of Tor.

However we should think hard here before flapping from one conf to
another.  In the grand scheme of things, I see the positives of moving
to two guards but also the positives of staying with one guard; I think
we need more data to decide what's best and for which threat models.

In general, the main argument for me to stay with one guard is to
minimize client exposure to guards over a period of time. If we choose
two guards instead of one, clients will expose themselves to double the
amount of guards over time (not to take into account flaky unreachable
guards). Perhaps we could compensate that by increasing the lifetime of
guards if we switch to two guards... I think simulations and graphs here
to show exposure of guards per number of guards would be useful, and we
have some of those already for prop247.

OTOH the main arguments for me to switch to two guards is not so much
security but performance improvements and reducing congestion of guard
nodes.

> Roger suggested that I enumerate the pros and cons of this increase on
> this mailing list, so we can discuss and consider this switch. So here
> is my attempt at that list. Let's start with a more in-depth recap of
> the one-guard arguments, along with some recent observations that change
> things.
>
>
> Arguments for staying with just one guard:
>
> 1. One guard means less observability.
>
> As Roger put it in the above blog post: "I think the analysis of the
> network-level adversary in Aaron's paper is the strongest argument for
> restricting the variety of Internet paths that traffic takes between the
> Tor client and the Tor network."
> http://freehaven.net/anonbib/#ccs2013-usersrouted
>
> Unfortunately, we have since learned that Tor's path selection has the
> effect of giving the adversary the ability to generate at least one
> additional observation path. We first became aware of this in
> https://trac.torproject.org/projects/tor/ticket/14917, where the change
> to one guard allowed an adversary to discover your guard by choosing it
> as a rendezvous point and observing the circuit failure. After the fix
> for #14917, the onion service will build a connection to a second guard
> that it keeps in reserve. By using this attack (as well as a similar but
> more involved attack with unique exit policies and carefully chosen /16
> exit node subnets), the adversary can force clients to be observed over
> two paths whenever they like.
>
> So while we may get benefit for moving from three guards to two guards,
> we don't get much (or any) benefit from moving to two guards to one
> guard against an active adversary that either connects to onion
> services, or serves content to clients and runs exits.
>

Hmm, that's a fair point. However, the fact that this behavior exists
currently does not mean that it's the best we can do with what we have.

Example of what we can do to stop this bad behavior: instead of using
our second guard when our "exit" conflicts with our first guard like
this: [G2 -> M1 -> G1], we could instead make a 4-hop circuit as
follows: [G1 -> M1 -> M2 -> G2]. This would stop us from using our
second guard and would hide the obvious signal you are worrying about.
(I see that dgoulet also suggested that in the ticket comment:7)

> 2. Guard fingerprintability is lower with one guard
>
> An adversary who is watching netflow connection records for an entire
> area is able to track users as they move from internet connection to
> internet connection through the degree of uniqueness of their guard
> choice. There is much less information in two guards than three, but
> still significantly more than with one guard:
> https://trac.torproject.org/projects/tor/ticket/9273#comment:3
>
> But, even with one guard, if there are not very many Tor users in your
> area, you still may be trackable. "Guard bucket" designs are discussed
> on the blog post and in related tickets, but they are complicated and
> involve tricky tradeoffs (see
>