Re: [qubes-users] Multiple TorVMs?

[Axon]

Axon:
> Just something I'm curious about: Is there any use case for having
> multiple TorVMs? Anyone out there currently doing this?
>
> I think the default stream isolation settings probably mean it is
> useless to have multiple TorVMs, but I'd rather ask than merely assume,
> in case there's some advantage I haven't considered.
>

https://lists.torproject.org/pipermail/tor-talk/2014-February/032166.html

> Rusty Bird:
>> Patrick Schleizer:
>>> The problem is, any Whonix-Workstation behind Whonix-Gateway -
>>> once compromised - can claim to be another Whonix-Workstation,
>>> thus not being stream isolated anymore.
>>>
>>> This could be solved, when there was a defense, that prevented
>>> impersonating other workstations. VPN and/or Static ARP entries
>>> and/or OpenSSH could be used for that purpose.
>>
>> (How) does Qubes deal with this?
>
> Last time I checked, it it did not. (Apart from the workaround of
> using a separate Tor-VM per workstation.)
>

When you say "workstation" are you referring to a physical machine
running Qubes or a virtual AppVM? If you mean the latter, then perhaps
the answer to my original query above is in fact "Yes."

> I guess they'd be also interested to discuss your new concept on their
> qubes-devel mailing list.

[Patrick Schleizer]

Axon:

>> Rusty Bird:
>>> Patrick Schleizer:
>>>> The problem is, any Whonix-Workstation behind Whonix-Gateway -
>>>> once compromised - can claim to be another Whonix-Workstation,
>>>> thus not being stream isolated anymore.
>>>>
>>>> This could be solved, when there was a defense, that prevented
>>>> impersonating other workstations. VPN and/or Static ARP entries
>>>> and/or OpenSSH could be used for that purpose.
>>>
>>> (How) does Qubes deal with this?
>>
>> Last time I checked, it it did not. (Apart from the workaround of
>> using a separate Tor-VM per workstation.)
>>
>
> When you say "workstation" are you referring to a physical machine
> running Qubes or a virtual AppVM?

I usually define Workstation and Gateway in context of Tor anonymity
systems like this:

- The Workstation is the place where the browser, IRC client and so on
is running.
- The Gateway is the place where Tor and the firewall is running.

Therefore a Workstation could be both. A physically machine behind a
Gateway or an App/Disp-VM behind a QubesOS TorVM.

[Axon]

Patrick Schleizer:

OK, but in the context of Qubes, the user should *always* be using some
kind of VM for user-level tasks (which of course includes all Torified
web browsing). So, are you saying (in the quotation above from your
tor-talk discussion) that there is a way for a compromised Qubes AnonVM
to impersonate another AnonVM to the TorVM? And that this can be
prevented by having a separate TorVM for each AnonVM? Because, if so,
then this is a very big deal. As I said in the other thread, it is
pretty trivial to set up a separate TorVM for each AnonVM, but I think
everyone around here has been assuming that there would be no reason to
do so. (Note the lack of response to my query.[1]) Now it sounds like
you are suggesting that there is a a *huge* reason to do so and that
probably every QubesTor user should be doing it. Is that the case?

[1]https://groups.google.com/d/topic/qubes-users/RcLtNi4Xwyw/discussion

[Patrick Schleizer]

Axon:

Yes.

> So, are you saying (in the quotation above from your
> tor-talk discussion) that there is a way for a compromised Qubes AnonVM
> to impersonate another AnonVM to the TorVM?

Yes. As long as there isn't any ARP Spoofing defense and/or
authentication (ssh and/or vpn) between AnonVMs to TorVM, any AnonVM can
impersonate another AnonVM since it is trivial to spoof IP addresses in
local LAN. And as I understand, connections between AnonVMs and TorVM is
just a LAN connection without any authentication. At least last time I
checked. Perhaps I am missing something in the QubesOS design. In that
case, I'd be happy to be educated.

> And that this can be
> prevented by having a separate TorVM for each AnonVM?

Probably yes, since different TorVMs aren't in the same subnet? Two
different TorVMs cannot access each other?

> Because, if so,
> then this is a very big deal. As I said in the other thread, it is
> pretty trivial to set up a separate TorVM for each AnonVM, but I think
> everyone around here has been assuming that there would be no reason to
> do so. (Note the lack of response to my query.[1])

> Now it sounds like
> you are suggesting that there is a a *huge* reason to do so and that
> probably every QubesTor user should be doing it. Is that the case?

