Tor Onion Services as Anti-DDoS Protection

The more widely known feature of Onion Services besides anonymity is the free and trustworthy end-to-end encryption they provide which is impossible to have under the Certificate Authority racket.

Another interesting property is they can serve as a drop-in Global Server Load Balancing and Layer 3 DDoS-resistance solution. In short a a free and libre CDN alternative to tyrants like Cloudflare. It can protect your site without compromising on principles like complete and unhindered access for your your users and readers.

This was recently brought up by network scaling engineer, Alec Muffett who contributed much code to make it possible to run heavy traffic Onion Sites.

Posted in General Security News

Advanced Deanonymization Attacks

A number of advanced deanonymization attacks. These do not just apply to Whonix, but any anonymity system. Some are also general security issues.

Rather than exploiting bugs in the hypervisor to break out, some of these attacks rely on the design of the underlying hardware to bypass privilege separation boundaries and extract (or leak) sensitive information to the network. No need for alarm, there are many qualifications to this and details in the listed tickets on proposed countermeasures. We are interested in cooperation to better assess the performance impact of the planned fixes.

  • Keystroke Deanonymization: T542
  • Advanced Attacks Meta ticket: T540
    • CPU-induced latency Covert Channel: T530
    • Cross-VM cache attacks countermeasures: T539
    • DRAMA: Exploiting DRAM Addressing for Cross-CPU Attacks: T541
    • TCP ISNs and Temperature induced clock skews: T543

 

Posted in Uncategorized

Qubes-Whonix 13.0.0.1.2 TemplateVMs – Testers Wanted!

Qubes-Whonix only!

Ideally for this testers wanted task, start fresh. Rename or delete both Whonix VMs sys-whonix and anon-whonix, reinstall whonix-gw and whonix-ws Qubes-Whonix templates. See the following instructions. Note: use qubes-dom0-unstable rather than qubes-templates-community then recreate Whonix VMs.

https://www.qubes-os.org/doc/reinstall-template/

(The following command deviates from the above instructions so you install the testers rather than stable Whonix templates.)

sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable qubes-template-whonix-gw qubes-template-whonix-ws

After template re-installation, to re-create Whonix VMs you can use the following command in Qubes dom0 using salt (not yet mentioned in Qubes documentation).

sudo qubesctl state.highstate

