Page MenuHomePhabricator

researchExperimental
ActivePublic

Watchers

  • This project does not have any watchers.

Recent Activity

Yesterday

Patrick lowered the priority of T389: make sure Qubes-Whonix has no access to clocksource=xen from High to Normal.
Sun, Dec 9, 6:53 AM · mgmt, research, security, Qubes, Whonix

Fri, Dec 7

Patrick removed a project from T530: CPU-induced latency Covert Channel Countermeasures: Whonix 15.
Fri, Dec 7, 12:06 PM · virtualizer, VMware, VirtualBox, KVM, Qubes, security, research, Whonix
Patrick removed a project from T444: test if Ricochet IM instructions are functional: Whonix 15.
Fri, Dec 7, 12:05 PM · onion-grater (Control Port Filter Proxy), research, Whonix
Patrick removed a project from T567: research: Single Tor-Gateway with Multiple Workstations vs Multiple Tor-Gateways mapped 1:1 to Workstation VMs: Whonix 15.
Fri, Dec 7, 12:04 PM · research, Whonix, user documentation
Patrick removed a project from T694: Gajim as default messenger: Whonix 15.
Fri, Dec 7, 12:02 PM · Whonix, research
Patrick removed a project from T772: Managing programs without Tor Socks / DNS Support: Whonix 15.
Fri, Dec 7, 12:00 PM · research

Mon, Dec 3

HulaHoop added a comment to T71: Show desktop clock in local time; keep system in UTC.

I think hiding the clock is a bad idea as a user may want to manually run sdwdate to adjust it if it's out of whack before initiating internet traffic. (This is on non-Qubes versions lacking auto time adjust)

Mon, Dec 3, 6:15 PM · research, whonix-setup-wizard, usability, desktop, Whonix
HulaHoop added a comment to T509: Consider nftables as a replacement for iptables.

https://researchut.com/post/migrating-firewall-to-nftables/

Mon, Dec 3, 6:02 PM · iptables, vpn-firewall, whonix-ws-firewall, whonix-gw-firewall, Whonix, refactoring, research

Tue, Nov 20

Patrick removed a project from T71: Show desktop clock in local time; keep system in UTC: kde.
Tue, Nov 20, 5:01 PM · research, whonix-setup-wizard, usability, desktop, Whonix
Patrick closed T630: Disabling Baloo file indexer as Wontfix.

https://forums.whonix.org/t/user-poll-xfce-vs-kde-kde-deprecation-considered/6235

Tue, Nov 20, 4:59 PM · Debian version 10 codename Buster, kde, security, research

Oct 13 2018

HulaHoop added a comment to T567: research: Single Tor-Gateway with Multiple Workstations vs Multiple Tor-Gateways mapped 1:1 to Workstation VMs.

Proposed implementations for multi-Tor suggested here:

Oct 13 2018, 12:44 AM · research, Whonix, user documentation
HulaHoop added a comment to T567: research: Single Tor-Gateway with Multiple Workstations vs Multiple Tor-Gateways mapped 1:1 to Workstation VMs.

The short story is that things get worse very quickly, but there is hope.
The analysis below assumes only the adversary that runs guards and not the local adversary like the host OS or the Whonix processes themselves.
In my analysis I assume a hypothetical adversarial guard bandwidth of 10% of the entire network. This is an arbitrary number since we don't know the real number, but it serves to show the trends as we increase the guards per client and number of clients per user. I do the kind of analysis we do in the Conflux[1] paper which is very relevant here, especially Table 3 and its discussion in section 5.2. I update the numbers and extend that analysis for the scenarios you have described.

  1. 1 guard/client, 1 client/user. The adversary (i,e, the compromised guard) will have the ability to observe 10% of the clients and hence 10% users. This is the situation today.
  2. 2 guards/client, 1 client/user. This is worse than 1 above. There is now a 18% probability that only one of the guards is compromised per client and a 1% chance that two guards are compromised per client. The probability of at least one bad guard is hence 19%. There really is not a real distinction between one or two bad guards from the user perspective since in both situations the client will go through a malicious guard in a short period of time, since the guard is picked uniformly at random from the guard set.
  3. 1 guard/client, 2 clients/user. The observable clients again increase to 19% from the base 10% in 1 above. This means that if the user split her app (or group of apps) across the clients then there is a 19% chance that at least one of the app (groups) is compromised. However, for each client there is still only a 10% chance that a malicious guard is present. Is this configuration better than scenario 2 above? Perhaps, but let's look at the following scenario first.
  4. 2 guards/client, 2 clients/user. The observable clients increases to 54%. This means that there is a 54% chance that at least one bad guard is present. This is worse than all the other scenarios above. However, if we fix apps (or groups of apps) to particular clients then we can compare to scenario 2 where the app group/client is analogous and the same analysis holds. Then, for each client there is again a 19% chance that there is a malicious guard present. If we compare to 3 above we can see that if we only use 1 guard/client then we can drop the exposure back down to 10% for that client and hence app group.

    Taking the above into account we can get good results by keeping the guard set size to 1 and users spin up one client for each app. Then we can achieve at most 10% of apps compromised at *any given time* but not simultaneously. We can call this scenario (which is an extension of scenario 3) the 1 guard/app scenario (1G/A). See the appendix for more tweaks to decrease guard exposure.

    If we want to consider 1G/A, then the next question for your user base is that is it better to either 1) have some portion of your apps compromised at *all* times (scenario 1G/A) or 2) have *all* your apps compromised some portion of the time (scenario 1). Tor tends to bend towards option 2, but then they have not considered the option of multi-client usage since it doesn't improve the situation in a non-compartmentalized setting, unlike the Whonix situation. I believe that option 2 is flawed because you never know if you are in fact currently compromised or not. It might be better to go ahead with assuming that you are compromised and mitigating that compromise to some portion of your network activity than all or nothing, which is what option 1 provides.

    I hope that answers your questions. Please do not hesitate to get in touch again if you would like to discuss further. I think this is a very interesting problem area and would be happy to contribute to improving the situation.

    Best regards, Tariq Elahi

    [1] http://cacr.uwaterloo.ca/techreports/2013/cacr2013-16.pdf

    Appendix We can do better if we allow a user's clients to look at each other's lists to exclude guards that are already picked. The benefit would be that once the bad bandwith has been assigned it can no longer affect subsequent guard selections. However, clients looking at each other's memory space will compromise your vision of process containment. A zero knowledge/oblivious method for comparing guard lists might work to avoid this problem, and indeed the adversarial response will be weak since the best they can do is spread their bad bandwidth over many relays and at best return to the original exposure rate (e.g. 10%) but now with added costs of running many more relays.
Oct 13 2018, 12:42 AM · research, Whonix, user documentation

Sep 20 2018

Patrick triaged T852: research and document how to shut down system on removal of some USB device as Normal priority.
Sep 20 2018, 11:39 AM · Whonix 16, research, Whonix

Sep 18 2018

marmarek added a comment to T691: sdwdate sclockadj change time without spamming logs.

Actually, the "apt-daily.timer: Adding 1h 17min 24.927437s random time" message have real impact, not only noise. Each time sdwdate change time, systemd adds a random delay to those timers. which means the timer will never expire (unless that random delay will happen to be very close to 0 - i.e. below the time until sdwdate change the time, which looks to be 1s).

Sep 18 2018, 3:55 AM · systemd, research, sclockadj, sdwdate, Whonix

Aug 16 2018

HulaHoop closed T367: Mixmaster GUI Options as Wontfix.

Non-Debian dependencies and non materialization of TUF PyPi makes a secure way to obtain this package impossible.

Aug 16 2018, 5:42 PM · user documentation, research, usability, Whonix
HulaHoop placed T600: Integrating Guix/Nix Package Manager up for grabs.
Aug 16 2018, 5:16 PM · Whonix, packaging, research
HulaHoop placed T772: Managing programs without Tor Socks / DNS Support up for grabs.
Aug 16 2018, 5:15 PM · research

Aug 9 2018

Patrick added a project to T774: [Revised] Clock Drift Correction Proposal: KVM.
Aug 9 2018, 5:19 PM · KVM, Whonix, research

Aug 8 2018

Patrick updated the task description for T215: install electrum bitcoin thin client by default?.
Aug 8 2018, 10:58 AM · anon-meta-packages, research, Whonix
Patrick updated the task description for T215: install electrum bitcoin thin client by default?.
Aug 8 2018, 10:39 AM · anon-meta-packages, research, Whonix
Patrick updated the task description for T215: install electrum bitcoin thin client by default?.
Aug 8 2018, 10:37 AM · anon-meta-packages, research, Whonix

Aug 7 2018

Patrick updated the task description for T389: make sure Qubes-Whonix has no access to clocksource=xen.
Aug 7 2018, 6:37 PM · mgmt, research, security, Qubes, Whonix

Jul 25 2018

Patrick closed T691: sdwdate sclockadj change time without spamming logs as Resolved.

This is sorted in a later version of systemd.

Jul 25 2018, 8:39 AM · systemd, research, sclockadj, sdwdate, Whonix
Patrick edited projects for T691: sdwdate sclockadj change time without spamming logs, added: systemd; removed Whonix 16.
Jul 25 2018, 8:39 AM · systemd, research, sclockadj, sdwdate, Whonix

Jul 24 2018

Patrick added a comment to T444: test if Ricochet IM instructions are functional.

There are up to date Whonix 14 testers versions available.

Jul 24 2018, 11:47 AM · onion-grater (Control Port Filter Proxy), research, Whonix
Patrick changed Impact from Whonix:triage to Whonix:normal on T444: test if Ricochet IM instructions are functional.
Jul 24 2018, 11:45 AM · onion-grater (Control Port Filter Proxy), research, Whonix
Patrick renamed T444: test if Ricochet IM instructions are functional from Ricochet IM to test if Ricochet IM instructions are functional.
Jul 24 2018, 11:45 AM · onion-grater (Control Port Filter Proxy), research, Whonix
Patrick updated the task description for T444: test if Ricochet IM instructions are functional.
Jul 24 2018, 11:43 AM · onion-grater (Control Port Filter Proxy), research, Whonix