While the current situation is non-ideal, I am not sure suggesting to
use using multiple TorVMs always is a good idea. At least not in their
current form.

Last time I checked, TorVM didn't use persistent Tor entry guards
(persistent Tor data directory), which I consider a much bigger issue.

The rest of my answer has been written under the assumption that QubesOS
TorVM will use persistent Tor entry guards in future...

Using an amount of x TorVMs would leak to ISP level adversaries, that
you are using an amount of X TorVMs, since they'll most likely choose
different Tor entry guards. Worse, you wouldn't really make use of the
security concept behind entry guards, since you're using more entry
guards than the typical TBB user. (In future TBB gets its own updater,
hence entry guards can be used for a longer time; plus Tor developers
are discussing to raise sticking with the same guard for ~9 months.)
(Being not different from a large group of users [TBB users] always is a
worthy goal in anonymity.)

Ideally, different TorVMs would use the same set of entry guards. I am
not aware how to configure Tor this way. (Other than copying it's data
directory, which will only work as long as these entry guards aren't
automatically replaced.) It has been suggested to implement a codeword
that the user can pick to let Tor default to the same set of entry
guards. [2] No work has been done on that yet and none is on the
horizon, I think.

Instead of using different TorVMs, perhaps it would be worth to
implement authentication between AnonVMs and TorVM. Circumvention of
stream isolation by compromised AnonVMs would then no longer be
possible. (Tor isolates streams from different [local] IP addresses by
default.)

This needs more thought, since denial-of-service attacks would still be
possible. A compromised AnonVM behind the same TorVM could still could
still cause so much network load, that other AnonVMs internet would be
virtually unusable. I am not sure, if an induced stress level in one
compromised AnonVM (causing network traffic) could again violate stream
isolation by sometimes causing lots of network traffic vs no network
traffic. Eventually such "morse codes" would be detectable by exit nodes
and/or ISP's of exit nodes.

As a defense, limiting network bandwidth and also hdd and cpu usage per
AnonVM could be limited. Does QubesOS support imposing such limits already?

> [1]https://groups.google.com/d/topic/qubes-users/RcLtNi4Xwyw/discussion

[2] https://trac.torproject.org/projects/tor/ticket/2653

[Axon]

Patrick Schleizer:

Sorry if this is a stupid question, but: How hard would it be to make
TorVM use persistent entry guards? Would it just be as simple as making
TorVM a StandaloneVM rather than an AppVM? (If so, then the "fix" is as
simple as changing the user docs a bit.)

[Axon]

Axon:

I meant "Template-based VM" rather than "AppVM." (TorVM is techincally a
"ProxyVM," not an "AppVM," in Qubes terminology.)

[Axon]

Patrick Schleizer:

Per your own question[3], whether using persistent entry guards is a
good idea probably depends on one's threat model and usage pattern,
right? Someone who takes their Qubes laptop to different locations and
connects to different internet access points (home, work, airport wi-fi,
hotel wi-fi) may actually be harmed by using persistent entry guards
rather than sticking with the way TorVM currently works. Is that right?

> Using an amount of x TorVMs would leak to ISP level adversaries, that
> you are using an amount of X TorVMs, since they'll most likely choose
> different Tor entry guards.

Is this necessarily so bad? Maybe for some users, but I would think that
other users might be in a position where they (reasonably) don't care if
ISP level adversaries know that they're using X number of TorVMs, as
long as that's all they know. It seems roughly the same as if X number
of people were all using Tor independently from the same external IP
address.

> Worse, you wouldn't really make use of the
> security concept behind entry guards, since you're using more entry
> guards than the typical TBB user.

Well, it's actually just that there are X sets of entry guards being
used from your external IP address, right? There's no basis to assume
that a given external IP address == a single Tor user. There are lots of
situations in which many people with the same external IP address might
be using Tor independently without each other knowing. Like I said
above, if this is the same as if X number of people were using Tor
independently from the same external IP address, then that doesn't seem
so bad. In fact, it seems suitable if you want to have a different TorVM
for a each distinct pseudonym.

[3]https://tor.stackexchange.com/questions/698/tracking-user-location-using-entry-guards

[Patrick Schleizer]

Axon:
>> Patrick Schleizer:

>> Last time I checked, TorVM didn't use persistent Tor entry guards
>> (persistent Tor data directory), which I consider a much bigger issue.
>>
> Sorry if this is a stupid question, but: How hard would it be to make
> TorVM use persistent entry guards? Would it just be as simple as making
> TorVM a StandaloneVM rather than an AppVM? (If so, then the "fix" is as
> simple as changing the user docs a bit.)