(Or you can also upgrade from Whonix jessie-proposed-updates and testers repository. Dedicated blog post and more information on this upgrade:
https://www.whonix.org/blog/testers-wanted-repo-upgrades)

Posted in Qubes-Whonix News, Testers wanted!

Testers wanted! Tor, anon-gw-anoynmizer-config and qubes-whonix upgrades

Upgraded packages have been added to Whonix jessie-proposed-updates and testers repository.

  • newer Tor version 0.2.8.6-1~d80.jessie+1
  • anon-gw-anoynmizer-config 1.9.2 – bugfix
  • newer qubes-whonix version 5.7-1 – It contains various bug fixes to ensure Qubes R3.2 compatibility.

If you can, please enable such a repository and help test this.

Posted in Qubes-Whonix News, Testers wanted!

corridor, a Tor traffic whitelisting gateway, a clearnet leak tester

After making the second step, posting how to use corridor, a Tor traffic whitelisting gateway with Qubes-Whonix, I will hereby do the first step, posting a general announcement of an interesting third party project, corridor. Please forget about Whonix for a moment, and I will explain what the corridor project by default is doing.

corridor is a Tor traffic whitelisting gateway. It is a filtering gateway. Not a proxying gateway.

corridor can be used to check systems / programs that should cause only Tor traffic for leaks. corridor can log any clearnet, non-Tor traffic and will block it.

Ideally, corridor gets installed on a physically isolated device running Debian with two network adapters. Let’s call that corridor-Gateway. Then start Tails, TBB or Whonix behind such a corridor-Gateway. Should there be any accidental clearnet traffic (leaks), then corridor could log it and would block it.

Alternatively, corridor can be installed in a Debian based VM. Another VM could run Tails, TBB or Whonix-Gateway. These VMs would be configured to connect through corridor-Gateway.

In pure corridor, non-Whonix terms, let’s call these VMs corridor-Gateway and corridor-Workstation.

In a corridor like setup, it is up to the coridor-Workstation to run its own Tor client to establish connections. The corridor-Gateway will run its own, separate Tor client. For the simplicity of the design, corridor-Workstation does not have access to Tor’s ControlPort running on corridor-Gateway. Again, corridor-Gateway is not a proxying gateway, it is a filtering gateway. The main purpose of the Tor client running on corridor-Gateway is to know obtain the current list of Tor entry guards. corridor-Gateway’s firewall restricts all outgoing connections to Tor relays [or Tor bridges].

This is not necessarily more anonymous. It is an additional fail-save Tor traffic whitelisting firewall that would protect from accidental clearnet leaks (hypothetical clearnet leak bugs in TBB, Tails or Whonix). As corridor’s project description states, quote “it cannot prevent malware on a client computer from finding out your clearnet IP address”.

corridor is mostly useful for developers and auditors of TBB, Tails or Whonix, perhaps also for advanced users who would like to have an additional safety net.

Quote corridor readme:

“corridor is not a replacement for using a well-designed operating system on your client computers, like Qubes with TorVM/Whonix.”

corridor cannot sit between Whonix-Gateway and Whonix-Workstation. That would make no sense in combination with the Whonix design.

Credits: The author of corridor is rustybird. The author of fork of corridor for Debian is Patrick Schleizer.

If you like Whonix, please support it.

 

Posted in Uncategorized

Using corridor, a Tor traffic whitelisting gateway with Qubes-Whonix

corridor is a Tor traffic whitelisting gateway. It is a filtering gateway. Not a proxying gateway.

It can also be used as a BridgeFirewall.

This is not necessarily more anonymous. It is an additional fail-save Tor traffic whitelisting firewall that would protect from accidental clearnet leaks (hypothetical clearnet leak bugs in Whonix). As corridor’s project description states, quote “it cannot prevent malware on a client computer from finding out your clearnet IP address”. corridor is mostly useful for developers and auditors of Whonix, perhaps also for advanced users who would like to have an additional safety net. It cannot protect from hypothetical Qubes ProxyVM leak bugs either, a physically isolated, standalone corridor-Gateway would be better and could cover that.

It does not increase the tunnel length, i.e. it does not add more relays between you and the destination, if you are interested in that, see Tunnels/Introduction.

Credits: The author of corridor is rustybird. The author of fork of corridor for Debian which will be used in this instructions is Patrick Schleizer.

The full documentation for doing this can be found here:
https://www.whonix.org/wiki/Corridor

If you like Whonix, please support it.

Posted in Qubes-Whonix News, Whonix New Features, Whonix Wiki Updates

combining Tor with a VPN or proxy can make you less anonymous

  • Tor avoids using more than one relay belonging to the same operator in the circuits it is building. Legitimate Tor relay operators adhere to Tor’s relay operator practices of announcing which relays belong to them by declaring this in the Tor relay family setting. Tor also avoids using Tor relays that are within the same network by not using relays within the same /16 subnet. [3] Tor however does not take into account your real external IP nor destination IP addresses. [4] In essence, you must avoid using the same network/operator as your first and last Tor relays since this would open up end-to-end correlation attacks.
  • Many tunnel providers use shared IP addresses which means that many users share the same external IP address. On one hand this is good since that is similar to Tor, where many users share the same Tor exit relays. On the other hand, this can in some situations lead to actually making you less safe.
  • It is possible to host Tor relays [any… bridges, entry, middle or exit] behind VPNs or tunnel-links. For example, there are VPN providers that support VPN port forwarding. This is an interesting way to contribute to Tor while not exposing oneself to too much legal risk. Therefore, there can be situation, where a VPN or other tunnel-link and a Tor relays could be hosted by the same operator, in the same network or even on the same IP.
  • In an economy with a deep labor division, ones are providing the service to host servers (VPS etc.). Others provide VPN and other tunnel-link services and rent such servers. It is common, that diverse customers run share the same IP address. This is another situation where a VPN or other tunnel-link and a Tor relays could be hosted by the same operator, in the same network or even on the same IP.
  • By adding arbitrary tunnel-links to your connection chain, you could unknowingly use the same operator/network twice in your connection chain.
    • scenario 1)
      • a) User uses VPN IP A on the host, thereby using it as it’s first relay.
        • b) User’s Tor client happens to pick a Tor exit relay running on VPN IP A.
        • Conditions a and b match at the same time. The user is now using the same IP as first and last proxy.
          • –> By using the VPN the user did not get more, but less secure.
    • different scenario 2)
      • a) User sets up a VPN inside Whonix-Workstation. Thereby that results in user -> Tor -> VPN -> internet. Using VPN IP A.
      • b) A Tor entry guard is being hosted on VPN IP A.
      • Conditions a and b match at the same time. The user is now using the same IP as first and last proxy.
        • –> By using the VPN the user did not get more, but less secure.
  • Choose your tunnel providers wisely.
    • Find out in which physical and legal jurisdiction and network their servers are located.
    • Perhaps avoid using VPN or SSH providers that support port forwarding.
    • Perhaps use only tunnel-link providers that are assigning private – as in not shared with others – unique – IP addresses, however it is not clear if this does more harm than gain as noted above.
    • Perhaps use tunnel-link providers that run their own servers rather than relying on shared infrastructure.
  • Perhaps manually pick your Tor relay[s]. Specifically your entry guard[s] or bridge[s]).
    • Tor documentation generally discourages tampering with Tor’s routing algorithm by manually choosing your relays, but since you are trying to be more clever by extending your Tor chain despite all information about the difficulty of this endeavor, perhaps it would make sense to pick your entry guard manually.
    • Using Bridges might be an alternative, but note the following quote. “Bridges are less reliable and tend to have lower performance than other entry points. If you live in a uncensored area, they are not necessarily more secure than entry guards. Source: bridge vs non-bridge users anonymity.

