Torless TBB

[Axon]

Hi Abel,

Quick question, if you don't mind:

In your Torless TBB launcher script for use with Qubes' transparent Tor
proxy, TOR_SOCKS_HOST=10.137.3.1. Is this supposed to be the same for
all Qubes machines regardless of how many ProxyVMs users have created
(or other user settings)? Or is the user supposed to change this before
using the script?

[Hakisho Nukama]

> --
> You received this message because you are subscribed to the Google Groups
> "qubes-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to qubes-devel...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> Visit this group at http://groups.google.com/group/qubes-devel.
> For more options, visit https://groups.google.com/groups/opt_out.

Hi,

I think it is dependent on chronological order of ProxyVM creation.
Btw, would it be reasonable to change the IP of a VM from inside qubes-manager?

Best Regards,
Hakisho Nukama

[Axon]

On 08/31/13 08:26, Hakisho Nukama wrote:
> On Fri, Aug 30, 2013 at 12:51 PM, Axon <ax...@openmailbox.org> wrote:
>> Hi Abel,
>>
>> Quick question, if you don't mind:
>>
>> In your Torless TBB launcher script for use with Qubes' transparent Tor
>> proxy, TOR_SOCKS_HOST=10.137.3.1. Is this supposed to be the same for all
>> Qubes machines regardless of how many ProxyVMs users have created (or other
>> user settings)? Or is the user supposed to change this before using the
>> script?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "qubes-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to qubes-devel...@googlegroups.com.
>> To post to this group, send email to qubes...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/qubes-devel.
>> For more options, visit https://groups.google.com/groups/opt_out.
>
> Hi,
>
> I think it is dependent on chronological order of ProxyVM creation.

I suspect that 10.137.3.x is reserved for Tor or something, which is why
the script can (apparently) work on any arbitrary Qubes system. At
least, on my system, it looks like none of the other VMs (whether Proxy,
App, or Template) have a 10.137.3.x address. (Some were created before
the torvm, others after.) Can anyone (dis)confirm this?

> Btw, would it be reasonable to change the IP of a VM from inside qubes-manager?

You mean the graphical Qubes VM Manager? I don't see any way to change
the IP address of a VM in there.

>
> Best Regards,
> Hakisho Nukama
>

[Axon]

On 08/31/13 10:47, Hakisho Nukama wrote:

> I've several QubeOS installations, and the IP of my TorVMs differ.
> If this is due to order of creation I don't know, but it is likely.

Right, but 10.137.3.x might still be somehow reserved for Tor use. (My
torvm is does not have a 10.137.3.x address, but the script still works.)

>
>>> Btw, would it be reasonable to change the IP of a VM from inside
>>> qubes-manager?
>>
>>
>> You mean the graphical Qubes VM Manager? I don't see any way to change the
>> IP address of a VM in there.
>>
>

> Yes, there is none. But would it be reasonable to change it from there?

I don't know, sorry.

>
>>>
>>> Best Regards,
>>> Hakisho Nukama
>>>
>>
>>
>

[Marek Marczykowski-Górecki]

Don't know details but looks like TorVM IP (so you need to update it).

--
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]

On 08/31/13 14:43, Marek Marczykowski-Górecki wrote:
> On 30.08.2013 14:51, Axon wrote:
>> Hi Abel,
>>
>> Quick question, if you don't mind:
>>
>> In your Torless TBB launcher script for use with Qubes' transparent Tor proxy,
>> TOR_SOCKS_HOST=10.137.3.1. Is this supposed to be the same for all Qubes
>> machines regardless of how many ProxyVMs users have created (or other user
>> settings)? Or is the user supposed to change this before using the script?
>
> Don't know details but looks like TorVM IP (so you need to update it).
>

Hm, it doesn't seem to affect anything no matter what I change it to.
Even if I change it to some random number (in IP address format). Tor
still works, and I still look like I have the IP address of some Tor
exit node. What does this setting actually do, I wonder?

[Axon]

Something just occurred to me: If the IP address of the user-created
torvm is dependent on the chronological order of the creation of VMs,
then the IP address of the torvm is likely to be different for every
Qubes user, which means that entering this in the Torless TBB script
will make users highly fingerprintable, which defeats the whole purpose
of using the TBB browser (instead of vanilla Firefox) in the first
place. Right?

[Axon]

On 08/31/13 17:37, Hakisho Nukama wrote:

> Yepp, I also think that the fixed IP and hostname (for TorVM and AnonymVM),
> which may differ from install A to B could lead to an increase in uniqueness.
> Either set them globally for all Qubes user,
> to 'torvm -10.13.37.1' and 'anonym - 10.13.37.42',
> or find some other way to cloak this information.
>
> See my previous post on "TorVM implementation":
> https://groups.google.com/d/msg/qubes-devel/C1D5_tbl4jM/he3cra8oKk8J
>
> Best Regards,
> Hakisho Nukama
>

Well, the user might wish to create an arbitrary number of TorVMs or
AnonVMs, so I don't know if we can presuppose any fixed number or even
range of numbers. But I take your point.

