Tor Browser New Identity differs from restarting Tor Browser in Whonix

Support
13

As a stopgap Whonix’s tb-starter /usr/bin/torbrowser could request newnym before starting Tor Browser and/or after Tor Browser has terminated. Does automation of that sound sane or can you imagine any ill effects?

2 Likes
14

⚓ T567 research: Single Tor-Gateway with Multiple Workstations vs Multiple Tor-Gateways mapped 1:1 to Workstation VMs is somewhat similar / related.

1 Like
15

No, it doesn’t. That’s why I specifically mentioned gmail.com. You asked the following earlier:

If “second reason” is referring to:

why would that not be correct? The only way that Tor Browser would not isolate different websites is if you used some type of proxy after Tor, in which case, all of your browsing would occur over a single circuit until a relay died.

The fact that 2 connections originate from the same Tor exit node within a short timeframe would constitute some circumstantial evidence. People are free to draw whatever conclusions they want.

Depends on logging.

1 Like
16

Can’t imagine any situation in which user would want to reuse circuits from a prior Tor Browser session - reauthentication with websites would be required anyway because cookies are destroyed.

Probably safer to issue newnym on termination, just because I don’t understand how SOCKSAuth is constructed and whether or not it’s possible for another application to issue the same SOCKSAuth.

1 Like
17

Thanks for the replies and patience, entr0py. I think I’m getting there.
As you say, you think the first-party domain is incorrect because it does show the same IP for every checked tab within one session. I have no idea what the SOCKSAuth does, but if the tabs use the same IP, how does that help keeping profiles apart?

And why is it different if it’s not logging into the the same website?
If joe logs into say an onion website, then restarts Tor Browser and logs into a clearnet website as marry, then both should be connected the same way as if they would have logged in one website?

Can you please elaborate on what you mean by “Depends on logging”? The logs that the websites keep or something else?

I do appreciate this.

18

No problem. We have found the source of the confusion!

I never said or implied this. What I said was that every checked tab showed the same IP for the same website. This proved that Tor Browser doesn’t automatically create a new circuit for every tab.

In fact, Tor Browser creates a new circuit for every new first-party base domain URL. That means mail.google.com and accounts.google.com will stream over the same circuit but mail.facebook.com will generate a new circuit. All the additional URLs that are generated from the initial request will also stream over the respective initial (first-party) circuit. This is Tor Browser’s default behavior - like unused circuits dying at 10 mins - it has nothing to do with restarting the browser or clicking “New Identity”. (Also don’t worry about SOCKSAuth. That’s just the mechanism that Tor Browser uses to differentiate websites).

Whatever logs websites keep, whatever logs ISPs keep, whatever logs the NSA keeps… Basically, I don’t know.

1 Like
19

@winibub To be absolutely certain that activities from your last session are not detectable in your new one - you should create a snapshot of a freshly installed GW after Tor is initially started up and rollback to it along with your WS clean state.

Want to run multi-WSs same time? You must have a separate GW assigned for every WS. Be sure to apply the advice above here too.

https://lists.torproject.org/pipermail/tor-dev/2016-November/011636.html

20

After restarting Tor Browser, connections should be stream isolated. Even to same domain. This is because Tor Browser sets a socks user name that contains a random string per first level domain the is different after a browser restart.

We are discussing multiple vs single gateway here at the moment btw:
⚓ T567 research: Single Tor-Gateway with Multiple Workstations vs Multiple Tor-Gateways mapped 1:1 to Workstation VMs

Sure.

My caution is related to worsening the fingerprint of any other application that may be running in parallel while sending newnym.

Learning the socks username can be done by running torbutton in debug mode. Just now documented here:
Tor Browser Essentials

The socks username consists of the the first level domain name as well as a random string. Example:

torproject.org:<random string >
21

I’ve been listening in on that convo. One GW per hidden service is reasonable but for client use, it’s a usability nightmare. And how would it be implemented to cover the dispVM use-case?

Just tested using your instructions in a Whonix-WS dispVM. My <random string> is always 0.

1 Like
22

That is strange! To make sure we are on the same side…

For me, I see:

Torbutton INFO: tor SOCKS: https://check.torproject.org/ via torproject.org:xxx

vs after restart

