{{Header}} {{#seo: |description=Hosting a bridge, private bridge, or obfuscated bridge in Whonix. Hosting a middle or exit Tor relay in {{project_name_long}}. |image=Moving-stairs-918559640.jpg }} [[File:Moving-stairs-918559640.jpg|thumb]] {{intro| Hosting a bridge, private bridge, or obfuscated bridge in Whonix. Hosting a middle or exit Tor relay in {{project_name_short}}. }} __FORCETOC__ = Introduction = When using {{project_name_short}}, it is still possible to volunteer to Tor by hosting a bridge, private bridge, obfuscated bridge, private obfuscated bridge, middle node or exit relay. This configuration is set up either inside {{project_name_gateway_long}} or directly on the host. = Rationale = {{mbox | type = notice | image = [[File:Ambox_notice.png|40px|alt=Info]] | text = This configuration is recommended for advanced users. }} Anonymity [https://forums.whonix.org/t/hosting-a-tor-relay-and-or-bridge-for-better-anonymity/12067 might or might not] be improved by hosting a Tor relay and/or bridge and using it to mix personal client Tor traffic. The reason is adversaries observing traffic will need to perform classification of both traffic generated by the Tor relay or bridge and your personal client traffic. To learn more about this topic, refer to posts by The Tor Project (developers of the Tor software). Also see: [https://cacr.uwaterloo.ca/techreports/2015/cacr2015-09.pdf On Realistically Attacking Tor with Website Fingerprinting]. Quote The Tor Project [https://blog.torproject.org/new-low-cost-traffic-analysis-attacks-mitigations New low cost traffic analysis attacks and mitigations]:
In terms of mitigating the use of these vectors in attacks against Tor, here's our recommendations for various groups in our community: Users: Do multiple things at once with your Tor client Because Tor uses encrypted TLS connections to carry multiple circuits, an adversary that externally observes Tor client traffic to a Tor Guard node will have a significantly harder time performing classification if that Tor client is doing multiple things at the same time. This was studied in [https://cacr.uwaterloo.ca/techreports/2015/cacr2015-09.pdf section 6.3 of this paper] by Tao Wang and Ian Goldberg. A similar argument can be made for mixing your client traffic with your own Tor Relay or Tor Bridge that you run, but that is [https://github.com/mikeperry-tor/vanguards/blob/master/README_SECURITY.md#the-best-way-to-run-tor-relays-or-bridges-with-your-service very tricky to do correctly] for it to actually help.
= Configuration = == Outside {{project_name_gateway_short}} == This procedure is currently [[Undocumented]]. Help is most welcome to complete this section. == Inside {{project_name_gateway_short}} == === Introduction === This procedure has not been tested for a significant period; please contact {{project_name_short}} developers if you are interested in this configuration. This configuration is non-trivial for reasons outside of {{project_name_short}} control and is mostly [[Unspecific|unspecific]] to the platform. An open port is required to allow unsolicited incoming connections; see [[Ports]] for an explanation. === Prerequisite Knowledge === Before attempting this setup, various learning exercises are recommended beforehand. # Set up a web server reachable on PC. For example: Internet → home router → PC → web server # Set up a web server reachable in VM. For example: Internet → home router → PC → Debian (not {{project_name_short}}) VM → web server After succeeding with the above configurations, then try the same with Tor in {{project_name_short}}. === Instructions === {{Box|text= Perform these steps in {{project_name_gateway_short}} ({{project_name_gateway_vm}}). '''1.''' Follow all the usual instructions on the torproject.org website inside {{project_name_gateway_short}}; the fact that Tor is being run inside a virtual machine does not change the procedure. '''2.''' Set up a port forwarding from the host to the virtual machine. * [[KVM]]: Follow the [https://wiki.libvirt.org/page/Networking#Forwarding_Incoming_Connections NAT port forwarding instructions] for {{project_name_gateway_short}}. * [[VirtualBox]]: Port forwarding can also be set using the VirtualBox GUI. Navigate to {{project_name_gateway_short}} → Settings → Network Interface → Port Forwarding '''3.''' Inspect [https://github.com/Whonix/whonix-firewall/blob/master/etc/whonix_firewall.d/30_whonix_gateway_default.conf /etc/whonix_firewall/30_default.conf]. '''4.''' Read the introductory comment about [[Configuration_Files|flexible modular configuration files]]. '''5.''' Read the comment about Tor Relay Settings. '''6.''' Close the file. '''7.''' {{Firewall_Settings}} '''8.''' Paste the following content and make adjustments if necessary. {{CodeSelect|code= ## Allow incoming DIRPORT connections for an optional Tor relay. GATEWAY_ALLOW_INCOMING_DIR_PORT=1 ## Allow incoming ORPORT connections for an optional Tor relay. GATEWAY_ALLOW_INCOMING_OR_PORT=1 ## DIRPORT incoming port. DIR_PORT=80 ## ORPORT incoming port. OR_PORT=443 }} '''9.''' {{Reload_Firewall}} '''10.''' The procedure is complete. }} = Easy Option: Snowflake Pluggable Transport = It was previously possible to install the Flashproxy bridge add-on in Chrome, Chromium and Firefox to help censored users access Tor. Essentially this performed as a miniature proxy that ran in the web browser, checked for clients needing access, and conveyed data between them and a Tor relay. https://crypto.stanford.edu/flashproxy/ However, after being operational between 2013 and 2016, Flashproxy was deprecated in 2017. The modern alternative to Flashproxy is Snowflake: https://tb-manual.torproject.org/circumvention/ https://support.torproject.org/censorship/
Snowflake is an improvement upon Flashproxy. It sends your traffic through WebRTC, a peer-to-peer protocol with built-in NAT punching.
This system is composed of three components: volunteers running Snowflake proxies, Tor users that want to connect to the internet, and a broker, that delivers snowflake proxies to users. ... Volunteers willing to help users on censored networks can help by spinning short-lived proxies on their regular browsers. ... Snowflake uses the highly effective [https://support.torproject.org/glossary/domain-fronting/ domain fronting] technique to make a connection to one of the thousands of snowflake proxies run by volunteers. These proxies are lightweight, ephemeral, and easy to run, allowing us to scale Snowflake more easily than previous techniques.
To assist censored users, the Snowflake pluggable transport can be installed in Tor Browser / Firefox or Chrome. Note that websites that are browsed by censored users will match their Tor exit node, not yours: * [https://addons.mozilla.org/en-US/firefox/addon/torproject-snowflake/ Tor Browser / Firefox] * [https://chrome.google.com/webstore/detail/snowflake/mafpmfcccpbjnhfhjnllmmalhifmlcie Chrome] To learn more about Snowflake, see [https://snowflake.torproject.org/ here] ([http://oljlphash3bpqtrvqpr5gwzrhroziw4mddidi5d2qa4qjejcbrmoypqd.onion/index.html v3]). Note that it is also possible to run a [https://community.torproject.org/relay/setup/snowflake/standalone/ standalone Snowflake proxy] ([http://xmrhfasfg5suueegrnc4gsgyi2tyclcy5oz7f5drnrodmdtob6t2ioyd.onion/relay/setup/snowflake/standalone/index.html v3]) on a server, but this configuration has not yet been attempted in {{project_name_short}}. = Footnotes = {{reflist|close=1}} {{Footer}} [[Category:Documentation]]