TorButton should not fixup .onion domains

I received the following email, which might be worth investigating:

Sorry to bother you with this, but didn't know who else to contact.

Defaults (about:config) for TorBrowser should include:

browser.fixup.alternate.enabled;false

to prevent injecting www. & .com on timed-out sites.

Thanks for all your great work; it means a lot to a lot of people.

added TorBrowserTeam201509 component::applications/tor browser owner::cypherpunks priority::medium resolution::fixed status::closed tbb-5.0-regression tbb-firefox-patch tbb-isec-report tbb-pref type::defect labels

I don't understand what we should be worried about here. As far as I can tell, fixup is not applied if the URL already had what appeared to be a valid TLD suffix...

Trac:
Owner: N/A to mikeperry
Component: Torbutton to TorBrowserButton

Trac:
Cc: N/A to g.koppen@jondos.de

Replying to mikeperry:

I don't understand what we should be worried about here. As far as I can tell, fixup is not applied if the URL already had what appeared to be a valid TLD suffix...

I have seen it applied to .onion hostnames.

.onion does sound like a more serious problem. Would adding .onion to the list of TLD's Firefox decides not to fixup be an acceptable solution? Or should we consider that a separate ticket/issue?

Trac:
Priority: normal to major
Component: TorBrowserButton to Firefox Patch Issues

Yes, this is relation to .onion hostnames getting fixed up.

GIven how many .onion sites require an longer time to load, seems a reasonable fix to add .onion to the list of TLDs firefox does not fixup.

Trac:
Username: Casemon

I still see Tor Browser adding www. to .onion's when they time out (which happens quite often with hidden services).

This doesn't strike me as a security or privacy issue per-se. Patches welcome.

Trac:
Summary: TorButton should set browser.fixup.alternate.enabled to false to TorButton should not fixup .onion domains
Priority: major to normal
Owner: mikeperry to cypherpunks
Status: new to assigned

I think this is a rather bad security issue if we consider the SecureDrop use case:

https://github.com/freedomofpress/securedrop/issues/196

Trac:
Username: garrettr

dont_fixup_onions.patch

Don't run the "alternate URI" fixup logic for .onion URI's

Trac:
Username: garrettr

I just tested a few alternate .onion domains, some that simply don't exist and some that were invalid. In neither case did TBB seem to attempt a fixup to .com...

FWIW, I was testing on a FF24esr-based build. It's possible the fixup behavior has changed since FF17.

Trac:
Keywords: N/A deleted, tbb-firefox-patch added

Trac:
Component: Firefox Patch Issues to Tor Browser

Trac:
Keywords: N/A deleted, isec-audit, tbb-pref added

Trac:
Keywords: isec-audit deleted, tbb-isec-report added

Trac:
Cc: g.koppen@jondos.de to g.koppen@jondos.de, intrigeri

I just noticed a fixup happen in TBB 5.0 for a .onion domain. Either the behavior changed again in FF38, or this is extremely erratic. In any case, it seems like we should either disable it or apply garrett's patch.

Trac:
Keywords: N/A deleted, tbb-5.0-regression, TorBrowserTeam201508 added

I was not able to get fixups to happen with .onion domains in my 5.5a1 build. For regular domains, e.g., "store.apple", I could only get fixups to occur (e.g., add "www" prefix) when I hacked my browser to not use a proxy. Maybe there is some difference in DNS failure modes with Tor that causes the fixup code to not be executed most of the time.

In any case, I am not a fan of this feature. I always run with browser.fixup.alternate.enabled = false and would vote for making that the default in Tor Browser.

I wonder if anyone relies on this feature? Since we have keyword.enabled = true by default, single words will trigger a search. Is there a common situation where the fixup behavior is useful?

Move remaining August tickets to September.

Trac:
Keywords: TorBrowserTeam201508 deleted, TorBrowserTeam201509 added

Ok, I flipped the pref to disable fixup for 5.0.3 and 5.5a3. Pushed.

Trac:
Status: assigned to closed
Resolution: N/A to fixed

closed

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