meek_lite: A New Pluggable Transport in Whonix 14
Greetings Whonix users!
The Whonix development team is thrilled to announce that a new pluggable transport called meek_lite will be available in Whonix 14. This blog post will briefly describe meek_lite and how it can be easily configured in the forthcoming Whonix release.
What are Pluggable Transports?
In many parts of the globe, direct connections to the Tor network are censored. It is simple for censors to use technology to block connections, because it only requires maintenance of a real-time blacklist of all [https://atlas.torproject.org/ publicly known] Tor (guard) relays and directory authorities.
In order to try and solve this problem, the Tor Project developed and implemented the bridge protocol. Tor bridges (“Tor bridge relays”) are alternative entry points to the Tor network, not all of which are listed publicly. Readers might already be familiar with the “vanilla” obfuscated bridges - obfs2, obfs3, obfs4 - which are available from the Tor Project via private channels, email and the Tor Project bridge database.
Unfortunately, these bridges have several limitations: [ref]https://whonix.org/wiki/Bridges [/ref]
- Bridges are less reliable and tend to have lower performance than other entry points.
- There is no guarantee bridges will hide Tor and Whonix from ISP level observers - deep packet inspection may quickly reveal Tor traffic, and then block it.
- Aggressive censors can gradually block known public bridges by requesting the same information from the [https://bridges.torproject.org/ Tor Project BridgeDB], as any normal user would do. [ref]Thus the documented Whonix recommendation to use private obfuscated bridges whenever possible.[/ref] [ref]BridgeDB has adopted various methods to stymie adversaries. For instance, email requests must come from certain providers, and algorithms were developed that reject requests for a large number of different bridges within a short period.[/ref]
As David Fifield has [https://lists.torproject.org/pipermail/tor-dev/2017-August/012400.html noted on the @tor-dev mailing list]:
We know that at least China and Kazakhstan pay attention to the default Tor Browser bridges (and China blocks them as soon as they enter the source code, even before a release).
Tor developers have recognized that security by obscurity has failed many bridge users, because most are still blocked in repressive environments. This has lead to the development of [https://www.torproject.org/docs/pluggable-transports.html.en Pluggable Transports (PTs)], which help to circumvent censorship by transforming the Tor traffic flow between the Tor client and the bridge so it appears to be “innocent” network traffic, instead of the actual Tor traffic. [ref]https://www.torproject.org/docs/pluggable-transports.html.en [/ref]
Unique meek_lite Features
Unlike traditional bridges, meek_lite utilizes the concept of collateral freedom. The basic design is outlined in the [https://trac.torproject.org/projects/tor/wiki/doc/meek Tor Wiki]:
“[t]raffic is relayed through a third-party server that is hard to block, for example a CDN. It uses a trick called domain fronting to talk to a Tor relay while appearing to talk to another domain”.
meek_lite has recently proven to perform better in circumventing censorship than other methods. For example, during the 19th National Congress of the Communist Party of China held last month, meek was one of the few effective tools to bypass strengthened Internet censorship.
Differences between meek_lite and meek
Tor Browser Bundle users may be familiar with the meek PT. meek_lite is a different implementation of meek created by Yawning from the Tor Project. Yawning provides a [https://github.com/Yawning/obfs4/commit/611205be681322883a4d73dd00fcb13c4352fe53 succinct description of the differences]:
This is a meek client only implementation, with the following
differences with dcf’s meek-client:
It is named meek_lite to differentiate it from the real thing.
It does not support using an external helper to normalize TLS
signatures, so adversaries can look for someone using the Go
TLS library to do HTTP.
It does the right thing with TOR_PT_PROXY, even when a helper is
Most of the credit goes to dcf, who’s code I librerally cribbed and
stole. It is intended primarily as a “better than nothing” option
for enviornments that do not or can not presently use an external
It should be understood that meek_lite does not normalize TLS signatures, but it is still effective enough to help users bypass most forms of censorship. Major software projects like Orbot have come to rely on meek_lite, providing support for its capabilities.
Why meek_lite is Important to Whonix
Prior to Whonix 14, censored users were limited to two possible configurations for system Tor: either obfs3 or obfs4 bridges. The integration of meek_lite into the Whonix ecosystem greatly improves both functionality and the user experience for those living in heavily censored areas:
Configuring meek_lite in Whonix
Once Whonix 14 is released, users can configure Tor to use meek_lite in one of two ways. Both methods have been documented in the Whonix Wiki.
Option 1: Edit the /etc/tor/torrc file manually
Add the following lines to the /etc/tor/torrc file:
ClientTransportPlugin meek_lite exec /usr/bin/obfs4proxy
Bridge meek_lite 0.0.2.0:2 B9E7141C594AF25699E0079C1F0146F409495296 url=https://d2cly7j4zqgua7.cloudfront.net/ front=a0.awsstatic.com
Then reload Tor.
Option 2: Use Anon-Connection-Wizard
Open Anon-Connection-Wizard, and select meek-amazon or meek-azure as the bridge type in the Tor Bridges Configuration Page:
Intended Target Group
Users should consider the following recommendations when deciding whether or not to use a PT:
- If you are not living in a censored area, it is neither necessary nor recommended to use a PT.
- If you are living in a censored area where obfs4 works, then use it in the first instance.
- If you are living in a censored area where obfs4 does not work, try meek/meek_lite.
meek_lite Whonix Development
Integration of meek_lite into Whonix 14 would simply not have been possible without the cooperation and support of developers from many different communities, including the Tor Project, Debian, Tails and Whonix. I have attempted to maintain a near-complete record of this project’s development in the following Whonix forum post: [graphical gui] Whonix Setup Wizard / Anon Connection Wizard - Technical Discussion
On a personal level, I have immensely enjoyed making contributions within an efficient, supportive and encouraging environment. I urge my fellow developers to consider joining the collaborative Whonix effort by getting in contact!