Re: [tor-talk] Review request: TorVM implementation in Qubes OS

[Abel Luck <abel@xxxxxxxxxxxxxxxxxxxx>]

adrelanos:
> Hi,
> 
> I am only commenting by reading the Readme:
> https://github.com/abeluck/qubes-addons/blob/master/qubes-tor/README.md
> 

This is exactly the type of feedback I wanted, thanks. See responses inline.

> First of all, I find this most interesting!
> 
>> Non-comphrensive list of identifiers TorVM does not protect:
> 
>>    Time zone
> 
> Could that be improved by editing /etc/localtime?

I need to do more research into what it would take to protect the
localtime. For example, what are the consequences (technically and
UX-wise) of changing the local timezone to, presumably, UTC?

> 
>> User names and real name
> 
> What will be the operating system user name?
> 
All Qubes VMs use the username "user", only the VM host (aka dom0) has a
user configured username

>> Name+version of any client (e.g. IRC leaks name+version through CTCP)
> 
> CTCP can also leak your local time (and therefore including timezone).
> 

Yea client leaks are something I don't have a desire to solve directly,
rather I would like to make users aware of them. I would love to see a
repository of tor-safe configurations for apps along the lines of
TorBirdy and TorBrowser.

>> For these reasons TorVM ships with two open SOCKS5 ports that provide
> Tor access with different stream isolation settings:
> 
> On which IP are they listening?
> 

Qubes automatically configures networking for client VMs (where client
in these case means clients of a ProxyVM that is providing NAT).

So, the answer to your question is, whatever the default gateway is.

>> Each AppVM will use a separate tor circuit (IsolateClientAddr)
> 
> Qubes OS takes care of assigning each AppVM their own local LAN IP?
> 
Yup.

It should be noted that AppVms are isolated from eachother on the local
network too.

>> Each destination address will use a separate circuit (IsolateDestAdr)
> 
> I am not sure, this is a good idea to have as default for any easily
> installable "Tor Distro Like" project.
> 
> Filesharing traffic already add a lot load the the Tor network. If these
> users create a new circuit for each IP they connect to, this might
> seriously harm the Tor network.
> 
>> For performance reasons less strict alternatives are provided, but
> must be explicitly configured.
> 
> I am in no position to suggest to disable it, but I guess if the Tor
> core members were reading this, they wouldn't like the idea. If they are
> not interested in this thread and therefore not reading this, I
> recommend to create an extra thread whether it's acceptable to enable
> IsolateDestAdr or IsolateDestPort by default for TransPort in a "Tor
> Distro Like" project by default for everyone.
> 

Hm, yes. After reading past discussion on this subject [1] I'm inclined
to disable these options on the default setup, and, instead provide
several more SOCKS ports with usecases (and defaults set accordingly).

>> Future Work  Integrate Vidalia
> 
> Good. Will any settings changed in Vidalia be persistent?
>
I haven't thought about this enough yet.

One problem, Vidalia's "New Identity" button doesn't make sense when you
have many stream contexts :|

Regarding persistence, do you suggest not making it so?

>> Future Work Create Tor Browser packages w/out bundled tor
> 
> Amazing.
> 
>> Future Work  Use local DNS cache to speedup queries (pdnsd)
> 
> That could make users more fingerprintable.
> 
>> Future Work  Support arbitrary DNS queries
> 
> That could make users more fingerprintable.
>

Yup, I'm aware. Really I've no plans to move forward here until
something more concrete develops. (I'm looking at who Tails and Whonix,
who've discussed this issue extensively).


> What is it needed for anyway? Which things do not work without arbitrary
> DNS queries?
>
XMPP SRV lookups for one. Not a pressing issue of course.

>> Future Work  Configure bridge/relay/exit node
> 
> Good.
> 
>> Future Work  Normalize TorVM fingerprint
> 
> I have no imagination what that could mean. Please elaborate.
> 
>> Future Work  Optionally route TorVM traffic through Tor
> 
> What is the motivation behind it?
There is no good reason I can think of yet, I'm just concerened a user
misunderstanding what a TorVM does (provides torified networking to
other AppVms), and opening firefox on it or something.
> 
>> Future Work  Fix Tor's openssl complaint
> 
> Please elaborate, one link is enough.

This is actually fixed. Tor disliked then OpenSSL ciphers available, but
upgrading openssl fixed it.

~abel

[1]:
https://sourceforge.net/p/whonix/wiki/Applications/#limited-workaround-for-tor-browser
https://lists.torproject.org/pipermail/tor-talk/2012-May/024401.html
https://lists.torproject.org/pipermail/tor-talk/2012-May/024403.html
https://trac.torproject.org/projects/tor/ticket/3455

_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk