Consider consolidating and simplifying sd-whonix/sd-proxy

[eloquence]

Because sd-proxy does not use a browser, there are only limited security benefits in the split VM architecture we currently use to access Tor. The complexity cost is significant. Post-beta, we should consider the advantages and disadvantages of different approaches:

1) No change 2) Using a single Whonix-based VM to run the proxy 3) Using a single Debian-based VM to run the proxy and managing Tor access / Firewall rules ourselves 4) Other options

[conorsch]

A balanced approach would still get us quite a reduction in complexity:

• use the securedrop-workstation TemplateVM for sd-proxy, consolidating as described in #471; and
• set its netvm to sd-whonix, which doesn't require its own TemplateVM (due to binddirs storing onion auth info)

Since we merged #447, we're customizing the underlying whonix-gw-15 TemplateVM, but perhaps we could avoid that by changing the log aggregation approach (#463).

[eaon]

Given the workstation's limited needs, I think it's feasible to do this with Tor's transparent proxy support (see: TransPort and maybe MapAddress in the torrc manual) while using iptables/nftables to lock down requests the securedrop.Proxy calls can make. Happy to draw up a proposal when you'd like to look at this again.

[eloquence]

As one data point, most of my recent updater run failures have been due to update failures specifically on the Whonix templates, usually due to an "Invalid response from proxy: Unable to connect" tinyproxy error. This is with the clearnet repos configured, not the onion service ones. If this is a common experience, it may be more grist for the mill of either simplifying our Whonix config our eliminating the dependency on Whonix altogether.

[eaon]

Removing our dependency on Whonix would …

• cut down on time to run the updater
• avoid repeated intermittent update failures
• decrease the overall complexity of the workstation
• (Option 1 only) use less memory because fewer VMs are required to operate
• :warning: remove the UI that allows one to confirm that a connection to the Tor network was successful, configure bridges, etc.
• :warning: (Option 1 only) remove our ability to use a netvm to connect to the Journalist Interface for administrative / QA purposes

Practical aspects of replacing our use of Whonix gateway

Option 1

Connect sd-proxy to the internet directly, but isolate it as best as possible.

sd-proxy should:

• be ready to use arti as a "drop-in" replacement for when it supports onion services (with authentication) and we've tested it thoroughly enough to switch
• use sys-firewall as netvm, but block all outgoing network connections except for TCP by the user debian-tor and all incoming connections except TCP connections to tor's SOCKSPort by localhost
• have securedrop-proxy connect to tor's SOCKSPort directly via python-requests' SOCKS5 proxy support

Option 2

Create a new qube called sd-tor, essentially a simpler version of the Whonix gateway, which acts as a no-GUI netvm that transparently proxies traffic via Tor.

sd-tor should:

• drop all non-TCP traffic except for DNS
• redirect all DNS traffic tor's DNSPort
• use tor's TransPort feature in conjunction with iptables TPROXY / nftables' tproxy to allow regular TCP packets to be routed over Tor
• "forward" all outgoing TCP packets to the TransPort except if they originate with the user debian-tor

Implementation

There's some overlap between the two so I tried to summarise it, let me know if splitting this up would be helpful:

• Add deb.torproject.org repository to sd-small-bullseye-template and install tor (and …keyring) (affected repo: securedrop-workstation)
• (Option 1) Switch from modifying tor configurations on sd-whonix to do the same on sd-proxy (affected repo: securedrop-workstation)
• (Option 2) Create new qube sd-tor (affected repo: securedrop-workstation)
• (Option 2) Switch from modifying tor configurations on sd-whonix to do the same on sd-tor (affected repo: securedrop-workstation)
• (Option 1) Add SOCKS5 proxy to requests (affected repo: securedrop-proxy)
• (Option 2) Change sd-proxy's netvm to sd-tor (affected repo: securedrop-workstation)
• Add a systemd service that loads iptables/nftables rules from /rw/config/firewall/$qubename.rules if the file exists (affected repo: securedrop-builder → folder: securedrop-workstation-config)
• Handle tor service (affected repo: securedrop-builder → folder: securedrop-workstation-config): Add tor.service.d/sdw-override.conf with ConditionalHost=sd-proxy

Personal preferences

While removing features (or fortuitous side effects) is hardly ever great, I think the trade-off here is worth it. I'd opt for Option 1. Please note, that would probably affect our threat model, but I think it'd be the setup that is easiest to understand/maintain and most "future proof" for when arti becomes viable.

In addition, I think there is an argument to be made that Option 1 should really be sd-proxy-dvm with sd-proxy being a "named DispVM" (not sure about the terminology here), because really we don't want persistence in every day operation (a mitigation not too dissimilar to Qubes' new default of making sys-usb disposable)

[legoktm]

I am a big +1 on this solely for "decrease the overall complexity of the workstation".

Minor nit: I think we should re-host tor debs for the workstation just like we do for the server. Or just grab them from bullseye-backports, which are kept roughly up to date with new Tor releases.

[eaon]

Regarding Option 1, I realised that we could use Qubes' firewall system for outgoing connections, which I think would be preferable, because it allows us to block access to private network addresses (10/8, 100.64/10, 172.16/12, 192.168/16 subnets) "outside" of sd-proxy. Blocking outgoing network access per-user (as in, only allow debian-tor to connect to anything but 127.0.0.1) would still have to live "inside" the qube though.

[zenmonkeykstop]

Still into this, will probably proceed with an arti-enhanced proxy, dropping the whonix requirement, once arti is stable and in general use.