No need to be sorry. And sorry, if this is a stupid answer. ;) You
"only" need to make Tor's data directory persistent. Or make the whole
VM persistent. No idea how technically difficult this is within QubesOS
/ TorVM. Perhaps not that simple, since the original TorVM author had it
on its todo list but never got to it?

[Patrick Schleizer]

Axon:

At the moment, maybe. Having this well understood and documented,
providing an option for either way would be ideal.

In future, as I followed Tor dev discussions a bit, they may reduce the
number of entry guards to 1.

> Someone who takes their Qubes laptop to different locations and
> connects to different internet access points (home, work, airport wi-fi,
> hotel wi-fi) may actually be harmed by using persistent entry guards
> rather than sticking with the way TorVM currently works. Is that right?

Maybe. I am not sure anyone has good answers to that yet. I suggest to
rephrase this question as being non-Qubes related on tor-talk mailing
list to get more insights.

Perhaps this will help:
https://tor.stackexchange.com/questions/698/tracking-user-location-using-entry-guards

>> Using an amount of x TorVMs would leak to ISP level adversaries, that
>> you are using an amount of X TorVMs, since they'll most likely choose
>> different Tor entry guards.
>
> Is this necessarily so bad? Maybe for some users, but I would think that
> other users might be in a position where they (reasonably) don't care if
> ISP level adversaries know that they're using X number of TorVMs, as
> long as that's all they know. It seems roughly the same as if X number
> of people were all using Tor independently from the same external IP
> address.

Anonymity loves company.
(http://freehaven.net/anonbib/cache/usability:weis2006.pdf)

You're either the one "that looks like TBB", one among many thousands of
TBB users or you're one of fewer pepole who "probably use multiple
TorVMs", which lets you stand out. Sure, it's not fatal, it's just one
additional bit of information that shouldn't unnecessarily leak. For
example, when looking for the one who hosts hidden services, you can
skip those who most likely use TBB and look into more closely into TorVM
users.

>> Worse, you wouldn't really make use of the
>> security concept behind entry guards, since you're using more entry
>> guards than the typical TBB user.
>
> Well, it's actually just that there are X sets of entry guards being
> used from your external IP address, right? There's no basis to assume
> that a given external IP address == a single Tor user. There are lots of
> situations in which many people with the same external IP address might
> be using Tor independently without each other knowing. Like I said
> above, if this is the same as if X number of people were using Tor
> independently from the same external IP address, then that doesn't seem
> so bad. In fact, it seems suitable if you want to have a different TorVM
> for a each distinct pseudonym.

Entry guards are a security feature.
(https://www.torproject.org/docs/faq#EntryGuards)

Picking a malicious one can harm your anonymity.

Briefly: When you choose x of y available relays as entry guard, you
have a chance of z to pick a malicious one. As Tor devs are discussing
in the blog post I liked last time, to further improve this situation,
they might in future just pick one entry guards and keep it for a long
time (~9 months). They believe, that using fewer ones and taking them
for a longer period will result in a lower probability of choosing a
malicious one.

So far as I understand the theory. Their concept might be flawed. Or
not. It's a open research question they say. Perhaps depending on ones
threat model. One way or the other, my point isn't to discuss optimal
entry guard rotation parameter here. I am not qualified for that. In
that regard, I must trust the Tor developers to make the best decision.

For the sake of our discussion here, I assume you do the same and trust
the Tor developers to make the best decision here. Feel free to dispute
it with them, but then what I will write below won't apply anymore.

Under the assumption, the we agree "using multiple entry guards is bad"
("because Tor devs think so"), using multiple TorVMs won't honor their
advice. Hence, I raised this point.

[Axon]

Patrick Schleizer:

Yes, after I corrected myself about the AppVM/ProxyVM thing, I realize
that it might well be more complicated than I had previously thought.
Perhaps someone who knows will chime in.

[Axon]

I actually just cited that very same link in the paragraph you're
replying to. It's reference "[3]". In fact, that question of yours is
what prompted my question above (hence why I began, "Per your own
question[3]...").

But I appreciate your clarifying that it is currently an open question.
I take this to mean that the current TorVM implementation is not
obviously flawed.

>>> Using an amount of x TorVMs would leak to ISP level adversaries, that
>>> you are using an amount of X TorVMs, since they'll most likely choose
>>> different Tor entry guards.
>>
>> Is this necessarily so bad? Maybe for some users, but I would think that
>> other users might be in a position where they (reasonably) don't care if
>> ISP level adversaries know that they're using X number of TorVMs, as
>> long as that's all they know. It seems roughly the same as if X number
>> of people were all using Tor independently from the same external IP
>> address.
>
> Anonymity loves company.
> (http://freehaven.net/anonbib/cache/usability:weis2006.pdf)
>
> You're either the one "that looks like TBB", one among many thousands of
> TBB users or you're one of fewer pepole who "probably use multiple
> TorVMs", which lets you stand out. Sure, it's not fatal, it's just one
> additional bit of information that shouldn't unnecessarily leak. For
> example, when looking for the one who hosts hidden services, you can
> skip those who most likely use TBB and look into more closely into TorVM
> users.
>

Hm... I don't think we're on the same page. I am confused by the fact
that you seem to be assuming that TBB and TorVM are incompatible (they
are not). But perhaps it is I who am missing something. Let's try this:

Suppose I have X number of TorVMs and the same X number of AnonVMs
(connected 1:1). In each AnonVM, I run an instance of TBB (with the
Transparent Torification option enabled).

- If X = 1, then in what sense am I distinguishable from a regular TBB
user?
- If X > 1, then in what sense am I distinguishable from X number of
regular TBB users sharing a single internet connection?

I think we may be talking past each other here. My point is not to
dispute that each individual Tor user should be using the correct number
of entry guards (where the "correct" number is whatever the Tor devs
says it is). Rather, my point is to challenge the notion of an
"individual Tor user." Qubes is all about challenging the notion of "one
user = one computer." In the same way, I am suggesting that having
multiple TorVMs is equivalent to having multiple individual Tor users.
If there is nothing particularly wrong with having multiple individual
Tor users who happen to share an internet connection (as might be the
case in an internet cafe, apartment building, or large household, for
example) then there should be nothing particularly wrong with having
multiple TorVMs which "happen" to share an internet connection.

Another way to look at it is this: Suppose you have X number of distinct
pseudonyms. How is anyone going to know that they're all controlled by
you, rather than being different people who happen to share an internet
connection with you?

[Patrick Schleizer]

Since TorVM is non-persistent, Tor's must create a fresh data directory
every time TorVM is restarted (always choose new entry guard). Same
situation as it is still in Tails and perhaps other Tor Live DVDs.
(Tails devs have a todo item to do something about this.) This is not
what Tor devs suppose for most users (stick with entry guard). Hence, I
think, the current TorVM implementation has a flaw.

>>>> Using an amount of x TorVMs would leak to ISP level adversaries, that
>>>> you are using an amount of X TorVMs, since they'll most likely choose
>>>> different Tor entry guards.
>>>
>>> Is this necessarily so bad? Maybe for some users, but I would think that
>>> other users might be in a position where they (reasonably) don't care if
>>> ISP level adversaries know that they're using X number of TorVMs, as
>>> long as that's all they know. It seems roughly the same as if X number
>>> of people were all using Tor independently from the same external IP
>>> address.
>>
>> Anonymity loves company.
>> (http://freehaven.net/anonbib/cache/usability:weis2006.pdf)
>>
>> You're either the one "that looks like TBB", one among many thousands of
>> TBB users or you're one of fewer pepole who "probably use multiple
>> TorVMs", which lets you stand out. Sure, it's not fatal, it's just one
>> additional bit of information that shouldn't unnecessarily leak. For
>> example, when looking for the one who hosts hidden services, you can
>> skip those who most likely use TBB and look into more closely into TorVM
>> users.
>>
>
> Hm... I don't think we're on the same page. I am confused by the fact
> that you seem to be assuming that TBB and TorVM are incompatible (they
> are not). But perhaps it is I who am missing something. Let's try this:

I didn't assume TBB and TorVM are incompatible.

> Suppose I have X number of TorVMs and the same X number of AnonVMs
> (connected 1:1). In each AnonVM, I run an instance of TBB (with the
> Transparent Torification option enabled).
>
> - If X = 1, then in what sense am I distinguishable from a regular TBB
> user?

Distinguishable at ISP level. TorVM does not use persistent entry
guards, TBB does.

> - If X > 1, then in what sense am I distinguishable from X number of
> regular TBB users sharing a single internet connection?

Distinguishable at ISP level. TorVM does not use persistent entry
guards, TBB does. Apparently really seldom someone re-uses its entry guards.

I would assume, that a big share of Qubes OS and/or TorVM users, is
using it from home and/or office. A smaller percentage is using it on
the go, from changing spots. Rather, I think it is safe to assume, that
data ISP's are snooping is corelated with local residents' registration
office, tax office, rental contracts, mobile phone location tracking
data, and so forth. Safe to assume, the adversary knows if the internet
access point is a general meeting point or private flat. Simple for
adversaries to assume then, that one is using non-persistent entry
guards. Again, you want to be in the seemingly biggest group of
"probably a TBB user" rather than "maybe a TorVM user", because the
latter group is more susceptible to run other applications than TBB or
hosting hidden services.

The last paragraph I wrote above also applies here. Adversaries who
correlate data the ISP is snooping with other authorities isn't easily
tricked and usually known how many people usually are in a location.

> Another way to look at it is this: Suppose you have X number of distinct
> pseudonyms. How is anyone going to know that they're all controlled by
> you, rather than being different people who happen to share an internet
> connection with you?

When TorVM with set of entry guards a is online, this fact is logged.
When pseudonym b is active (in a public forum or so), this fact is
logged. Same goes for set of entry guards c and pseudonym d. Adversaries
can attempt to correlate such logs. They don't need a proof, only to
make the circle of suspects smaller and investigate further with
ordinary means from there. I think, if you are using the same set of
entry guards for all your pseudonyms you're better off.

[Axon]

But as you just admitted, the ultimate benefit of entry guard
persistence is unknown. It may help some users, and it may harm others.
It's a controversial issue. Even Roger readily admits that the entry
guard solution isn't very satisfying.[4]

We also have to remember that there's a tradeoff being made in the case
of Tails and Qubes TorVM. In both cases, you give up persistent entry
guards, but you gain something in return. With Tails, you gain "amnesia"
among other things. With TorVM, you gain strong isolation (and also
"amnesia," but to a lesser extent than with Tails).

IMO, at present, the bigger, more likely threat to Tor users is being
attacked with an exploit rather than being passively profiled. The
recent NSA revelations certainly support this, as do Roger's
comments.[4] Knowing this, if you had to choose, it would be logical to
choose the isolation provided by TorVM, even if that means giving up the
(controversial) benefits of entry guard persistence.

But, of course, I agree with you that anonymity will invariably be
harmed by looking different from everyone else (where "everyone else" is
assumed to be using plain TBB). So, even if it turns out that persistent
entry guards aren't a good idea for a particular user, that user may be
better served by jumping on the bandwagon anyway. In that sense, the
best thing for Qubes would be to combine isolation with persistent entry
guards. Does Whonix do this? Perhaps QubesWhonix is what we really need. :)

[4]https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-parameters

[Patrick Schleizer]

Well, when you begin to question my assumption "TBB uses entry guards,
Tor devs did that, must be good, let's better do as TBB does", my
argument breaks down. It really only makes sense if you grant me that.
Only under that assumption, what I say can be true. I think this isn't
the right place to discuss this assumption. Mixing up topics. And I am
not the right one to defend "pro entry guards" standpoint.

> But, of course, I agree with you that anonymity will invariably be
> harmed by looking different from everyone else (where "everyone else" is
> assumed to be using plain TBB). So, even if it turns out that persistent
> entry guards aren't a good idea for a particular user, that user may be
> better served by jumping on the bandwagon anyway.

> In that sense, the
> best thing for Qubes would be to combine isolation with persistent entry
> guards.

Yes. I think:
- current situation, non-persistent entry guards: least ideal
- persistent entry guards: ok
- documentation and option to easily choose between non- and persistent
entry guards: ideal

> Does Whonix do this?

Whonix uses persistent entry guards. After this discussion I realize we
should add documentation for when using entry guards may be non-ideal
and how to do that.

> Perhaps QubesWhonix is what we really need. :)

Many pieces of Whonix would make sense to be included in TorVM. It would
be better if Whonix's improvements were split into smaller packages, so
they can be easier understood and ported elsewhere, even be uploaded to
Debian/Fedora. I also plan to port Whonix to QubesOS, but other tasks
got into the way, so better don't hold your breath.

[Marek Marczykowski-Górecki]

I hope you are missing something ;)
The current implementation uses per-VM interface, so any ProxyVM (like
firewallvm or torvm) have separate interface for each VM connected to it. Then
there are iptables rules guarding against IP spoofing.

For example:
[user@firewallvm ~]$ ifconfig | grep vif
vif13.0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
vif26.0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
vif39.0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
(...)

[user@firewallvm ~]$ ip r
(...)
10.137.2.25 dev vif26.0 scope link metric 32726
10.138.2.3 dev vif13.0 scope link metric 32739
10.138.2.8 dev vif39.0 scope link metric 32713
(...)

[user@firewallvm ~]$ sudo iptables -t raw -nvL
Chain PREROUTING (policy ACCEPT 1520K packets, 558M bytes)
target prot opt in out source destination
(...)
DROP all -- vif39.0 * !10.138.2.8 0.0.0.0/0
DROP all -- vif26.0 * !10.137.2.25 0.0.0.0/0
DROP all -- vif13.0 * !10.138.2.3 0.0.0.0/0
(...)

Not sure if this makes this discussion void - perhaps there are some other
(application level?) attacks against common TorVM...

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Axon]

I'm beginning to wonder whether a good solution to the entry guard
problem for TorVM users might be to use plain TBB in an AnonVM *without*
the Transparent Torification option selected *for now*. I know that you
wrote the FAQ entry against running Tor over Tor.[5] However, I think it
is telling that Roger wrote that running Tor over Tor is recommended
against "mainly because we're likely to make it fail to work at some
point in the future (#2667)."[6] In other words, the main reason not to
use Tor over Tor has nothing to do with security or anonymity, but
merely with forward compatibility. Until the time comes when Tor over
Tor doesn't work anymore (and that may be a long time, or never, from
the looks of the ticket discussion[7]), Qubes users might get the best
of both worlds by running unmodified TBB behind a TorVM. If the AnonVM
gets profiled by a bad entry node (which is more likely, since they're
not persistent), it just gets traffic coming from some exit node, rather
than from the user's real IP. Although the number of entry nodes used in
this setup is increased (which also increases the chance of getting a
bad entry node), the three selected by TBB remain persistent, so the
increase over regular TorVM usage is minuscule. Finally, as before, if
TBB gets exploited, no real IP is leaked, since all traffic is
transparently Torified.

The major risk with this approach (IIUC) is that when running Tor over
Tor, each instance of Tor selects its own path separately, so there's a
chance that your entry node (node 1 of 6) happens to be the same as your
exit node (node 6 of 6),[8] but this seems highly improbable given the
sheer number of nodes there are coupled with the fact that your entry
nodes will be persistent. The important thing is to determine whether
the probability of this happening is higher or lower than the
probability of being profiled successfully while using regular TorVM. I
suspect that the latter is significantly higher.

But, as always, I welcome being corrected.

[5]https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO#ToroverTor
[6]https://trac.torproject.org/projects/tor/ticket/5611#comment:2
[7]https://trac.torproject.org/projects/tor/ticket/2667
[8]This is of course different from the risk that your entry and exit
nodes will be distinct nodes which happen to be controlled by the same
(malicious) entity, which is also a risk even with regular TBB (and this
is exactly what entry guards are intended to make less likely).

[Patrick Schleizer]

I don't think so as long as Tor over Tor isn't well understood.

Also I don't see how this takes advantage of persistent entry guards.
The first one that establishes a connection is still TorVM. And TorVM
will always take another entry guard.

Connections schema:
user -> entry-guard-TorVM(non-persistent)[1] -> middle-relay-TorVM[2]
-> exit-relay-TorVM[3] -> entry-guard-TBB(persistent)[4] ->
middle-relay-TBB[5] -> exit-relay-TBB[6]

I am not sure, if you're picking a good one (assumption: having a good
chance to pick a good one) at [4] can act as substitute for the for
the bad one (assumption: having good chance to pick a bad one) chosen
at [1].