Torbutton INFO: tor SOCKS: https://check.torproject.org/ via torproject.org:yyy

For you it is always 0?

1 Like
23

Finally figured it out! The culprit is Tor Browser VERSION.

I tested using a dispVM with a fresh installation of Tor Browser, a regular appVM, and a Virtualbox VM - all of them running TB 6.0.5. They all showed domain:0 for socks user:pass. Even after clicking New Identity, the password continued to be 0.

6.5a3 and 6.5a3-hardened both showed random strings for the password, which changed after pressing New Identity. Closing and restarting the browser does indeed generate a new password - so the submitted ticket should be updated to differentiate between Tor Browser versions.

I can’t tell if this is a bug with 6.0.5 or a feature of the alpha browsers. I can’t find my way around trac.torproject so if someone wants to take a look, here are some relevant links:

Tor Browser design doc: 4.5. Cross-Origin Identifier Unlinkability
The Design and Implementation of the Tor Browser [DRAFT]
Issue Tracker:
Tor Browser should set SOCKS username for a request based on first party domain (#3455) · Issues · Legacy / Trac · GitLab
Code:
The Tor Project / Organization · GitLab

Now, I’d like to continue my rant :slight_smile: Am I the only schmuck running 6.0.5 around here?

1 Like
24

Seems to be a bug since feature has been a part of TBB since 4.5-stable.
Release notes: Tor Browser 4.5 is released | The Tor Project

Update Torbutton to 1.9.2.2. Changes since 1.7.0.2 in 4.0.8:

  • Bug 3455: Use SOCKS user+pass to isolate all requests from the same url domain

trac.torproject is really non-newb friendly (keeps idiots like me away so guess that offers some benefits…) I couldn’t find any existing tickets mentioning this “bug” but ymmv:

torbutton:

torbrowser:

1 Like
25

Three options.

  • ask on Tor IRC
  • ask on tor-talk
  • report a new bug (I guess you effort well justifies the risk of adding a duplicate)
26

+1 as it will get noticed at some point. On IRC people can be unavailable. On tor-talk no one that matters reads there anymore.

27

filed against tbb: TBB 6.0.5 DomainIsolator does not generate unique nonce paswords for socksauth (#20623) · Issues · Legacy / Trac · GitLab

Go figure. I just got around to subscribing couple days ago.

EDIT: Actually, I’m thinking that this might be expected behavior. I think the original design of TBB 4.5 was to have a socks password of 0 that incremented for each new circuit. The random passwords may be a new alpha feature. If this is the case, then the previous submitted ticket #20479 is still relevant for TBB 6.0.5 + system Tor.

28

Now that we all do understand random socks user names better… And imagine 20623 was fixed or 6.5 was blessed the stable version already… What do you think about my original above question in this posting?

29

Just updated 20623. Bug is indeed invalid IIUC.

20479 will persist as an issue (only for stable TBB - alpha should be unaffected) unless:

  1. Whonix tb-starter issues newnym (before or after) or
  2. Random password feature is backported to TBB-stable by TBB

Just now, while testing Android, I see that connections to Google Cloud Messaging (port 5228) persist for 30? minutes after the Android VM is shut down. (I don’t even understand how that’s possible unless somehow Whonix-Gateway is keeping the connection alive in place of the Android VM.) I wonder if there are scenarios where connections can stay alive after TBB shutdown.

If yes, then newnym should happen after TBB close. The other thing that New Identity does is “close all remaining HTTP keep-alive connections”. Not sure if that’s easy to add.

30

Random socks user name was introduced later indeed:

Newnym before Tor Browser gets started and after it got closed. This is because you can never be sure the send newnym on close will work (could be killed for some reason). This is why I am considering both to make this more reliable.

Since that is http, there is nothing Whonix need to do about this. That should happen inside the browser.

Please open a separate thread for this and add where/how you can see this.

31

I’m having this problem too - seems to be a persistent error for me.

The only variable I can identify was an update to my templateVMs

32

As of TBB-6.5, this should now apply to TBB-stable and not only alpha. https://blog.torproject.org/blog/tor-browser-65-released:

Bug 19206: Avoid SOCKS auth and NEWNYM collisions when sharing a tor client

2 Likes