Disable update pings for Torbutton and Tor Launcher

added MikePerry201401R component::torbrowserbutton extdev-interview owner::mikeperry priority::very high resolution::fixed status::closed tbb-security type::defect labels

Trac:
Cc: N/A to gk

#10501 (closed) is related.

Disabling the ping is not so easy it turns out. The radio button you are alluding to just disables the auto-install of an update which gets fetched though, if available. (btw that pref is directly saved into the extensions.sqlite database (applyBackgroundUpdates)). If we already want to prevent the ping (which is a good idea IMO) we could just give Torbutton and TorLauncher a custom update URL pointing to our servers (and returning nothing) or just to 127.0.0.1. Not sure if the latter works at all but it might be the best solution if we avoid unnecessary update traffic in the first place.

Trac:
Keywords: N/A deleted, extdev-interview added

Trac:
0001-Ticket-10682-Set-dummy-update-URL-to-prevent-AMO-hij.patch

Hi! Made a quick patch to set updateURL to https://127.0.0.1 (FF doesn't let you install addons with protocol-less or HTTP updateURLs, it seems). Verified expected results with tshark on port 443 before/after applying the patch while manually forcing an update (right click on the addon in about:addons).

Anything other tests I should run?

That patch is for Torbutton; presumably should work for both if it works for either.

Trac:
Status: new to needs_review
Keywords: N/A deleted, MikePerry201401R added

FF doesn't let you install addons with protocol-less or HTTP updateURLs, it seems Why we need install addons? What happens if to use TBB with already "installed" such addons? If you tries to solve problem by breaking some functional then probably using TBB with updateURL that breaking any tries to fetch would be better?

What happens if to use TBB with already "installed" such addons? Found answer. It disables addon.

Then if to fetch (even for localhost, it still fetches) something then probably protect it by large enough broken update key.

broken update key. and yet to use banned port

<em:updateURL>https://127.0.0.1:9050/</em:updateURL>

banned_ports affects it?

Set pref "extensions.logging.enabled" to true, and look at the Firefox menu | Developer | Browser Console. Note, though, that SSL cert errors will not show up anywhere - that's a Firefox bug.

Trac:
Username: ben

Break updates properly or nothing. It's better to fetch from AMO, at least guids blocked right now, than to fetch from unknown place for real.

Trac:
Status: needs_review to new

Well, due to the fix for #10419 (closed), these requests are in fact broken. The browser will no longer connect to directly to 127.0.0.1, nor will connections to 127.0.0.1 be sent to the exit node, unless the user edits their torrc to set 'ExtendAllowPrivateAddresses 1' for some reason. So this should certainly be an improvement

If you want defense in depth against people who reconfigure Tor/Firefox, we can also use a banned port too instead of 443, but this fix is already in 3.5.2, which we shouldn't delay any further without compelling reason because it contains security fixes for Firefox 24.3.0.

Would you consider a banned port to be an improvement? If so, we can file a new ticket and I will commit that immediately for 3.5.3.

How about https://127.0.0.1:0 ? In my standard Firefox, 0 seems to be a banned port. I concur with cyberpunks that it's better to use a wrong port than a real one.

Trac:
Username: ben

fix for #10419 (closed) Security hole.

ExtendAllowPrivateAddresses no. ClientRejectInternalAddresses

The browser will no longer connect to directly to 127.0.0.1, nor will connections to 127.0.0.1 be sent to the exit node It's all depends Tor not Torbrowser that has security hole with passing localhost over proxy.

https://127.0.0.1:0 TBB not get it like valid URL, passing it to search engine.

Replying to cypherpunks:

fix for #10419 (closed) Security hole.

Can you explain how this fix is a security hole?

ExtendAllowPrivateAddresses no. ClientRejectInternalAddresses

Sorry, pasted the server side option. But it is still blocked by the Tor client by default.

The browser will no longer connect to directly to 127.0.0.1, nor will connections to 127.0.0.1 be sent to the exit node It's all depends Tor not Torbrowser that has security hole with passing localhost over proxy.

Fair enough, I guess if people want to extend Tor Browser to support other SOCKS proxies, I would not refuse patches that made that more secure or functional. But it is not a development priority at this point for us to do this.

It also sounds like you are now asking for an additional patch that completely blocks 127.0.0.1 from the browser independent of addon update URLs? Should we also extend that patch to block all RFC1918 addresses from the browser, too? This definitely sounds like a separate ticket.

https://127.0.0.1:0 TBB not get it like valid URL, passing it to search engine.

There are banned ports that are hardcoded in Firefox, like 25. Should we use one of those instead?

mikeperry: the hardcoded banned port list is at: http://mxr.mozilla.org/comm-central/source/mozilla/netwerk/base/src/nsIOService.cpp#69

Trac:
Username: ben

Can you explain how this fix is a security hole? Communicating with localhost over proxy is security hole. Torbrowser not Tor. It's ok Tor client prevents localhost connection attempts, but this have nothing with browser security. You patches browser for dns leaks but why if user could to use tails or netfilter? Because design of Torbrowser.

I think cypherpunks is worried that for whatever reason (bug, misconfiguration, etc.), Tor might actually answer on that https://localhost:9050/ request - and somehow allow an attacker to deliver an XPI, which will then be installed. For that to happen, Tor would need to speak SSL and present a proper cert (signed by a CA that Firefox has built in). I think the chance of all that coming together is almost nil, but I agree that it's safer to use a port where no server is listening.

Trac:
Username: ben

While we're at it, I think it's safer to do the same for all extensions that are shipped with Tor, including HTTPS Everywhere and noscript. If I'm coming out of an tor exit node asking for an update for my noscript, that's an easy way to get me. The SSL certs are checked, but I think all built-in CAs are accepted by Firefox.

Trac:
Username: ben

HTTPS Everywhere already has an updateURL and updateKey, since EFF self-hosts it.

Ah, indeed, an updateKey is more secure than simple SSL with CAs. https://developer.mozilla.org/de/docs/McCoy noscript (coming with my TBB) doesn't have an updateURL, though, so it would update via AMO (addons.mozilla.org), which means the security of Tor users depends on AMO infrastructure.

Trac:
Username: ben