Here's another potentially worrisome issue: In PV domains, it is
possible to see some hardware information. For example, CPU information
is clearly visible even from the GNOME system settings GUI. If an
adversary compromises an AnonVM (i.e., an AppVM which uses a TorVM as
its NetVM), then the adversary now knows the user's hardware profile in
addition to the fact that s/he is a Qubes user. Since the HCL reports
are publicly posted to this group and listed on the website, it would be
trivial to cross-reference the data to identify someone (or at least to
drastically narrow the search).

[Axon]

Update on this topic:

I'm now wondering whether it makes more sense to use Abel's custom
script or to follow the instructions here:
https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/WebBrowsers#TorBrowserbehindatransparentorisolatingproxy

The goal is to use TorBrowser in an AppVM, where the AppVM uses a TorVM
as its NetVM. The goal is to use TorBrowser in this way *without*
accidentally running Tor over Tor, as this may damage anonymity in ways
we do not understand and do not know how to measure.

The problem is that there are unanswered questions about how, exactly,
Abel's script works (see previous messages in thread) and virtually no
Tor documentation about how to correctly use "TOR_SOCKS_HOST".

[Axon]

After playing and testing a bit, I think these two approaches are
essentially the same.

The built-in TorButton Proxy settings should be:

[x] Use custom proxy settings
SOCKS Host: <IP address of your TorVM> Port: 9049 [same for all Qubes
installations?]

Everything else default.

Now, I'm guessing that Abel's script does the same thing like this:

TOR_SOCKS_HOST=10.137.3.1
TOR_SOCKS_PORT=9049

export TOR_SOCKS_HOST
export TOR_SOCKS_PORT

The problem is that 10.137.3.1 is probably not the IP address of your
TorVM, since it's different for every Qubes user (unless, of course, two
users happen to have the same IP for their TorVM by sheer chance). So
you have to change it manually.

(In addition, Abel's script sets the time zone to UTC and makes the
TorBrowser Firefox run as a separate process.)

Finally,

./tor-browser_en-US/App/Firefox/firefox -no-remote -profile
./tor-browser_en-US/Data/profile

is essentially accomplishing the same thing as changing

./App/vidalia --datadir Data/Vidalia/

to

./App/Firefox/firefox -profile ./Data/profile


So... if you've been using the script this whole time without changing
the TOR_SOCKS_HOST IP address, you've probably been running Tor over Tor...

This is just my best attempt to figure out what's going on, and I could
be totally wrong. Until (or unless) someone who actually knows about
this stuff sheds some light on it for the rest of us, I'm afraid the
safest thing for Qubes users to do might just be to forget about
TorBrowser and use vanilla Firefox. Unless, of course, you *need* your
browser to be less fingerprintable, in which case... you might have to
go with TAILS or Whonix for the time being. It really pains me to have
to say this, because I would really like to see *more* adoption of
TorBrowser, as that would benefit all of us, from an anonymity perspective.

[Axon]

Ah, I just found this email from almost exactly one year ago:
https://groups.google.com/d/msg/qubes-devel/dYNAdngHjt0/ZT5T2IcylGEJ

In it, Abel writes:

> On another note, my patches will support Tor connections three different
> ways:
>
> 1. Transparent TCP+DNS proxy (non-DNS UDP rejected)
> 2. SOCKS proxy on 9050, strict stream isolation settings, most
> anonymous, but lower performance
> 3. SOCKS proxy on 9049, less strict stream isolation, less anonymous,
> better performance

Assuming this is still true today, I suppose this means you could choose
either port 9049 or 9050 depending on your performance vs. anonymity needs.

[Axon]

OK, so this is already addressed on the wiki page under the
"Performance" heading:
http://qubes-os.org/trac/wiki/UserDoc/TorVM

However, note what it says: "SOCKS Port 9050 should be used by web
browsers."

SOCKS Port 9050, *not* SOCKS Port 9049! This makes it extremely puzzling
that the script uses SOCKS Port 9049!

Actually, this section of the page is not very clear:

> Port 9049 - Isolates destination port and address, and by SOCKS Auth
> Same as default settings listed above, but each app using a unique SOCKS user/pass gets its own circuit.

What default settings listed above? I don't see any "default settings
listed above" on this page. Do you?

> Port 9050 - Isolates by SOCKS Auth and client address only
> Each AppVM gets its own circuit, and each app using a unique SOCKS user/pass gets its own circuit

The second part of each sentence is the same: "each app using a unique
SOCKS user/pass gets its own circuit." So, the only difference is that
with Port 9050, each AppVM gets its own circuit? Is that actually
consistent with the email from a year ago?

[adre...@gmail.com]

Hi!

I've answered the question "How do I use Tor Browser with Qubes TorVM?" on the private Tor stackexchange beta:
http://tor.stackexchange.com/questions/29/how-do-i-use-tor-browser-with-qubes-torvm
My answer isn't public yet in stackexchange, probably soon. Anyhow, I am happy to share my answer with you by copying it in here.

This answer isn't perfect yet, but still better than nothing.