Jul 22 2018

HulaHoop added a comment to T600: Integrating Guix/Nix Package Manager.

@ng0 I wrote a proposal draft. Feel free to improve it before I post:

Jul 22 2018, 6:23 PM · Whonix, packaging, research

Jul 19 2018

ng0 added a comment to T600: Integrating Guix/Nix Package Manager.

Just this bit already:

Jul 19 2018, 5:19 PM · Whonix, packaging, research
ng0 added a comment to T600: Integrating Guix/Nix Package Manager.

Acknowledged and I'm lagging behind. You can expect an answer somewhere between mid August and beginning of October.

Jul 19 2018, 5:12 PM · Whonix, packaging, research

Jul 14 2018

Patrick changed the status of T66: Certificate Authority (CA) Pinning for whonix.org from Invalid to Resolved.

We have now a DNS Certification Authority Authorization (CAA) Policy.

Jul 14 2018, 12:02 PM · research, website, Whonix, security, infrastructure

Jul 9 2018

Patrick added a comment to T84: Should we enable HTTP Public Key Pinning (HPKP) for whonix.org?.
In T84#14765, @marmarek wrote:
Jul 9 2018, 7:21 AM · infrastructure, security, research, Whonix, website
Patrick closed T66: Certificate Authority (CA) Pinning for whonix.org as Invalid.

Same as T84#14765.

Jul 9 2018, 7:20 AM · research, website, Whonix, security, infrastructure
Patrick updated the task description for T66: Certificate Authority (CA) Pinning for whonix.org.
Jul 9 2018, 7:19 AM · research, website, Whonix, security, infrastructure
Patrick updated the task description for T84: Should we enable HTTP Public Key Pinning (HPKP) for whonix.org?.
Jul 9 2018, 7:19 AM · infrastructure, security, research, Whonix, website

Jul 7 2018

Patrick closed T84: Should we enable HTTP Public Key Pinning (HPKP) for whonix.org? as Wontfix.
Jul 7 2018, 2:36 PM · infrastructure, security, research, Whonix, website

Jun 29 2018

HulaHoop added a comment to T801: use libresolv-wrapper rather than functional Whonix-Gateway system DNS resolver?.

Check these alternatives out:

Jun 29 2018, 11:58 PM · Whonix, Whonix 16, research, anon-gw-dns-conf

Jun 25 2018

Patrick raised the priority of T694: Gajim as default messenger from Low to Normal.
Jun 25 2018, 4:43 AM · Whonix, research

Jun 24 2018

Patrick updated the task description for T694: Gajim as default messenger.
Jun 24 2018, 8:28 AM · Whonix, research
Patrick added a comment to T694: Gajim as default messenger.

https://github.com/Whonix/anon-apps-config/commit/55901b6e45fe6dc818c03e3264bcfd4f3e08325d

Jun 24 2018, 8:28 AM · Whonix, research
Patrick assigned T772: Managing programs without Tor Socks / DNS Support to HulaHoop.
Jun 24 2018, 6:43 AM · research

Jun 23 2018

Patrick triaged T801: use libresolv-wrapper rather than functional Whonix-Gateway system DNS resolver? as Normal priority.
Jun 23 2018, 9:49 AM · Whonix, Whonix 16, research, anon-gw-dns-conf

Jun 20 2018

HulaHoop added a comment to T509: Consider nftables as a replacement for iptables.

nftables transition info:

Jun 20 2018, 3:03 PM · iptables, vpn-firewall, whonix-ws-firewall, whonix-gw-firewall, Whonix, refactoring, research

Jun 18 2018

Patrick updated the task description for T509: Consider nftables as a replacement for iptables.
Jun 18 2018, 4:23 PM · iptables, vpn-firewall, whonix-ws-firewall, whonix-gw-firewall, Whonix, refactoring, research

May 18 2018

HulaHoop added a comment to T600: Integrating Guix/Nix Package Manager.

If you would have read the chat content (which I assume you didn't), you would see some insight into the problems and what possible solutions there are.

May 18 2018, 3:18 PM · Whonix, packaging, research

May 16 2018

Patrick added a comment to T623: port anon-ws-disable-stacked-tor to systemd socket activation.

@HulaHoop in T544#16070

How are we doing on RAM use? Is it any more or less efficient than socat after you cut down the number of spawned instances?

May 16 2018, 5:33 PM · Whonix 14, Whonix, research, anon-ws-disable-stacked-tor
HulaHoop closed T602: OnionMail as Wontfix.

Project looks dead no recent releases.

May 16 2018, 2:41 PM · Whonix 15, research, Whonix

May 9 2018

Patrick changed the status of T444: test if Ricochet IM instructions are functional from Open to testing-in-next-build-required.

https://github.com/Whonix/uwt/commit/907f8e1ee93a0ec47febecce3e86266c681764fa

May 9 2018, 11:48 AM · onion-grater (Control Port Filter Proxy), research, Whonix
Patrick changed the status of T444: test if Ricochet IM instructions are functional from Review to Open.
May 9 2018, 11:34 AM · onion-grater (Control Port Filter Proxy), research, Whonix