wkrp
commented
4 years ago MassBrowser was the topic of the 2020-04-30 session of the Tor anti-censorship team reading group. Meeting log. Some topics covered:
- MassBrowser is similar to Snowflake in some ways, viz. in its use of volunteer proxies and domain-fronted communication with the Operator (in Snowflake a similar component is called the broker). Client-to-Client proxying is a notable feature that doesn't have a parallel in Snowflake.
- Matching peers by their NAT characteristics is a cool idea; how does that work technically?
- Because the Client includes a browser, how do security updates work? Looks like it uses an electron-updater package.
- From personal conversation, it sounds as if Buddies were at one time web browser extensions before evolving into their current standalone form.
- MassBrowser is getting a security audit from Subgraph.
- There was some confusion about how Client-to-Client proxying interacts with content category whitelisting and the list of known-blocked sites. For a Client in China to read a Chinese news site through another Client in Iran, it seems that the Operator would need to know more than the "News" content category and the fact that the site is blocked in China; it would also need to know that the Client acting as a Buddy is located somewhere where the site is not blocked.
- The claim, in e.g. §V-B and §VII-C, that censors cannot block residential peer-to-peer connections, is still untested, as the group sees it. The collateral damage argument may have more to do with the agility of changing Buddy addresses rather than the utility of any single Buddy address (NATed or not): if the Buddies sparsely occupy a large address space, it can be hard to write a rule to block them without blocking something else important. But even the agility argument is untested (as in Snowflake): how often do Buddies/proxies actually change their address? The group outlined some research avenues for investigating this.
MassBrowser: Unblocking the Censored Web for the Masses, by the Masses Milad Nasr, Hadi Zolfaghari, Amir Houmansadr, Amirhossein Ghafari https://censorbib.nymity.ch/#Nasr2020a https://massbrowser.cs.umass.edu/
MassBrowser is a multi-modal circumvention system that aims to overcome the deficiencies of other systems by combining many circumvention techniques: selective proxying, CacheBrowsing (Holowczak and Houmansadr 2015, Zolfaghari and Houmansadr 2016), domain fronting, volunteer proxies, and user-to-user proxying. It is designed to be difficult to block, provide high quality of service, be easy to deploy and cheap to operate, and enable users to control their level of privacy. The main design principle of MassBrowser is that circumvention systems should concentrate on providing blocking resistance only, with anonymity and privacy being optional features. The system has operated as an invitation-only beta for more than a year.
The system consists of censored Clients, volunteer proxies called Buddies, and a collection of backend infrastructure called the Operator (Fig. 1). Whenever a Client needs to connect to some destination, it considers a prioritized list of connection options, preferring options that have lower cost and higher performance (Fig. 4):
The Operator is the arbiter of what destinations are considered blocked or CacheBrowseable. The operator sources this information from ICLab and GreatFire, together with its own web crawls. Clients download this information from the Operator and refresh their local cache of it periodically. Clients' communication with the Operator is protected by domain fronting, though any other unblockable channel (even a low-bandwidth or high-latency one) would work. Because a Client's routing decisions depend on what destinations are being accessed, the MassBrowser Client software needs to be able to inspect traffic, even encrypted traffic. To that end, the Client installs a local root TLS certificate and does TLS interception of everything that flows through the Client software.
To become a Buddy, a person downloads and runs the standalone MassBrowser Buddy software. Communication between Clients and Buddies is encrypted and obfuscated using an obfsproxy-like modular transport; because the Buddy software is not a browser extension, it is not limited to using web protocols like WebRTC and can be freer in its obfuscation. Clients may also use other censored Clients as Buddies; the intuition is that what is blocked in one censored network is usually not blocked in another. A Buddy is a one-hop proxy: it has the ability to inspect traffic, and any outgoing connections will be attributed to the Buddy. Buddies can express a whitelist of content categories they are willing to proxy; how it works is the Client contacts the Operator and says "I need to access a Gaming destination," and then the operator matches the Client with a Buddy that has whitelisted the Gaming category. Certain content categories (pornography) are never proxied through one-hop Buddies but instead always go through a Tor tunnel. Besides content categories, the Operator considers compatibility of NATs and the current load on each Buddy when matching Clients with Buddies, and uses the Enemy at the Gateways proxy distribution mechanism to mitigate the risk of Buddy-discovery attacks.
Thanks to Amir Houmansadr for commenting on a draft of this summary.