This answer mostly works for TBB 3.0 and above. (Currently the Alpha version of TBB.) Most of this solution is taken from Whonix's source code. It could be made to work with TBB 2.x (currently the stable version of TBB) as well, in that case get the modified Tor Browser start script (start-tor-browser) from Whonix 0.5.6 source code. (For TBB 2.x, see also [TorifyHOWTO/WebBrowsers](https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/WebBrowsers).) You can ask questions in the comments and I will improve this answer, if I can.

This is definitely doable and not rocket science. Also since TBB 3.0 works in Whonix out of the box. Download, [OpenPGP verification up to you], extract, run. No Tor over Tor. No modifications. (Because of environment variables and rinetd, see below.) So it might be useful to check out how it's done in Whonix. I try to summarize the relevant parts for you here...

Create a file /etc/profile.d/20_torbrowser.sh.

<pre>
## Deactivate tor-launcher,                                                                                                                                                        
## a Vidalia replacement as browser extension,                                                                                                                                     
## to prevent running Tor over Tor.                                                                                                                                                
## https://trac.torproject.org/projects/tor/ticket/6009                                                                                                                            
## https://gitweb.torproject.org/tor-launcher.git
export TOR_SKIP_LAUNCH=1

## The following TOR_SOCKS_HOST and TOR_SOCKS_PORT variables
## do not work flawlessly, due to an upstream bug in Tor Button:
##    "TOR_SOCKS_HOST, TOR_SOCKS_PORT regression"
##    https://trac.torproject.org/projects/tor/ticket/8336
## (As an alternative,
##    /home/user/tor-browser_en-US/Data/profile/user.js
## could be used.)
#export TOR_SOCKS_HOST="192.168.0.10"
#export TOR_SOCKS_PORT="9100"

## Something else to consider, but better don't use it, use proper stream isolation.
#export TOR_TRANSPROXY=1
</pre>

Reboot, so the environment variables takes effect.

Due to the [bug](https://trac.torproject.org/projects/tor/ticket/8336) changing Tor Browser's proxy settings with a script isn't as trivial as exporting the environment variables TOR_SOCKS_HOST and TOR_SOCKS_PORT. Either change the proxy settings in Tor Button (sorry, I don't know which IP/port the Qubes-Tor-Gateway is providing) or use rinetd.

Sample config for rinetd (you have to adjust IP's and ports, i.e. connectaddress and connectport):

<pre>
##
## this is the configuration file for rinetd, the internet redirection server
##
## you may specify global allow and deny rules here
## only ip addresses are matched, hostnames cannot be specified here
## the wildcards you may use are * and ?
##
## allow 192.168.2.*
## deny 192.168.2.1?

##
## forwarding rules come here
##
## you may specify allow and deny rules after a specific forwarding rule
## to apply to only that forwarding rule
##
## bindadress    bindport  connectaddress  connectport

## SocksPorts
127.0.0.1        9050      192.168.0.10    9050
127.0.0.1        9150      192.168.0.10    9150
</pre>

Tor Button's New Identity feature won't work, because that requires access to Tor's control port. Unfiltered access to Tor's control port is recommended against, because the control port command "getinfo address" could leak your IP. Due to lack of control port access, you will also see a "your browser is not configured to use Tor" warning when Tor Browser starts, because it uses Tor's control port for its check. Those two things shouldn't matter much and could be fixed with something like [Control Port Filter Proxy](https://www.whonix.org/wiki/Dev/Control_Port_Filter_Proxy), but that's a different story.

[Axon]

Very interesting and helpful. Thank you!

Just a preliminary question first: Is there any known way for a user to
check whether their browser is using Tor over Tor?

[adre...@gmail.com]

On Sunday, September 29, 2013 5:44:19 PM UTC, Axon wrote:

Just a preliminary question first: Is there any known way for a user to
check whether their browser is using Tor over Tor?

Yes. Start Tor Browser and check. The workstation / or AppVM shouldn't run a "tor" process. You can look through the list of running processes "ps aux | grep tor".

Another way of ensuring as a user is deleting tor-browser_en-US/App/tor.

From a developer perspective: In Whonix-Workstation starting Tor is prevented, because rinetd listens on Tor's default ports 9050, 9051, 9150 and 9151. And because the Tor Debian package is prevented from starting because Whonix diverts (config-package-dev) Tor's init script's config file /etc/default/tor by disabling the Tor daemon from automatically starting.

[Axon]

I set up an AppVM behind a TorVM to test and put a fresh vanilla copy of
TBB in there.

$ ps aux | grep tor

This shows the same result regardless of whether I start TBB intact
normally (presumably thereby running Tor over Tor) or first delete
tor-browser_en-US/App/tor. How can we explain this?

[Axon]

(Just to clarify, the "same result" seems to be that neither one shows a
"tor" process running. Only TorBrowser itself.)

[Marek Marczykowski-Górecki]

On 30.08.2013 14:51, Axon wrote:

Perhaps it is good idea to add some firewall rule in TorVM to redirect traffic
to any 10.137.0.0/16 IP + port 9050/9049 to the tor running in TorVM. This way
AnonVM can use any IP as a sock proxy address.

[Axon]

On 09/30/13 08:34, Marek Marczykowski-Górecki wrote:
> On 30.08.2013 14:51, Axon wrote:
>> Hi Abel,
>>
>> Quick question, if you don't mind:
>>
>> In your Torless TBB launcher script for use with Qubes' transparent Tor proxy,
>> TOR_SOCKS_HOST=10.137.3.1. Is this supposed to be the same for all Qubes
>> machines regardless of how many ProxyVMs users have created (or other user
>> settings)? Or is the user supposed to change this before using the script?
>
> Perhaps it is good idea to add some firewall rule in TorVM to redirect traffic
> to any 10.137.0.0/16 IP + port 9050/9049 to the tor running in TorVM. This way
> AnonVM can use any IP as a sock proxy address.
>

Just to make sure we're assuming the same setup:

AnonVM --> TorVM --> FirewallVM --> NetVM --> Internet

Now, are you referring to adding a firewall rule in TorVM using the
Qubes VM Manager? I'm not sure I know the correct way to make such a rule.

Example (in "Firewall rules" tab of TorVM settings in Qubes VM Manager):
Deny network access except...
Address Service Protocol
10.137.0.0/16 versiera tcp

(When I type "9050" into the "Service" field, it shows up as "versiera,"
as above.)
Is this example what you mean? I'm not sure if what I have done here
makes any sense.

[Abel Luck]

Axon:

The documentation is out of sync with recent changes I suspect.

Currently, 9050 doesn't use the paranoid stream isolation options, while
9049 does.

Web browsers, and other apps that make dozens of short connections,
shouldn't use the extreme stream isolation (port 9049), because it is
quite slow.

So, in regards to the 1, 2, 3 list quoted above, that information is
outdated if you're running the latest version of torvm.

9050 - less strict stream isolation, less anonymous, better performance

9049 - strict stream isolation settings, most anonymous, but lower
performance

Originally, that was reversed. I made the change because 9050 is the
default SOCKS port, and it is considered courteous practice in the Tor
community not to enable strict isolation by default as it puts more
strain on the network.

> Actually, this section of the page is not very clear:
>
>> Port 9049 - Isolates destination port and address, and by SOCKS Auth
>> Same as default settings listed above, but each app using a unique
>> SOCKS user/pass gets its own circuit.
>
> What default settings listed above? I don't see any "default settings
> listed above" on this page. Do you?
>

That's a copy/paste error on my part when tweaking the documentation
after the 9050<->9049 switch.

>> Port 9050 - Isolates by SOCKS Auth and client address only
>> Each AppVM gets its own circuit, and each app using a unique SOCKS
>> user/pass gets its own circuit
>
> The second part of each sentence is the same: "each app using a unique
> SOCKS user/pass gets its own circuit." So, the only difference is that
> with Port 9050, each AppVM gets its own circuit? Is that actually
> consistent with the email from a year ago?

To understand the difference between the various stream isolation
settings, read the tor manpage for the following options:

IsolateClientAddr, IsolateSOCKSAuth, IsolateDestAddr, and IsolateDestPort

~abel

[Abel Luck]

adre...@gmail.com:

Woot. Thanks for the info adrelanos. Whenever I next get time, I'll work
on porting this to Qubes directly.

~able

[Joanna Rutkowska]

On 09/29/13 19:30, adre...@gmail.com wrote:

> Tor Button's New Identity feature won't work, because that requires access
> to Tor's control port. Unfiltered access to Tor's control port is
> recommended against, because the control port command "getinfo address"
> could leak your IP. Due to lack of control port access, you will also see a
> "your browser is not configured to use Tor" warning when Tor Browser
> starts, because it uses Tor's control port for its check. Those two things
> shouldn't matter much and could be fixed with something like [Control Port
> Filter Proxy](https://www.whonix.org/wiki/Dev/Control_Port_Filter_Proxy),
> but that's a different story.
>

I would recommend against exposing the Tor control to any AppVMs not
only because the VM might issue commands to obtain the IP, but
generally, even if we could disable select commands over this channel,
this still would probably expose large attack surface on the tor running
in the TorVM, hence negating the isolation provided by using a separate
VM (the user AppVM should be considered untrusted, because it runs a Web
browser).

Anyway, a different question -- and I think this was already discussed
on this mailing list some time ago, but I couldn't find it quickly and I
don't remember the conclusion -- why would anybody want to use TBB in an
AppVM connect to a TorVM? Why not a plain Firefox or any other browser?

joanna.

[Marek Marczykowski-Górecki]

On 01.10.2013 03:27, Axon wrote:
> On 09/30/13 08:34, Marek Marczykowski-Górecki wrote:
>> On 30.08.2013 14:51, Axon wrote:
>>> Hi Abel,
>>>
>>> Quick question, if you don't mind:
>>>
>>> In your Torless TBB launcher script for use with Qubes' transparent Tor proxy,
>>> TOR_SOCKS_HOST=10.137.3.1. Is this supposed to be the same for all Qubes
>>> machines regardless of how many ProxyVMs users have created (or other user
>>> settings)? Or is the user supposed to change this before using the script?
>>
>> Perhaps it is good idea to add some firewall rule in TorVM to redirect traffic
>> to any 10.137.0.0/16 IP + port 9050/9049 to the tor running in TorVM. This way
>> AnonVM can use any IP as a sock proxy address.
>>
>
> Just to make sure we're assuming the same setup:
>
> AnonVM --> TorVM --> FirewallVM --> NetVM --> Internet
>
> Now, are you referring to adding a firewall rule in TorVM using the Qubes VM
> Manager? I'm not sure I know the correct way to make such a rule.

I meant to modify qubes-tor startup script to add such redirection. Ok, I
should check this first - those rules are already present:
/sbin/iptables -t nat -A PREROUTING -i vif+ -p tcp -m tcp --dport
$TOR_SOCKS_ISOLATED_PORT -j DNAT --to-destination
$QUBES_IP:$TOR_SOCKS_ISOLATED_PORT
/sbin/iptables -t nat -A PREROUTING -i vif+ -p tcp -m tcp --dport
$TOR_SOCKS_PORT -j DNAT --to-destination $QUBES_IP:$TOR_SOCKS_PORT

So TOR_SOCKS_HOST can be any IP (excluding localhost ;) ).

[adrelanos grayson]

On Tuesday, October 1, 2013 11:51:28 AM UTC, joanna wrote:

On 09/29/13 19:30, adre...@gmail.com wrote:

> Tor Button's New Identity feature won't work, because that requires access
> to Tor's control port. Unfiltered access to Tor's control port is
> recommended against, because the control port command "getinfo address"
> could leak your IP. Due to lack of control port access, you will also see a
> "your browser is not configured to use Tor" warning when Tor Browser
> starts, because it uses Tor's control port for its check. Those two things
> shouldn't matter much and could be fixed with something like [Control Port
> Filter Proxy](https://www.whonix.org/wiki/Dev/Control_Port_Filter_Proxy),
> but that's a different story.
>


I would recommend against exposing the Tor control to any AppVMs not
only because the VM might issue commands to obtain the IP,

 

but
generally, even if we could disable select commands over this channel,

It's not a blacklist approach, it's a whitelist approach.
 

this still would probably expose large attack surface on the tor running
in the TorVM, hence negating the isolation provided by using a separate
VM (the user AppVM should be considered untrusted, because it runs a Web
browser).

I don't think Tor is the main attack surface in my application. For attack surface, please see https://groups.google.com/forum/#!msg/qubes-devel/2vnGqsoM9p0/UFVm36X4MMAJ second chapter. I'd be very interested what you think.

Anyway, a different question -- and I think this was already discussed
on this mailing list some time ago, but I couldn't find it quickly and I
don't remember the conclusion --

Yes, was discussed in this thread:
https://groups.google.com/forum/#!topic/qubes-devel/2vnGqsoM9p0
 

why would anybody want to use TBB in an
AppVM connect to a TorVM? Why not a plain Firefox or any other browser?

I know you found that thread already, but for anyone else, here's the link:

 https://groups.google.com/forum/#!topic/qubes-devel/6ewqvvwj7I4

 

[Axon]

That's great! So now all we have to do is make sure that we bypass TBB's
bundled Tor and set TOR_SOCKS_PORT correctly. (Or can TOR_SOCKS_PORT
also be any port?)

According to Abel's recent email[1], TorBrowser should currently be
using port 9050. However, according to Adrelanos' recent email[2], this
cannot be done simply by exporting the environment variable
TOR_SOCKS_PORT. Instead, he says, we can either change the proxy
settings in TorButton or use rinetd. I'll go with the first option
because it seems easier, and it doesn't sound like there's any drawback
to doing it that way. If I understand everything correctly, then, the
right way to do this is:

1. Click the TorButton icon.
2. Click "Preferences..."
3. Select "Use custom proxy settings"
4. Change "SOCKS Host" to anything except localhost (e.g. 1.1.1.1).
5. Change "Port" to 9050.
6. Leave everything else at the defaults. Click OK.
7. Restart TorBrowser.

(How does this look? Any missing steps?)

But we're not finished yet. We still have figure out how to bypass the
Tor that's included in TBB. Thankfully, Adrelanos already provided us
with detailed instructions.[3] In short:

Create a file /etc/profile.d/20_torbrowser.sh containing:

export TOR_SKIP_LAUNCH=1

But /etc is going to be wiped every time we shut down the AppVM, so we
have to put it in the TemplateVM. But which TemplateVM is it supposed to
go in? The TemplateVM for the AnonVM or the one for the TorVM? (Of
course, they could be the same TemplateVM, but we should not assume that
they are! In fact, there are good reasons to have separate ones, but
that's a different topic.)

After we determine the answer to that question, we put the file in the
correct TemplateVM, shut it down, and restart the AnonVM. Done! Now we
can use TorBrowser in a Qubes AppVM without running Tor over Tor (or any
other undesirable side effects).

(How does this look? Any missing steps? Once we get this settled it can
be added to the wiki as a reference for others. So, if something doesn't
look right, please speak up now.)

[1]https://groups.google.com/d/msg/qubes-devel/Dd0MVbIam5I/q84E18iuI7oJ
[2]https://groups.google.com/d/msg/qubes-devel/Dd0MVbIam5I/FeW-Exqcw5sJ
[3]http://tor.stackexchange.com/questions/29/how-do-i-use-tor-browser-with-qubes-torvm

[Marek Marczykowski-Górecki]

No, TOR_SOCKS_PORT must me the right port (9050 or 9049 - don't remember which
is which...).

You can use ~/.profile for this.

> After we determine the answer to that question, we put the file in the correct
> TemplateVM, shut it down, and restart the AnonVM. Done! Now we can use
> TorBrowser in a Qubes AppVM without running Tor over Tor (or any other
> undesirable side effects).
>
> (How does this look? Any missing steps? Once we get this settled it can be
> added to the wiki as a reference for others. So, if something doesn't look
> right, please speak up now.)
>
> [1]https://groups.google.com/d/msg/qubes-devel/Dd0MVbIam5I/q84E18iuI7oJ
> [2]https://groups.google.com/d/msg/qubes-devel/Dd0MVbIam5I/FeW-Exqcw5sJ
> [3]http://tor.stackexchange.com/questions/29/how-do-i-use-tor-browser-with-qubes-torvm
>

[Axon]

Actually, I forgot to include the additional (perhaps superior) option
for ensuring that we don't accidentally run Tor over Tor. As Adrelanos
said: just delete tor-browser_en-US/App/tor! This is simple and
straightforward, and I think even novice Qubes users will understand
this and feel comfortable with it. Plus, if we go with this option, we
don't have to worry about creating the 20_torbrowser.sh file or about
which TemplateVM to stick it in.

[Axon]

Ah, OK. Thanks, Marek.

Either way, that's easy enough: Either create the file and put it in
~/.profile, or just delete tor-browser_en-US/App/tor.

[adrelanos]

Marek Marczykowski-Górecki:

> You can use ~/.profile for this.

I think it's better to document and implement to drop files in
/etc/profile.d/ folder. (If Fedora supports that.)

[adrelanos]

Axon:

> According to Abel's recent email[1], TorBrowser should currently be
> using port 9050. However, according to Adrelanos' recent email[2], this
> cannot be done simply by exporting the environment variable
> TOR_SOCKS_PORT. Instead, he says, we can either change the proxy
> settings in TorButton or use rinetd. I'll go with the first option
> because it seems easier,

Easier from a user perspective only.

> 1. Click the TorButton icon.
> 2. Click "Preferences..."
> 3. Select "Use custom proxy settings"
> 4. Change "SOCKS Host" to anything except localhost (e.g. 1.1.1.1).
> 5. Change "Port" to 9050.
> 6. Leave everything else at the defaults. Click OK.
> 7. Restart TorBrowser.
>
> (How does this look? Any missing steps?)

Sounds good. Restart should not be required.

> But we're not finished yet. We still have figure out how to bypass the
> Tor that's included in TBB. Thankfully, Adrelanos already provided us
> with detailed instructions.[3] In short:
>
> Create a file /etc/profile.d/20_torbrowser.sh containing:
>
> export TOR_SKIP_LAUNCH=1

1. Just to make sure: My instructions were just my best attempt to share
my knowledge. It's not actually tested. But I think I said that in that
post.

2. Is /etc/profile.d/ actually functional in Fedora?

3. This only works for TBB 3.x (not yet stable, still alpha). Not for
TBB 2.x. (stable).

For TBB 2.x you need to modify the start-tor-browser startup script.

> But /etc is going to be wiped every time we shut down the AppVM, so we
> have to put it in the TemplateVM. But which TemplateVM is it supposed to
> go in? The TemplateVM for the AnonVM or the one for the TorVM? (Of
> course, they could be the same TemplateVM, but we should not assume that
> they are! In fact, there are good reasons to have separate ones, but
> that's a different topic.)

Not sure here, I think having separate templates for TorVM (=Gateway)
and AnonVM (=Workstation) is the way to go. Adding
/etc/profile.d/20_torbrowser.sh to the AnonVM template.

[adrelanos]

Another way to prevent Tor over Tor is listening on TBB's default port
127.0.0.1:9150, so TBB's Tor won't be able to listen on that port.

Axon:

> Either way, that's easy enough: Either create the file and put it
> in ~/.profile, or just delete tor-browser_en-US/App/tor.

Only deleting tor-browser_en-US/App/tor can't be a final solution.
Once TBB gets its own updater, that may break.

This was by the way the Firefox users.js proxy settings method.

## Editing /home/"$USERNAME"/tor-browser_"$TB_LANG"/Data/profile/users.js
## http://kb.mozillazine.org/User.js_file
## Configuring Tor Button to use SOCKSPort;
## expanding extensions.torbutton.banned_ports with Whonix specific ports.

echo '
## Begin of patched user.js.
## If you edit this file while Firefox is running, your changes will be
## overwritten, when you close Firefox.

## How to create the user.js network settings:
## 1. Make a backup of prefs.js.
## 1. Start Tor Browser with the patched start script.
## 2. Apply proxy settings using the Tor Button settings dialog..
## 3. Make a diff from the old and the new pref.js.
## 4. Copy the relevant changes to user.js.

## network settings
## (Are now set in /etc/environment - or not...)
## (See /etc/environment.)
user_pref("extensions.torbutton.use_privoxy", false);
user_pref("extensions.torbutton.settings_method", "custom");
user_pref("extensions.torbutton.socks_host", "192.168.0.10");
user_pref("extensions.torbutton.socks_port", 9100);
user_pref("network.proxy.socks", "192.168.0.10");
user_pref("network.proxy.socks_port", 9100);
user_pref("extensions.torbutton.custom.socks_host", "192.168.0.10");
user_pref("extensions.torbutton.custom.socks_port", 9100);

## End of user.js.
' >>
/home/"$USERNAME"/tbbdownload/tor-browser_"$TB_LANG"/Data/profile/user.js

Anyhow. After a lot experience integrating Tor Browser into Whonix,
I've came to the conclusion, that using proxy settings, user.js or
proxy settings environment variables will break every now and then.
For times when it breaks, users are told to manually update Tor
Browser. And this discussion about Tor over Tor and changing proxy
settings starts again.

The new low maintenance strategy from a developer perspective is
setting "export TOR_SKIP_LAUNCH=1" and hoping that won't break in
further versions. And not changing anything in Tor Browser, leaving
the defaults (little else gets tested by upstream anyway), and using
port redirection (rinetd) to forward port 127.0.0.1:9150 (default
port) to whatever the gateway provides.

Anyone capable for omitting rinetd and doing such port redirection
with pure iptables?

The advantage of no longer needing to tell users how to modify proxy
settings is, that they don't need to wait until some template/package
is updated. And that they can always use the stock version from
torproject.org and are unable to mess up one way or another. People
will do as Tor Browser / Tor Button tells them and update directly
from torproject.org. They don't have such an compartmentalization of
QubesOS/TorVM/TBB/Tor Browser/torproject.org in mind, they see a

[Axon]

Adrelanos, this is a great message. I like what you're saying. But it
looks like it got prematurely cut off. I want to read the rest. :)

[adrelanos]

Axon:

> Adrelanos, this is a great message. I like what you're saying. But
> it looks like it got prematurely cut off. I want to read the rest.
> :)

Thanks.

from 127.0.0.1:9150 to gateway:9050 with pure iptables?

The advantage of no longer needing to tell users how to modify proxy
settings is, that they don't need to wait until some template/package
is updated. And that they can always use the stock version from
torproject.org and are unable to mess up one way or another. People
will do as Tor Browser / Tor Button tells them and update directly
from torproject.org. They don't have such an compartmentalization of
QubesOS/TorVM/TBB/Tor Browser/torproject.org in mind, they see a

window and conclude it's all from the vendor, and don't know that the
downstream developers (QubesOS/Whonix) actually rarely have any
contact to TBB developers or say in what TBB is doing. Many peaces of
Open Source software thrown together doesn't result in something where
everything was assembled by a team with a unified user experience in mind.

[Abel Luck]

Joanna Rutkowska:

> On 09/29/13 19:30, adre...@gmail.com wrote:
>
>> Tor Button's New Identity feature won't work, because that requires access
>> to Tor's control port. Unfiltered access to Tor's control port is
>> recommended against, because the control port command "getinfo address"
>> could leak your IP. Due to lack of control port access, you will also see a
>> "your browser is not configured to use Tor" warning when Tor Browser
>> starts, because it uses Tor's control port for its check. Those two things
>> shouldn't matter much and could be fixed with something like [Control Port
>> Filter Proxy](https://www.whonix.org/wiki/Dev/Control_Port_Filter_Proxy),
>> but that's a different story.
>>
>
>
> I would recommend against exposing the Tor control to any AppVMs not
> only because the VM might issue commands to obtain the IP, but
> generally, even if we could disable select commands over this channel,
> this still would probably expose large attack surface on the tor running
> in the TorVM, hence negating the isolation provided by using a separate
> VM (the user AppVM should be considered untrusted, because it runs a Web
> browser).
>

This is correct IMHO. Indiscriminately allowing Tor control to AppVms is
a bad idea.

> Anyway, a different question -- and I think this was already discussed
> on this mailing list some time ago, but I couldn't find it quickly and I
> don't remember the conclusion -- why would anybody want to use TBB in an
> AppVM connect to a TorVM? Why not a plain Firefox or any other browser?
>

TBB is more than just firefox + the tor daemon. The version of firefox
included is heavily patched to, among many other things, reduce the
ability to fingerprint--and therefore deanonymize--a user.

Read the Tor Browser design document for more information:

https://www.torproject.org/projects/torbrowser/design/

In short, you sacrifice much anonymity protection by using a normal
browser over Tor.

More reading:

* https://panopticlick.eff.org/
*
https://blog.torproject.org/blog/firefox-private-browsing-mode-torbutton-and-fingerprinting


~abel

[Hakisho Nukama]

> --
> You received this message because you are subscribed to the Google Groups "qubes-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> Visit this group at http://groups.google.com/group/qubes-devel.
> For more options, visit https://groups.google.com/groups/opt_out.

About fingerprinting, this is considered on page 16:
http://www.theguardian.com/world/interactive/2013/oct/04/tor-stinks-nsa-presentation-document

Best Regards,
Hakisho Nukama

[Axon]

Now that TBB 3.0 has been released, I think it's time to revisit this
issue. Apparently a lot has changed from TBB 2.x, and Abel's script for
starting Torless TBB in Qubes no longer works (but perhaps isn't
required any more?). So, are there any special requirements for using
TBB 3.0 Torlessly in Qubes R2B3? Can one just set TorButton >
Preferences > Transparent Torification, and be done with it (assuming
the QubesTor side has already been properly configured)?

[sam]

This is what I have done and it is working fine except for the fact that I have not been able to get it to work within the template so a user would just need to repeat the single folder containing TBB to how ever many VM's they would like to use it in.

( Basically want it to work the same way as installing

The other part that I have not yet looked into would be to see If setting a bridge into the TorButton settings has any effects or if bridge mode needs to be set in the TorVM.

[vuarnet]

There is a section in the start_tor_browser script though that comments on settings in TBB about:config that can be set for use to use a "system level tor" instead of the TBB-packaged tor:

# Additionally, if using a system-installed Tor, the following about:config

# options should be set (values in <> mean they are the value taken from your

# torrc):

#

# SETTING NAME                            VALUE

# extensions.torbutton.banned_ports       [...],<SocksPort>,<ControlPort>

# extensions.torbutton.block_disk         false

# extensions.torbutton.custom.socks_host  127.0.0.1

# extensions.torbutton.custom.socks_port  <SocksPort>

# extensions.torbutton.inserted_button    true

# extensions.torbutton.launch_warning     false

# extensions.torbutton.loglevel           2

# extensions.torbutton.logmethod          0

# extensions.torbutton.settings_method    custom

# extensions.torbutton.socks_port         <SocksPort>

# extensions.torbutton.use_privoxy        false

# extensions.torlauncher.control_port      <ControlPort>

# extensions.torlauncher.loglevel          2

# extensions.torlauncher.logmethod         0

# extensions.torlauncher.prompt_at_startup false

# extensions.torlauncher.start_tor         false

If you set extensions.torlauncher.start_tor and extensions.torlauncher.prompt_at_startup to false, it works as intended, assuming a anonvm -> torvm -> firewallvm -> netvm setup.

I originally tried setting transparent torification in Torbutton, but it still started the TBB-packaged tor (verified via ps aux | grep tor), but tor was not started when I set these flags in about:config.

[Andrew B]

> --
> You received this message because you are subscribed to the Google Groups "qubes-devel" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel...@googlegroups.com <mailto:qubes-devel...@googlegroups.com>.
> To post to this group, send email to qubes...@googlegroups.com <mailto:qubes...@googlegroups.com>.

> Visit this group at http://groups.google.com/group/qubes-devel.

> For more options, visit https://groups.google.com/d/optout.

It also works to simply do:

$ TOR_SKIP_LAUNCH=1 ./start-tor-browser

Andrew

[HW42]

Andrew B:

[ Last mail was accidentally sent only to Andrew ]

I'm using something like this:

---------------------------------------------------
#!/bin/bash

export TOR_SKIP_LAUNCH=1
export TOR_CONTROL_PASSWD='"none"'
export TOR_CONTROL_HOST=10.137.6.1
export TOR_CONTROL_PORT=9051
export TOR_SOCKS_HOST=10.137.6.1
export TOR_SOCKS_PORT=9050

exec /home/user/tor-browser/start-tor-browser "$@"
---------------------------------------------------

Replace 10.137.6.1 with the IP of your tor gateway and adapt the path.

If you are annoyed by the warning about the failed tor start set
extensions.torbutton.local_tor_check to false.

HW42

[Axon]

I was under the impression that it's fine if the tor process gets
started in the AnonVM as long as traffic doesn't actually get routed
through Tor from within the AnonVM (and again in the TorVM, i.e., Tor
over Tor).

Is this incorrect?

Or are you saying that the "Transparent Torification" option in
Torbutton is actually broken and does not do what it says it does?

[vuarnet]

I think it is fine -- it didn't cause any problems. Putting Torbutton in "transparent" mode did the trick, with or without having the packaged tor running. I simply don't want it running because I figure it's an easy unknown worth eliminating. Nothing more. Setting the flag in the about:config in TBB did the trick for both utilizing transparent proxying (as far as I can tell) and not having an extraneous tor running.
 

Or are you saying that the "Transparent Torification" option in
Torbutton is actually broken and does not do what it says it does?

Not at all -- Torbutton seemed to work exactly as intended -- when I set it to transparent mode, it worked fine and bypassed Tor (the "test settings " button in the preferences in Torbutton is really handy to double-check that transparent torification works before relying on it.

The only thing that I'm confused about still is the difference between using the transparent setting or the SOCKS host setting as in the script above... I'm not clear on the benefits / drawbacks of either method, and I got a bunch of errors when I originally started TBB with the SOCKS host specification, so I backed off and went back to transparent mode.

The simplicity of transparent proxying is attractive, I'm just not sure if there are any material benefits to doing it the way that HW42 suggests via script (specifying your torVM's IP address and port under SOCKS host within Torbutton prefs). It seems like if you trust in the enforcement of stream isolation by specifying TorVM as your AnonVM's netvm (proxyvm), it should be OK.