I've read somewhere "your ISP is a permanent and can be an evil entry
guard as well". If that is true, then [1] should be regarded to
function similarly to an ISP.

> I know that you wrote the FAQ entry against running Tor over
> Tor.[5] However, I think it is telling that Roger wrote that
> running Tor over Tor is recommended against "mainly because we're
> likely to make it fail to work at some point in the future
> (#2667)."[6] In other words, the main reason not to use Tor over
> Tor has nothing to do with security or anonymity, but merely with
> forward compatibility.

The question is, what did he mean by "mainly" which limits his
original sentence (he could have dropped the "mainly") to say
something else.

From my reading of lots of papers from anonbib
(http://freehaven.net/anonbib/), I conclude that things are often more
nuanced than thought at first and that doing non-standard things is
often a bad idea. Since it look like that no one researched that
anonymity impliications of Tor over Tor yet... Before making this
default for lots of Qubes users, I advise to raise this topic on the
tor-talk mailing list where other Tor knowledgeable people can state
their thoughts.

> Until the time comes when Tor over Tor doesn't work anymore (and
> that may be a long time, or never, from the looks of the ticket
> discussion[7]), Qubes users might get the best of both worlds by
> running unmodified TBB behind a TorVM. If the AnonVM gets profiled
> by a bad entry node (which is more likely, since they're not
> persistent), it just gets traffic coming from some exit node,
> rather than from the user's real IP. Although the number of entry
> nodes used in this setup is increased (which also increases the
> chance of getting a bad entry node), the three selected by TBB
> remain persistent, so the increase over regular TorVM usage is
> minuscule. Finally, as before, if TBB gets exploited, no real IP is
> leaked, since all traffic is transparently Torified.

I am not sure. Tor over Tor also means lower throughput, even higher
pings, more connection interruptions. This is clearly bad for
usability reasons. Rather I would be interested, if Tor exit nodes or
destination servers could conclude from throughput/ping, "most likely
a Tor over Tor user".

> The major risk with this approach (IIUC) is that when running Tor
> over Tor, each instance of Tor selects its own path separately, so
> there's a chance that your entry node (node 1 of 6) happens to be
> the same as your exit node (node 6 of 6),[8] but this seems highly
> improbable given the sheer number of nodes there are coupled with
> the fact that your entry nodes will be persistent.

There are not that many Tor exists. You often get the same one. Also
there are not that many Tor entry guards. The risk increases with the
number of users. I wouldn't risk that.

> The important thing is to determine whether the probability of this
> happening is higher or lower than the probability of being profiled
> successfully while using regular TorVM. I suspect that the latter
> is significantly higher.

In other words, if I understand right, you're asking...
"Is it more probable by not-using persistent entry guards to pick a
malicious entry guard and be deanonymized by that or is it more
probable to pick the same Tor relay as your entry guard and your exit
relay and be deanonymized by that?"

I am intrigued by the complexity of this question and don't think
anyone can answer this without some math and research. My advice is to
avoid this question by not having to choose between those.

[Abel Luck]

On Wednesday 26 February 2014 10:53:01 Patrick Schleizer wrote:
> Since TorVM is non-persistent, Tor's must create a fresh data directory
> every time TorVM is restarted (always choose new entry guard). Same
> situation as it is still in Tails and perhaps other Tor Live DVDs.
> (Tails devs have a todo item to do something about this.) This is not
> what Tor devs suppose for most users (stick with entry guard). Hence, I
> think, the current TorVM implementation has a flaw.

This is incorrect. qubes-tor has used a persistent data directory for over a
year since v0.1 [1] The first 0.1betas didn't persist the data directory, but I
think I was the only one ever to use those versions.

Going back to the original topic of this thread: should multiple TorVMs be
used per-appvm due to impersonation concerns (ip spoofing, etc).

IMHO, this isn't an issue or bug for qubes-or, rather it is a larger
networking issue for Qubes as a whole.

Given the expected one-TorVM to many-AppVMs scenario where one AppVM is
compromised, spoofing/impersonation may result, but [psuedo|ano]nymity isn't
lost because the TorVM isn't compromised.

But the consequences of compromise in an AppVM applies equally to the one-
FirewallVM to many-AppVMs scenario: AppVMs can spoof eachother.

HOWEVER: this is all irrelevant because spoofing isn't possible. See Marek's
reply to this thread in Feburary:

"The current implementation uses per-VM interface, so any ProxyVM (like
firewallvm or torvm) have separate interface for each VM connected to it. Then