This is now documented here:
https://www.whonix.org/wiki/Tunnels/Introduction#Introduction

Posted in Whonix Important News, Whonix Misc News, Whonix Wiki Updates

Your MAC Address Randomization attempts are futile!

The following paper explains why.

Why MAC Address Randomization is not Enough:
An Analysis of Wi-Fi Network Discovery Mechanisms

The above interesting paper has been found by HulaHoop and added to Whonix MAC address documentation.

Posted in General Security News, Whonix Important News, Whonix Wiki Updates

Gathering Feedback of new Whonix Homepage Draft

We have been discussing a new Whonix homepage (old) and new Whonix download page (old) for a while now. The draft has been created by Ego and we are now be counseled by ura design, Elio Qoshi (@elioqoshi) (who has recently refined Whonix logo).

Please keep your feedback specific to the new Whonix homepage.

The new Whonix homepage draft can be found here:
http://egobits1.github.io
http://archive.is/1qxfJ )

Elio’s latest suggestion can be found here:
https://forums.whonix.org/t/new-qubes-website-new-whonix-website/1736/84
(We agreed to finish the visual changes before the text gets improved.)

The source code for the Whonix homepage draft can be found here:
https://github.com/EgoBits1/EgoBits1.github.io

Other than that, we are also considering to replace mediawiki.

Posted in Whonix Website News

Whonix logo has been refined

We are excited to reveal that our very own Whonix logo has been slightly refined, offering now better support for smaller screens and more mediums. We also have new profile image based on the logo for social media usage.

Head over to the Whonix blog or Whonix social media accounts to check it out:
https://www.whonix.org/blog/
https://www.facebook.com/Whonix/posts/1138354749540112
https://twitter.com/Whonix/status/7474134011319787521
https://facebook.com/sharer.php?u=https://www.whonix.org/wiki/Portal

For comparison:
– before: http://archive.is/JA7Wy
– after: http://archive.is/HNxVk

Before:

After:

Feel free to grab the source files if you want to try it out yourself:
https://www.whonix.org/wiki/Dev/Logo#Refinement_June_2016

The refinement was done by ura design, Elio Qoshi (@elioqoshi). I recommend Elio. The quality of his work, his rates, his responsiveness, community engagement and patience is exemplary. I am looking forward to upcoming projects with him.

Posted in Whonix Website News

Legal

Archives

Contribute

Would you like to contribute to the Whonix project?

Contributing can be as easy as sharing the blog over social media, volunteering, or making a monetary donation.

For more ideas on how to get involved see the "Contribute" and "Testers-Wanted" categories.

Thanks!

- Whonix Staff