GSoC with Tor and Whonix: Anon-Connection-Wizard

Hello everyone! I am iry.

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
  • Improve and add features to the tor_status.py
  • torrc.d feature request against Debian Tor package
  • Switch from overwriting .torrc approach to edit-mark approach, and then to torrc.d approach
  • Shipping default Tor bridges request
  • Update default provided Tor bridges

All my commits in the summer can be found in this pull request which has been merged into the Whonix repository.

I also wrote bi-week reports to @tor-project mailing list, which have been recorded on GSoC page in Tor wiki.

Q: What is your next step on anon-connection-wizard?

A: I will still be working on my Github repository and the following features will be implemented in the near future :

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 [2]; 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. [3]

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:

  1. [graphical gui] Whonix Setup Wizard / Anon Connection Wizard – Technical Discussion
  2. review and merge anon-connection-wizard pull request by iry

Note that offering feedback, testing, developing, packaging, porting and translating are all ways to contribute and will all be welcomed!

Q: What other work have you done during the summer?

A: Like what I said in my GSoC proposal:

I never consider my project as a one-time project. Instead, I consider it as an important step to help myself get more involved in the Tor/Whonix community.

I was trying to jump into and follow up many different parts of the Tor and Whonix community. For those who may be interested, here are some links:

  • Github: @irykoon
  • Whonix Forum: @iry
  • Whonix Phabricator: @iry
  • Tor trac: @iry
  • Tor Mailing lists: iry at riseup dot net
Posted in Whonix New Features Tagged with: , ,

Whonix Livestream 17.June.2017 – Let’s talk Reality Winner

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

Posted in General Security News

In Defense of The Intercept on the Reality Winner Case

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.

She also did a lot of fatal mistakes during and after leaking:

* Searched on her work computer how to evade warnings from auditing systems.
* Spilled the beans on what she did and her planned defense on prison phones (or any phone for that matter)

No one is born knowing good opsec but I wonder if we missed an opportunity to make our documentation on the topic more accessible to users.

Posted in Uncategorized

Listen Port Convention

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.

Posted in Contribute, Whonix Development News

2nd Patreon Stream Now Public – Let’s talk Quantum

I’ve just wrapped up the second monthly Patreon Live Stream, this time sadly without Patrick, due to an error on my part.

This time I covered quantum computing, its threats for current encryption and verification standards and what it is going to mean for the future.

You may watch it now here: https://www.youtube.com/watch?v=Mt3yWqwNMzc

 

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

Posted in General Security News

Beyond #Grsecurity: The Future of Linux security is Brighter than Ever

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 (keescook@chromium.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 particularly betrayed 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.

Posted in Contribute, General Security News, Uncategorized

BOUNTY – easy aeternity wiki editing bounty

This is a sponsored blog post.

In total there are 1000 ETH bounty to be shared.

a) 500 ETH will be shared among all wiki editors

You can easily get ETH by contributing to the wiki of aeternity.

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.

The terms and conditions can be found in the æternity Wiki Bounty Campaign blog post.


The Wiki bounty is sponsored by Simply VC Co Ltd, a subsidiary of Simply Holding Co Ltd.

This is a promotion of aeternity run by Simply VC Co Ltd.


Background:
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.

Posted in Uncategorized

MAC Address Randomization: Not as Random as You Think

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 [1] 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, [2] 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. [3]

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. [4]
[5]

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

… 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. [8]

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. [9]

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: [10]

  • Randomization techniques and schemes were easily identified from large collections of wireless traffic.
  • Adoption rates for MAC randomization are low, particularly for Android devices. [11]
  • Passive and active techniques for determining true global identifiers is a trivial task due to flawed MAC randomization implementations, particularly for Android devices. [12]
  • 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. [13]

Conclusion

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. [14]

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. [15]

Other critical changes for smartphone user privacy include: [16] [17]

  • 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. [18] 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.

Primary Source

Martin, J. et al. (2017). “A Study of MAC Address Randomization in Mobile Devices and When it Fails”. US Naval Academy.


  1. https://arxiv.org/pdf/1703.02874v1.pdf
  2. https://en.wikipedia.org/wiki/IEEE_802.11
  3. https://arxiv.org/pdf/1703.02874v1.pdf
  4. Unfortunately, due to weaknesses in current spoofing methods it is likely the MAC address can be enumerated via the physical characteristics of the Wi-Fi card. https://www.whonix.org/wiki/Computer_Security_Education#Introduction_2
  5. Spoofing is only necessary if you expect to travel with your laptop or PC. It is not required for home PCs that do not change locations. For further information on spoofing MAC addresses in Whonix, see https://www.whonix.org/wiki/Computer_Security_Education#MAC_Address
  6. https://arxiv.org/pdf/1703.02874v1.pdf
  7. https://arxiv.org/pdf/1703.02874v1.pdf
  8. https://en.wikipedia.org/wiki/MAC_spoofing#MAC_Address_Randomization_in_WiFi
  9. https://arxiv.org/pdf/1703.02874v1.pdf
  10. https://arxiv.org/pdf/1703.02874v1.pdf
  11. Possibly due to chipset and firmware incompatibilities.
  12. Notably, Samsung devices were never observed to perform MAC randomization, despite being the leading manufacturer of Android devices.
  13. https://securityintelligence.com/news/mac-address-randomization-gets-clobbered/
  14. https://arxiv.org/pdf/1703.02874v1.pdf
  15. https://arxiv.org/pdf/1703.02874v1.pdf
  16. https://arxiv.org/pdf/1703.02874v1.pdf
  17. See the original paper for further discussion of these issues.
  18. https://securityintelligence.com/news/mac-address-randomization-gets-clobbered/
Posted in General Security News

Livestream NOW!

Patrick and I are going stream ourselves NOW under this address: http://www.youtube.com/channel/UCh6htf3E721zcvahGLxFl9w/live

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 egowhonix@jabber.at via OTR.

Posted in Contribute, General Security News

Public Livestream on 14th of April at 8PM CEST and Patreon

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.

To join our livestream, simply visit Youtube via this link on Friday, the 14th of April at 8PM Central European Summer Time: http://www.youtube.com/channel/UCh6htf3E721zcvahGLxFl9w/live

For our American users, that would be 2PM Eastern Time. If you click on the link, there is also a timer to show you when the stream will start.

We hope to see many of you join our stream. If you miss it, you will be able to watch it later on our Youtube Channel were every stream will be publicly available after the fact.

In conclusion, we hope that you will enjoy using Whonix for years to come and would be thankful for any support, no matter how small.

Our Patreon may be found here: https://www.patreon.com/whonix

Posted in Contribute, Whonix Important News