Consider making onion-grater drop NEWNYM requests from Workstations to prevent correlating isolated circuits

Development
1

Link to a comment: Review the newnym error handling UX (#41708) · Issues · The Tor Project / Applications / Tor Browser · GitLab

1 Like
2

You could also suggest this to Tails for wider input because onion-grater was invented by the Tails project.

3

Hmm I’m not sure to what extent it applies to the Tails threat model. Whereas for Whonix it’s clear-cut that one Workstation should not be able to substantially influence the circuits of another, right?

Actually the issue goes beyond just filtering unprivileged clients via onion-grater or whatever: Even the trusted user themself should be wary of (and maybe cautioned against?) triggering NEWNYM in any way. It’s a very big global hammer when the problem is usually just one crappy annoying circuit somewhere.

4

rustybird via Whonix Forum:

Hmm I’m not sure to what extent it applies to the Tails threat model. Whereas for Whonix it’s clear-cut that one Workstation should not be able to substantially influence the circuits of another, right?

Could apply a single instance of Tor Browser with multiple tabs.

Actually the issue goes beyond just filtering unprivileged clients via onion-grater or whatever: Even the trusted user themself should be wary of (and maybe cautioned against?) triggering NEWNYM in any way. It’s a very big global hammer when the problem is usually just one crappy annoying circuit somewhere.

Yes. Therefore applies to Tor Browser generally (outside of Whonix) as
well as Tails.

5

The issue could be much more generalized than even just newnym.

Quote Tor developer teor from [tor-dev] Different trust levels using single client instance.

  • Caching of DNS, HS descriptors, preemptive circuits, etc.
  • VMs can leak other VM’s guards and even entire circuits
    • easily without a control port filter
    • perhaps some discovery attacks even with a filter

If Tor has a global cache for DNS, HS descriptors, preemptive circuits, etc. then this wouldn’t be compatible with the Tor Browser per-tab isolation design. This cache would either need to be disabled or also be per-tab.

Also quoting from that ticket:

I can’t answer that, I’m sorry.

We could just remove it if it’s safe not to have it/it’s useless.
I’ll need to ask the network team.
I’ll meet some folks in a couple of weeks and ask them (I took a note to, I hope we’ll have time also for that :slightly_smiling_face:).

So it could be the case that you posted off-topic in the wrong ticket assigned to the wrong person / team.

The ticket was just for Review the newnym error handling UX. Not to review multi-tab / multi Tor Browser connected to the same Tor versus Tor global cache. Might be better to make a dedicated ticket and link to it.

6

Thanks for that link, right on target.

After looking into the tor code a bit, currently the main sticking point seems to be the onion-service client state - until TB moves to arti. Summary

Tails might be less affected by this dilemma (of either interfering with unrelated global state with NEWNYM, or not properly invalidating all of the related state without), because a) they’ve set up onion-grater to allow only TB to do NEWNYM and b) they don’t have multiple TB instances running concurrently. So for them, that NEWNYM can only interfere with other, relatively “minor” applications (that are also in the same scope - no equivalent of multiple isolated Workstations there). Which is probably not quite as much of a tracking risk in practice. I still need to think about it some more…

1 Like