[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] Review request: TorVM implementation in Qubes OS
Abel Luck:
> 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?
UTC is fine. Afaik Tails, Liberte Linux and Whonix are using 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
Good!
>>> 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.
Awareness is fine. If the things which can leak are spoofed, randomized
and/or shared with others, they are less severe.
Setting it to UTC is ok and another time related suggestions is coming
in an extra mail.
>>> 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 :|
I think it still makes sense. Let's say you are using an extra SocksPort
for web and an extra SocksPort for IRC.
After closing the browser it's still useful to issue a new identity to
unlink the sessions before the circuit changes after 10 minutes
automatically.
I am not a expert on that topic, but from observing stream isolating
doesn't lead to circuits being used longer. All circuits switch after 10
minutes and if you want to do it earlier manually, that's still useful.
Interestingly circuit creation is internally implemented in Tor so well,
that if you have 30 SocksPorts, that won't result in 30 circuits. Tor
still only builds the required regular amount of circuits. Only if you
were to use those 30 SocksPorts all at once you had big amounts circuits.
If users understand it, new identity is a good thing. The bigger problem
are users who don't understand it:
https://tails.boum.org/todo/disable_Vidalia_new_identity_feature/
Maybe it should be better renamed to "switch Tor circuit" rather than
"New Identity"?
> Regarding persistence, do you suggest not making it so?
Persistence will be answered in the other mail along with Tor.
>>> 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
>
Rest of it sounds pretty good.
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk