meek_lite: A New Pluggable Transport in Whonix 14

Originally published at: News - Whonix Forum

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 publicly known Tor (guard) relays and directory authorities.

In order to try and solve this problem, the Tor project came up with the idea of making a proportion of Tor guard relays only available via relatively private channels. However, since these alternative guard relays ("vanilla bridges") use the same protocol to communicate with the Tor clients as normal guard relays, a censor can simply identify the Tor signature of the network connection and then block it.

Tor developers have recognized that security by obscurity has failed many bridge users, because most are still blocked in repressive environments. This has led to the development of 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.

Unfortunately, traditional obfusticated bridges - obfs2, obfs3, obfs4 - still depend on censors being unaware of bridge information (like the IP address), which is still a security by obscurity approach. This allows aggressive censors to gradually block known obfusticated bridges by requesting the same information from the Tor Project BridgeDB, as any normal user would do. [^1]

Additionally, as David Fifield has 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).

Unique meek_lite Features

Unlike traditional bridges, meek_lite utilizes the concept of collateral freedom. The basic design is outlined in the 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 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 TORPTPROXY, even when a helper is not present.

Most of the credit goes to dcf, who's code I librerally cribbed and stole. It is intended primarily as a "better than nothina" option for enviornments that do not or can not presently use an external Firefox helper.

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:

  • In some jurisdictions like China, meek_lite is the only Tor PT that is currently effective.
  • Forthcoming features of Tor launcher / Anon Connection Wizard enable meek_lite to automatically retrieve Tor bridges.

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. It is recommended to check the Wiki since it will be up-to-date, unlike this blog post.

Option 1: Edit the /etc/torrc.d/50_user.torrc file manually

Beginning from Whonix 14, it is recommended to place all user customized Tor configurations into /etc/torrc.d/50_user.torrc.

Add the following lines to the /etc/torrc.d/50_user.torrc file:

DisableNetwork 0 UseBridges 1 ClientTransportPlugin meeklite exec /usr/bin/obfs4proxy Bridge meeklite 0.0.2.0:2 B9E7141C594AF25699E0079C1F0146F409495296 url=https://d2cly7j4zqgua7.cloudfront.net/ front=a0.awsstatic.com

Then reload Tor.

Option 2 (Preferred): 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 this Whonix forum post.

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!

[^1]: 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.

2 Likes

Good work! Some minor nits.

Change:

To order to try and solve this problem, the Tor project came up with the idea to remain part of the Tor guard relays only available via relatively private channels. Hoewever, since these alternative guard relays, called vanilla bridges, use the same protocal to communicate with the Tor clients as normal gurard relays use, a censor can simply identify the connection is Tor traffic and then block it.

To:

In order to try and solve this problem, the Tor project came up with the idea of making a proportion of Tor guard relays only available via relatively private channels. However, since these alternative guard relays (“vanilla bridges”) use the same protocol to communicate with the Tor clients as normal guard relays, a censor can simply identify the Tor signature of the network connection and then block it.

Change:

Unfortunately, traditional obfusticated bridges - obfs2, obfs3, obfs4 - still rely on the hope that censors do not know the information (for example, IP address of the bridges), which is, still, security by obscurity. This allows aggressive censors gradually block known those obfusticated bridges by requesting the same information from the [https://bridges.torproject.org/ Tor Project BridgeDB], as any normal user would do.

To:

Unfortunately, traditional obfusticated bridges - obfs2, obfs3, obfs4 - still depend on censors being unaware of bridge information (like the IP address), which is still a security by obscurity approach. This allows aggressive censors to gradually block known obfusticated bridges by requesting the same information from the [https://bridges.torproject.org/ Tor Project BridgeDB], as any normal user would do.

Change:

Begin from Whonix 14, it is recommended to place all user’s own Tor configuration into /etc/torrc.d/50_user.torrc.

To:

Beginning from Whonix 14, it is recommended to place all customized Tor configurations into /etc/torrc.d/50_user.torrc.

Thank you so much for your revision, @torjunkie ! I have updated the blog post.

I changed this one:

to:

Because there will be many different customized files created by users, Debian and Whonix. :slight_smile:

1 Like