On 2016-11-05 01:36, teor wrote:
On 5 Nov. 2016, at 11:26, Patrick Schleizer
<[email protected]> wrote:
Thank you for your answers!
teor:
* Caching of DNS, HS descriptors, preemptive circuits, etc.
Can you please elaborate on 'etc.'?
I am asking because stream isolation for DNS already has a ticket:
https://trac.torproject.org/projects/tor/ticket/20555
HS cache isolation also has a ticket:
https://trac.torproject.org/projects/tor/ticket/15938
Looks like preemptive circuits isolation does not have a ticket yet.
Preemptive circuits aren't a caching mechanism, and can't really be
isolated in the way you think - circuits are isolated by existing
mechanisms, but this is likely not enough to defend against hostile
clients sharing an instance.
Isolation is a defence against the remote end, not the client end.
If you could please elaborate on 'etc.' we might be able to complete
the
stack of missing tickets.
Circuit cannibalisation (yet another thing that can't be isolated)
SSL state
Guard state
Consensus availability and content
Descriptor availability and content
Connectivity (or lack thereof)
Uptime
ControlPort config information
ControlPort config changes
And many more.
The supported way to isolate many of these things is to run a separate
Tor instance, preferably on a separate machine on a separate network.
We don't even recommend running a SOCKS client and a hidden service
on the same instance.
T
--
Thanks. This is very useful info to keep in mind since it affects usage
advice. A
There is one more related scenario of single Gateway - Workstation pair
where the Workstation VM is rolled back to a clean state between
different sessions however only a NEWNYM is triggered on the Gateway
without restarts. My guess is that many of the risks you detailed still
hold so I want to find out what is the best opsec to handle this:
Do these risks persist across reboot of the Tor VM?
Is restarting of the Tor process enough?
Or should we recommend instead that users make an initial clean snapshot
of the Tor VM and roll back to this instead?
_______________________________________________
tor-dev mailing list
[email protected]
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