there are iptables rules guarding against IP spoofing." [2]

So, given these two important facts:

1) AppVMs can't spoof eachother in Qubes' network
corollary: stream isolation can't be circumvented
2) TorVM has a persistent data directory

I'm not sure why running multiple TorVMs would ever be needed, unless using
persistent entry guards is considered harmful, which it sounds like it may be
in some usecases. Yet the solution is to change TorVMs use of entry guards,
not run more TorVMs.

~abel

[1]: http://git.qubes-os.org/?p=joanna/qubes-app-linux-tor.git;a=commit;h=eb47d510d6418db4d5349432422cdbd6c56fbaab
[2]: https://groups.google.com/d/msg/qubes-devel/le7-Rrq6yxY/k_fQdSTzvLAJ

[Axon]

(See reply below.)

(Note: My replies take into account the revelation that TorVM does, in
fact, use persistent entry guards. They also take into account the
subsequent thread on this topic.[4])

I suspect that this is a moot point since Qubes doesn't support the
anonymized downloading and updating of packages (including the qubes-tor
package itself). I will clarify what I mean, but first, please allow me
to recap your basic argument, Patrick. (Please correct me if I get it
wrong.)

Axon's recap of Patrick's argument:
> All else being equal, it is better (i.e., safer with respect to
> anonymity) to look like a regular TBB user than to look like
> something different (e.g., a TorVM user). Using just one TorVM allows
> you to look the same as regular TBB users, which is good. However,
> using multiple TorVMs makes you look different from regular TBB users
> to ISP-level adversaries, since they can see that you use multiple
> different sets of entry guards (one per TorVM), whereas a regular TBB
> user uses only one set of entry guards. Therefore, Qubes users should
> use just one TorVM rather than multiple TorVMs.

This is a very reasonable argument, but it doesn't apply to Qubes due to
the simple fact that ISP-level adversaries *already* know you're a TorVM
user (and therefore different from regular TBB users) because they can
see your downloads/updates of the qubes-tor package! The exception to
this is, of course, if you mask your download of the qubes-tor package
in some way, e.g., by downloading it over Tor. However, since doing
Qubes updates over Tor is very difficult and not supported,[5] we can
safely assume that almost every Qubes user does not currently do this.
(Depending on how serious this is (see below), this may be a place where
Whonix has a noteworthy advantage over Qubes+TorVM.)

>> Another way to look at it is this: Suppose you have X number of distinct
>> pseudonyms. How is anyone going to know that they're all controlled by
>> you, rather than being different people who happen to share an internet
>> connection with you?
>
> When TorVM with set of entry guards a is online, this fact is logged.
> When pseudonym b is active (in a public forum or so), this fact is
> logged. Same goes for set of entry guards c and pseudonym d. Adversaries
> can attempt to correlate such logs. They don't need a proof, only to
> make the circle of suspects smaller and investigate further with
> ordinary means from there. I think, if you are using the same set of
> entry guards for all your pseudonyms you're better off.
>

OK, let's flesh out your example. Suppose I have three TorVMs connected
to three pseudonyms:

TorVM[a]---Pseudonym[A]
TorVM[b]---Pseudonym[B]
TorVM[c]---Pseudonym[C]

The following facts are then logged whenever they occur:
- [a] is online.
- [A] is active (e.g., in a public forum).
- [b] is online.
- [B] is active (e.g., browsing a website).
- [c] is online.
- [C] is active (e.g., sending an email).

Adversaries can then attempt to correlate these logs. They can correlate
[a] with [A], [b] with [B], and [c] with [C]. (Let's assume I don't
consistently start/stop usage of any pair at the same time as any other
pair.)

But how is this any different from the risk that *every* Tor user faces?

Even if I decided to use plain vanilla TBB with one pseudonym, I would
face the same risk, namely that my entry traffic log gets correlated
with my exit traffic log. The only difference in the case of multiple
TorVMs is that my real identity is associated with multiple sets of
entry traffic logs (i.e., multiple sets of entry guards). But that, by
itself, does not make it any easier for my adversary to succeed in
correlating my entry traffic with my exit traffic. In pictorial terms:


/---[TorVM]---Pseudonym1 (TorBrowser user)
Real Identity--------|----[TorVM]---Pseudonym2 (TorBrowser user)
(multi-TorVM user) \---[TorVM]---Pseudonym3 (TorBrowser user)


My ISP (and everyone else who can see my traffic as it enters the Tor
network) can see that I'm a multi-TorVM user. However, in my AnonVMs, I
use TorBrowser (with Transparent Torification), so my exit node (and
everyone else who can see my traffic as it leaves the Tor network) just
sees another TorBrowser user.

Once again, an adversary can unmask me if he can successfully correlate
my entry traffic with my exit traffic, but the same goes for every other
plain vanilla TBB user. So nothing is lost by using multiple TorVMs.


What do you think, Patrick? Have I correctly understood your argument?
Do you (or anyone reading this) see any flaws in my reasoning?

[4]https://groups.google.com/d/topic/qubes-users/xWAO3WpXn9k/discussion
[5]https://groups.google.com/d/topic/qubes-users/9gf2rhkJfPc/discussion