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]
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
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
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.
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:
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.
As some of you have noticed, I have been working on an application called anon-connection-wizard as a Google Summer of Code(GSoC) project this year.
I was under the mentor and help of the Whonix core developer @Patrick, and so many other enthusiastic developers including but are not limited to @JasonJAyalaP , joysn1980, @HulaHoop from Whonix, and Sukhbir (sukhe) from the Tor project. I would like to say thank you to everyone who has helped me from my heart. Within such a supportive community, I enjoyed the development process so much that I kept experiencing flows.
This post, presenting in a Q&A form, is an introduction to the anon-connection-wizard which will be shipped with the upcoming Whonix 14! It is also a summary of the work I have done and the tasks I will be working on.
Q: What is anon-connection-wizard?
A: anon-connection-wizard is a python-based application that help users in different Internet environment connect to the Tor network. The followings are some screenshots of it which provides you with some visual impression on it:
Q: How does anon-connection-wizard work?
A: It will firstly ask users questions about their network environment, like whether they live in censored areas. And then, it will generate a .torrc file with the most suitable Tor configurations according to the answers from users.
Q: Isn’t it very similar to the Tor-launcher shipped with Tor Browser Bundle?
A: Yes, it does share several similar functions with the current Tor-launcher. I have been considering Tor-launcher as the upstream of anon-connection-wizard and trying to closely keep up and collaborate with their development.
Q: Why do we need anon-connection-wizard when we have already had Tor-launcher?
A: Because these two applications have very different use cases. Currently, the implementation of Tor-launcher heavily relies on the Tor Browser(which is based on Firefox). However, a Tor user does not necessarily be a Tor Browser Bundle user. There are still a large number of people I call system Tor users who would like to run core Tor with different torified applications. And these people (yes, you are one of them if you use Whonix!) may prefer anon-connection-wizard because it does not rely on Tor browser and all its dependencies have already been packaged into Debian.
Q: What works have you done during the summer?
A: anon-connection-wizard was originally developed by @troubadour as part of the Whonix Project. Some of the screenshots of its old version can be found in this Whonix blog post. In March, I completed the basic function and ported it from Python2 to Python3, from PyQt4 to PyQt5. During the summer, I made a huge amount of improvement and changes, which include:
Completely redesign anon-connection-wizard UI basing on Linda’s PET paper and Tor UX team’s proposal to new Tor-launcher.
Add a torrc page in anon-connection-wizard that allows users have an overview before connecting to the Tor network
Add serveral help buttons with detailed instructions to help users make decision
User input validation check
Let anon-connection-wizard remember user’s last time settings
Create a torrc_repair script that tries to fix corrupted .torrc files
implement bridge request via anon-connection-wizard once BridgeDB API is finished #15967
Q: What are you going to do in the future development?
A: The future goal of anon-connection-wizard is to be packaged as a generic standalone application into Debian so that it can be used by different anonymity focused distributions like Whonix and Tails. In order to achieve it, the following works need to be done:
package anon-connection-wizard as .deb
make anon-connection-wizard translatable
get anon-connection-wizard translated into different languages
after doing all the steps above, check if it can be helpful for Tails
What’s more, Tails developer anonym pointed out a promising future for the anon-connection-wizard on the tor-dev mailing list:
Any way, I also see potential for future collaboration between Whonix and Tails for extending the usefulness of anon-connection-wizard beyond what Tor Launcher (and its replacement) offers ; anon-connection-wizard targets the OS, not just a single application, so it could integrate the choices of network configuration (wired? which wireless network? MAC spoofing?) and Tor configuration (proxy? pluggable transport?) in a single place which probably makes more sense for users and also allows us to more easily (optionally) save these settings so they are restored the next time you visit the same network. This could potentially even be used to help giving users control over entry node selection to avoid persistent Entry Guards from leaking information about you geographical movement. 
Q: Can I get involved into the development of anon-connection-wizard, too?
A: Absolutely! Please let me say thank you for your interest in anon-connection-wizard! I was trying to keep most of my development communication public so that people like you can have a clear idea on how all the developing decisions have been made and how we have been communicating and cooperating with each other. Most of the discussions happened in these two places and a simple “hi, I think maybe I can help with…” is just enough to join us:
I’ve just wrapped up the third monthly Patreon Live Stream.
This time I covered the Reality Winner leaks, what kind of mistakes were done by the Intercept as well as her and why these leaks are going to have a hard time impacting a lot of people.
I’d like to note on that front that on two occasions during this stream, I made the mistake of stating Jeff Sessions occupation wrongly. This was a mistake on my part which does in no way change anything stated surrounding Sessions actions, though I still would like to apologize for making this mistake. Also, I’m starting to realize that I should attempt to suppress those “Um’s“ as they are beginning to be really annoying…
You may watch it now here: https://youtu.be/pb_BHUr00kg
If you would like to join us next time or you feel like supporting Whonix, please consider donating to our Patreon: https://www.patreon.com/whonix
All of the blame has unfairly been put on The Intercept for Reality Winner’s arrest to paint them as incompetent and scare away potential whistle-blowers. While yellow printer dots are one of the ways to trace the document to the source printer, its not the only one. Anyhow in the future The Intercept should consider posting transcribed data from originals they verified for authenticity instead.
Its probably certain that machines with Top Secret access are part of a comprehensive auditing framework which also combines data from mass surveillance on employees. For example an investigator can run a query for everyone who accessed the file AND who used Tor or started doing so recently from a location tied to them. Just like the Harvard student who sent the bomb threat was caught. The circumstantial evidence from this data narrows down the set of suspects and kills any plausible deniability.
Server applications using Tor ephemeral onion services such as ricochet-im, onionshare, ZeroNet and unMessage usually listen on localhost only, as Tor usually runs on the same system and is able to map them. However, due to Whonix’s split design, Tor runs on the Whonix-Gateway and the application runs on the Whonix-Workstation. This requires the application to listen on the Whonix-Workstation’s external network interface in order to allow the mapping from the Whonix-Gateway’s internal network interface.
At the moment, it looks like there is no convention to configure where these applications listen by default (localhost vs. all interfaces). The decision seems to be up to the upstream author of the software, as well as the packager. Then it’s up to the system administrator to decide on where the server application should listen, and currently there is not a great place for derivatives to globally modify this setting.
We believe that a solution to this problem is having a convention where listen config files for server applications are added to listen.d folders. Applications would then use a parser to read these configs in order to find, for example, which interface to listen on. This approach would prevent redundancy of application configs, support multiple systems, simplify applications development/packaging, as well as the system administration.
A specification for this convention has been devised, and we would like to present it after incorporating feedback from users of debian-devel.
What do you think of this proposal? Would you use it? Do you believe it can be improved? Please share your views in the Whonix forums.
Those of us following security news have heard about grsec’s decision by now.
If you are a current grsec sponsor reading this who doesn’t like their de-facto violation of kernel code licensing, I urge you to privately leak updated versions to Kees Cook (firstname.lastname@example.org) who can study and incorporate the code into mainline without endangering your access. This will free changes back to the community where they belong and in the long-term you won’t be forced to pay through the nose to run a secure kernel.
PaXTeam is making a false equivalency between their hostile actions and RedHat licensing. To be clear, the GPL does not restrict monetizing software. However businesses can still make handsome profits working around the license by providing support services. RedHat releases back source code – though not in the neat broken up patch-sets but they still release it which satisfies the GPL requirements. Grsec is creating a derivative work of GPL’d kernel code and then coercing customers to relinquish their freedoms.
Reminder: if it wasn’t for the GPL they wouldn’t have a codebase to secure in the first place. if they hate copy-left for being too permissive then they can feel free to fork a BSD kernel and copyright the hardened copy they make.
I think most can agree about where those GPL violators should stick their baton but I think there is a good side to all this. Its a painful reminder that unless code is mainlined and project’s contributions are up-streamed its only a matter of time before they disappear and the code is lost.
No doubt this will catalyze KSPP and bring more security to everyone instead of a select few who know how to tweak and compile a kernel. Another side effect is that protections will be rolled out for many more archs than with grsec support only covering x86 and x64.
Its worth reading Kees Cook’s (KSPP project leader) statement answering common accusations made by Spender and PaXTeam and parroted by their supporters who blame everyone else except their idols who stabbed them in the back.
Unlike the biased comparison on the grsec site, it seems KSPP has successfully integrated more features than they were credited. Much work still remains to be done but its definitely a good start. Its becoming clear that the real reason they closed their sources is in a desperate attempt to not become obsolete.
The Gentoo devs feel particularlybetrayed after dedicating lots of effort modifying their userland code to be compatible with PaX and being left out in the cold without warning.
This spawned the Hardened Kernel Project an emerging multi-distro (Gentoo, Arch and hopefully Debian) effort to help upstream as much code as possible. If you write kernel code this project can really use your help.
MAC Address Randomization: Not as Random as You Think
For privacy-minded individuals, randomization of Media Access Control (MAC) addresses for Wi-Fi networks and mobile devices has long been touted as a standard defensive technique. However, recent research  suggests that major flaws in implementation have left smartphone users defenseless and vulnerable to exploitation.
What is MAC Address Randomization?
All network interfaces on networked devices have a factory-assigned MAC address which is hard-coded on a network interface controller. In the case of smartphones using 802.11 (Wi-Fi) radio specifications,  devices have a 48-bit link-layer MAC address that functions as a globally unique identifier. The MAC address is sent in every link-layer frame sent to or from the mobile device. 
Smartphone behavior is distinct from general computing network cards (both wired and wireless), as the MAC address used to assign an address to your computer on the local network is not passively sent to computers beyond the local router. This means the MAC address is not traceable unless logged by other computers on the network.  
Smartphone behavior has grave privacy implications. Any network observer can eavesdrop on nearby Wi-Fi traffic, with pinpointing of this traffic to a uniquely identified device.  In addition to broadcasting of the MAC address ID, smartphones send probe requests that broadcast at a semi-constant rate, posing an even greater surveillance risk: 
… wireless devices identify access points within close proximity. Traditionally, devices perform active scanning where they broadcast probe request frames asking nearby APs to identify themselves and respond with 802.11 parameter information required for connection setup. These probe request frames require a source MAC address, but if an 802.11 device uses its globally unique MAC address then it is effectively broadcasting its identity at all times to any wireless receiver that is nearby. Wireless device users can then easily be tracked across temporal and spatial boundaries as their devices are transmitting with their unique identity.
In an attempt to solve this problem, most major smartphone device manufacturers and operating systems (Android, iOS etc.) have implemented protocols to create temporary, randomized MAC addresses that are distinct from the true global identifier. Randomized, pseudonym addresses are changed periodically to restrict third party tracking. 
In theory, observers of network traffic (like ISPs) should be prevented from singling out smartphone traffic or identifying the physical location from other nearby devices, because randomized MAC addresses shouldn’t be linkable to the previous address. 
The Flawed MAC Address Randomization Implementation
Transportation of network traffic without a static ID is a common sense approach for privacy advocates. Unfortunately, a recent study by the US Naval Academy shows the implementation of this technique in smartphones is seriously flawed across every OS platform, device manufacturer and model.
Using real-world datasets, the 2017 study found: 
Randomization techniques and schemes were easily identified from large collections of wireless traffic.
Adoption rates for MAC randomization are low, particularly for Android devices. 
Passive and active techniques for determining true global identifiers is a trivial task due to flawed MAC randomization implementations, particularly for Android devices. 
The global MAC address was discoverable via a “control frame attack”. This allows tracking/surveillance for all known devices, irrespective of the OS, manufacturer, device type or randomization scheme.
Smartphone chipsets were discovered to have a flaw in how they handled low-level control frames, allowing an identification rate of 100%. Considering previous studies exhibited “only” a 50% accuracy rate, and Android devices were susceptible even when Wi-Fi was disabled or Airplane Mode enabled, this is a devastating result for user privacy. 
Unfortunately, smartphone MAC address randomization policies are not universally adopted, nor particularly effective at eliminating privacy risks. Network adversaries currently have a smaller test set to contend with, making their job of identification easier. 
Standardized MAC address randomization needs to be correctly implemented on any mobile device using Wi-Fi, with the entire length of the MAC field used as randomization input. Unique methods of randomization simply increase the attacker’s chances of deanonymizing a user. 
Other critical changes for smartphone user privacy include: 
Random addresses for every probe request.
Removal of sequencing numbers from probe requests.
Removal of global MAC addresses from probe requests.
Elimination of directed probe requests for cellular offloading.
Redesign of chipset firmware to prevent RTS frames eliciting a CTS response while in State 1.
Convincing device manufacturers to implement MAC address randomization consistently across all devices is a large and improbable undertaking.  Without a solution on the horizon, users of mobile devices should expect to be uniquely fingerprinted. User behavior on mobile devices should be adjusted accordingly in response to this clear and present danger to user privacy.
Martin, J. et al. (2017). “A Study of MAC Address Randomization in Mobile Devices and When it Fails”. US Naval Academy.
If you’d like to join us, we’d be very grateful. Furthermore, this will be our first Patreon Stream. If you want to support us on Patreon, click here.
Remember that to watch the stream via the Tor Browser Bundle, you should set the Security Settings to Low (default).
Also, if you would like to talk to us or ask us a question, you may either post it in this thread, ask directly via the Youtube Chat or join us via OTR. To join us via OTR, simply sent a message to email@example.com via OTR.