[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



Hi,

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

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?

> User names and real name

What will be the operating system user name?

> Name+version of any client (e.g. IRC leaks name+version through CTCP)

CTCP can also leak your local time (and therefore including timezone).

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

> Each AppVM will use a separate tor circuit (IsolateClientAddr)

Qubes OS takes care of assigning each AppVM their own local LAN IP?

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

> Future Work  Integrate Vidalia

Good. Will any settings changed in Vidalia be persistent?

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

What is it needed for anyway? Which things do not work without arbitrary
DNS queries?

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

> Future Work  Fix Tor's openssl complaint

Please elaborate, one link is enough.

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