TBB 6.0.5 DomainIsolator does not generate unique nonce paswords for socksauth

TBB 6.0.5 under Debian-8 with Isolating Proxy (Whonix)

SocksAuth viewed in Browser Console with torbutton.loglevel=3 shows :0 for all domains. Password=0 persists even after issuing newnym (via New Identity).

TBB 6.5a3 & TBB 6.5a3-hardened do not exhibit this behavior. These browsers generate unique nonce passwords for separate domains, which are re-generated when newnym is issued.

Trac:
Username: entr0py

added base-url component::applications/tor browser domain first-party owner::tbb-team priority::very high reporter::entr0py resolution::invalid severity::major socksauth status::closed type::defect version::tor 0.2.8.9 labels

Looking at a related ticket, Initialize the SOCKS password to random offset at start (https://trac.torproject.org/projects/tor/ticket/18787)

It may be the case that the random nonce is a feature of the alpha browsers and not implemented in TBB-stable. If so, does the stable password increment only for dirty circuits? In my testing, neither New Identity nor browser restart incremented the password, which becomes an issue when using TBB with system Tor as filed in this ticket: make closing and restart of Tor Browser as good as New Identity (https://trac.torproject.org/projects/tor/ticket/20479)

Trac:
Username: entr0py

So? Features get merged into alpha, and rarely if ever get backported, and this was a new feature that happened to get merged into 6.5a (#19206 (moved)).

The fact that the password component doesn't change is irrelevant as long as NEWNYM is being sent anyway, since all existing circuits (with colliding identifiers) will not be used for further traffic.

Trac:
Status: new to closed
Resolution: N/A to invalid

The random socks user name was implemented in 4.5 stable already.

source: https://blog.torproject.org/blog/tor-browser-45-released

Bug #3455 (moved): Use SOCKS user+pass to isolate all requests from the same url domain

Are you sure the password / random string is really irrelevant? If so, why was it implemented?

Overview:

• 4.5: stable: should work (first stable where this was implemented) (untested)
• 6.0.5: broken
• 6.5a3: working

We changelogs between 6.0.5 and 6.5a3 do not indicate any related changes.

So I think this is a valid bug report against 6.0.5. If it randomly works in one version but not in a later version, I also think this is a good item for unit testing.

Trac:
Resolution: invalid to N/A
Status: closed to reopened
Cc: N/A to adrelanos

@yawning Thanks for the clarification. Didn't realize that random passwords were an alpha-only feature. This came up because TBB 6.0.5 was re-using existing circuits after being closed and restarted (#20479 (moved)) under system Tor - which I see was a motivation for #19206 (moved):

The SOCKS username/password isolation should include a instance identifier such that each invocation of Tor Browser ends up using difference circuits (Currently, the isolation tags will get reused).

@adrelanos IIUC, stable torbrowser has never used random passwords. It's always been 0 + increment per new circuit. Also, I failed to realize that a different password isn't needed after NEWNYM - by definition.

Trac:
Username: entr0py

What yawning said.

Trac:
Status: reopened to closed
Resolution: N/A to invalid

closed

moved to tpo/applications/tor-browser#20623 (closed)