Separate tor hidden service from bridge, harden HS with vanguards add-on

[nickgnazzo]

Hello!

I'm not sure if this is going to be of interest or use to the general Streisand community (or if these changes are a little too niche), but I've made a number of modifications to the default Tor hidden service and bridge config for my own copy of Streisand, and installed the vanguards add-on from one of the Tor Project developers.

I figured it can't hurt to at least open a PR if this is of interest to anyone else (or maybe this isn't the appropriate place? feel free to tell me to screw off :). I mostly did this for educational purposes and unyielding boredom.

This PR attempts to do the following:

• Run Streisand's Tor hidden service and Tor bridge on separate Tor processes.
  • The Tor Project recommends against running a hidden service and a tor bridge on the same machine, or at the very least to run them as separate processes. This way, the HS activity won't be able to "block" the bridge's activity (this is a side effect of Tor being single-threaded). Also, the bridge will actually report your onion service history in its statistics if they use the same process.
  • See these two links for more info:
    • https://trac.torproject.org/projects/tor/ticket/8742
    • https://trac.torproject.org/projects/tor/ticket/16585
  • This will get rid of the warning in the log files about running a Tor bridge/hidden service on the same process when Tor starts up.
  • To accomplish this, I created a new "debian-tor-hs" user (the default user for Tor is "debian-tor"), and changed the Tor bridge config to no longer create a hidden service (the HS is now in a separate config). The hidden service has its own systemd unit, AppArmor profile, and torrc config which are all configured to use the "debian-tor-hs" user/group.
• Modify the Tor hidden service to use the local bridge for its own connection to the Tor network.
  • Since Streisand is making a locally running bridge, I thought it made sense for the HS to use that same bridge to connect to Tor. It also helps us to somewhat conceal our hidden service traffic by blending it in with other people using the bridge.
    • Though, admittedly, this would be a lot more well-blended if the bridge were public and being used by lots of other Tor users. This way the HS wouldn't quite stand out so much against traffic analysis.
• Install the vanguards add-on written by Mike Perry from the Tor Project.
  • The vanguards add-on aims to provide additional defenses from deanonymization attacks against Tor hidden services. It accomplishes this by using the control socket (or port) of the hidden service to monitor connections from clients, rendezvous points, change the way guards are used/circuits are built, and a lot more.
  • For more information, read the awesome documentation from Mike about the project and how it works:
    • Technical README
    • Security README
  • Also see Tor's blog post on the add-on:
    • https://blog.torproject.org/announcing-vanguards-add-onion-services
  • Since this add-on isn't yet widely available as an apt package and won't be auto-updated, I wrote a fairly small script which will periodically fetch and GPG verify new tags from the repo listed above.
    • I also added Mike's key to the Streisand keyring in the tor-bridge role, so we can verify the GPG signed git tags within the repository. If the update script fails to verify the tag, it tries to abort and revert us back to the last known "good state"/verified git tag.