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.
Even the smallest edit (such as fixing a typo) will add you to the list of editors.
At time of writing, there were only 13 editors. Your chance to get this bounty.
b) Another 500 ETH bounty will be distributed to the top 10 quality Wiki contributors, based on aeternity staff picks.
Since the evaluation of contributions can be quite subjective, please do not participate by making excessive Wiki edits solely for the bounty. Always keep in mind that your contribution might not get the appreciation that you think it deserves.
The bounty is open to everyone and will run until May 29, 2017.
This is a promotion of aeternity run by Simply VC Co Ltd.
Simply VC Co Ltd is invested in aeternity.
I am working for Simply VC Co Ltd. I am also a developer of Whonix, the anonymous operating system. (proof)
This bounty campaign however is unrelated to Whonix.
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.
Whonix is a project which requires a lot of dedication, passion and time to be properly maintained. Especially Patrick has sacrificed a huge part of his live to making a fail-safe way to use Tor accessible to as many people as possible.
For the last few years, he mainly was able to focus on the tasks required to maintain Whonix thanks to the dedication of individuals supporting Whonix either in the forum, wiki, on Github or on all three, as well as the occasional donations provided by generous donors. However, because of the nature of these donations, it continues to be challenging to focus on long time goals, seeing how it is hard to make extensive plans based on occasional monetary support.
Because of this, over the course of the last few months, we have looked into different ways of obtaining long term funding, either via government programs or by incentivising people to donate on a more regular basis. In the end, we decided to look into the latter, as it would enable us to have an even better communication with our community, wouldn’t in any way compromise the open and rather democratic structure currently in place for support and development and make it possible to give something back to our most generous supporters. It also would keep Whonix in the hands of our great community, instead of trusting a government organisation which may have different goals or requirements and would potentially force us to not act in the best interest of our users, by limiting our ability to implement the features we deem necessary.
To make this possible, we decided to team up with Patreon, a service which enables you to donate a certain amount of money every month. You are able to cancel your regular donation anytime you want and, best of all, will receive certain rewards by us if you decide to donate. These rewards all have the goal of both giving you an incentive to donate a bit to keep Whonix sustainable for the future and furthering the cause behind Whonix in general. You will be able to more directly decide on new features and may gain access to other rewards, like a monthly live stream in which Patrick Schleizer and I, Ego are going to cover certain topics related to Whonix, Tor, anonymity, journalism and cryptography, as well as answer question of Patrons.
Our complete list of rewards:
$1 Become A Patron
$5 Join the Monthly Livestream
$10 Priority Support
$15 Livestream Chat Access
$20 Immortalize yourself by becoming part of the Whonix Installer Source
$30 Vote on Features
$50 Personal Support
$100 Personalized Video Guide
$500+ Advertise on Whonix.org
Now, I am aware of what some of you may think right now.
Isn’t Patreon a service which requires the use of something traceable like a credit card or PayPal and don’t they use Cloudflare, the enemy of all Tor users?!
Yes, that is correct. Because of the fact that a lot of Whonix users are rather critical of services using Cloudflare, it was important for us to address this head on. Obviously, we can understand that a lot of users will not be able to use Patreon due to the fact that they require to stay as anonymous as possible. We understand that and will never ask someone who needs to stay anonymous to give up that anonymity, simply so we may get some cash. We also will continue to focus on keeping this subset of our user base, the one that really requires anonymity, as safe as possible.
If you are a user who has no issues with using a service like Patreon, would like to support Whonix and are able to do so, we would be very grateful if you could do so via a monthly donation.
Since it is quite a lot to ask you for money when you aren’t sure whether you will enjoy the rewards, we have decided to make our first monthly Whonix-Livestream open to anyone. It will be broadcasted via Youtube Live which you may access via the Tor Browser Bundle with Whonix and you may ask Patrick and me anything you’d like via OTR.