Make Tor Browser's updater work over Hidden Services

This would provide additional cover traffic for other HSes. Another proposal from the (second) HS guard discovery protections meeting at the 2015 Berlin Tor developer meeting was to only have clients check for new Tor Browser updates via some HS(es), and then do the actual download of the update over the regular non-HS mirrors.

added TorBrowserTeam201901 component::applications/tor browser owner::tbb-team points::medium priority::medium severity::normal status::new tbb-security tbb-update tor-hs type::enhancement labels

since updates can be a high lattency application the download process could be split in a randomized pattern and thus be more difficult to filter out of a traffic analysis.

Trac:
Username: elypter

Seems #10391 (moved) is now a duplicate of this one.

Trac:
Cc: isis, asn, special, mikeperry to isis, asn, special, mikeperry, gk

Trac:
Cc: isis, asn, special, mikeperry, gk to isis, asn, special, mikeperry, gk, mcs, brade, whonix-devel@whonix.org

Another thing to add (from an email that was sent to tor-dev):

This is far easier to do for the Torbutton RecommendedTBBVersions fetch since the updater has special cert pinning that would need to be altered for hidden services.

Trac:
Severity: N/A to Normal
Reviewer: N/A to N/A
Cc: isis, asn, special, mikeperry, gk, mcs, brade, whonix-devel@whonix.org to isis, asn, special, mikeperry, gk, mcs, brade, whonix-devel@whonix.org, boklm

Not an expert, but should this be postponed until prop 224 and all related HS props that are nearly complete are deployed? I know HS as it is now is still probably as secure or more than a clearnet site but would like to hear whether it is in theory safer to do so then.

#19927 (moved) is a duplicate.

#23131 (moved) is a duplicate.

#25078 (moved) is a duplicate.

I'd like to test this out, first in the alpha series, sooner than later. The idea would be to fetch the metadata file (update.xml) over .onion which is a pretty small file (around 1000 bytes) but not the full update. I am in particular concerned about TLS being the means of authenticating the contents of that xml file and think we can do better with an .onion responsible for that.

weasel, ln5: do you feel the current .onion setup for aus1 is robust enough for that test? Should we wait until we have v3 services available? Or...?

Any other concerns?

Trac:
Keywords: N/A deleted, TorBrowserTeam201901 added
Status: new to needs_information
Cc: isis, asn, special, mikeperry, gk, mcs, brade, whonix-devel@whonix.org, boklm to isis, asn, special, mikeperry, gk, mcs, brade, whonix-devel@whonix.org, boklm, weasel, ln5

Trac:
Keywords: N/A deleted, tbb-updater added

Renaming keyword to make it a bit broader

Trac:
Keywords: tor-hs tbb-security, tbb-updater deleted, tor-hs, tbb-update, tbb-security added

Hi!

Replying to gk:

I'd like to test this out, first in the alpha series, sooner than later. The idea would be to fetch the metadata file (update.xml) over .onion which is a pretty small file (around 1000 bytes) but not the full update. I am in particular concerned about TLS being the means of authenticating the contents of that xml file and think we can do better with an .onion responsible for that.

weasel, ln5: do you feel the current .onion setup for aus1 is robust enough for that test? Should we wait until we have v3 services available? Or...?

We discussed this in Brussels a bit. It is our current consensus that the onion service providing aus1.tpo is not suitable for this purpose.

The onion service is backed by onionbalance, which appears to be unmaintained upstream and which does not support v3 onion services. Furthermore, in order for us to be comfortable relying and depending on an onion service for such an important purpose, we would want that onionbalance itself could be run in a distributed/redundant way such that we would not have any SPoFs.

Once these issues are addressed, we can reconsider the issue. For now, however, we recommend you not rely on the onion for updates.

Cheers,

Trac:
Status: needs_information to new

mentioned in issue #19927 (moved)

mentioned in issue #23131 (moved)

mentioned in issue #25078 (moved)

mentioned in issue #25146 (moved)

moved to tpo/applications/tor-browser#17216