{{Header}} {{Title|title= Configure (Private) (Obfuscated) Tor Bridges }} {{#seo: |description=Censorship Circumvention. Get around network bans. Using {{project_name_short}} with (private) (obfuscated) bridges. Useful in case your Internet Service Provider (ISP) bans or throttles connections to the Tor public network. |image=Black-and-white-50272-640.jpg }}
* [[Network_Obstacle|Network Obstacle]] * [[Bridges|Configure (Private) (Obfuscated) Tor Bridges]] * [[Hide_Tor_from_your_Internet_Service_Provider|Hide Tor use from the {{isp}}]]
[[File:bridge_page_custom.png|thumb]] {{intro| Censorship Circumvention. Get around network bans. Using {{project_name_short}} with (private) (obfuscated) bridges. Useful in case your Internet Service Provider (ISP) bans or throttles connections to the Tor public network. }} = Bridges Description and User Groups = == Introduction == {{mbox | type = notice | image = [[File:Ambox_notice.png|40px|alt=Info]] | text = If a website cannot be reached over Tor, this does not necessarily relate to network level censorship that requires a bridge to be configured; it may relate to blacklisting of all Tor exit IP addresses by the server. In that case, see [[Geo-blocking]] for circumventing censorship by destination servers. }} When Tor is used with {{project_name_short}} in the default configuration, anybody observing the properties of its application protocol can discover its presence. Potential observers include the Internet Service Provider (ISP), advanced adversaries, censorship enforcement bodies and other interested parties. [https://2019.www.torproject.org/docs/bridges Tor bridges ("Tor bridge relays")] are alternative entry points to the Tor network, acting as substitutes to regular Tor guards rather than an additional hop to the 3 hop journey. Not all bridges are obtainable publicly. Using a bridge makes it harder, but not impossible, for the ISP to determine if a user is connecting to Tor. == Intended User Groups == {{mbox | type = notice | image = [[File:Ambox_notice.png|40px|alt=Info]] | text = Tor non-functionality is often related to [https://2019.www.torproject.org/docs/faq.html.en#DoesntWork local configuration problems] rather than ISP or state-level censorship. }} For the majority of {{project_name_short}} users, connecting to Tor with the default configuration is appropriate and will work successfully. The minority of users requiring a bridge normally fall into three categories: https://blog.torproject.org/different-ways-use-bridge
* Tor is blocked, and some way - any way - to reach the network has to be found. The adversary is not very dangerous, but very annoying. * Tor may or may not be blocked, but the users are trying to hide the fact they're using Tor. The adversary may be extremely dangerous. * Other bridge users: Testing whether the bridge works (automated or manual), probing, people using bridges without their knowledge because they came pre-configured in their bundle.
The first group of users is only concerned with circumventing Tor censorship that is based on IP address or fingerprinting of protocols. Circumvention is necessary because {{project_name_short}} would otherwise be rendered useless for most activities except working offline on documents and so on, since all Internet traffic is routed through Tor by default. This group is not worried about hiding the use of Tor and will need to use bridges or possibly [[Censorship_Circumvention_Tools|other circumvention tools]]. The second user group is unable to safely start {{project_name_short}} in the default configuration due to Tor being considered dangerous or suspicious in their locality. In this case [[Hide Tor from your Internet Service Provider|private bridges]] should be utilized instead of public obfuscated bridges, as this makes it ''harder'' (not impossible) to detect Tor. Over time, censors have gotten better at detecting Tor network traffic between the client and the first hop, even with the use of more advanced pluggable transports. There is a cyber-censorship arms race in effect. Note that the meek_azure pluggable transport may be necessary to deal with highly aggressive ISP censorship or national firewalls, like those found in China and the Middle East. The third group is only concerned with testing bridge connections. == Before Configuring a Bridge == {{mbox | image = [[File:Ambox_warning_pn.svg.png|40px]] | text = '''Warning:''' Bridges are important tools that work in many cases but they are not an absolute protection against the technical progress an adversary might make in identifying Tor users. Using bridges might be advisable to prevent identification as a Tor user, but the Tor Project's [https://2019.www.torproject.org/docs/bridges bridges documentation] is primarily focused on censorship circumvention, that is, overcoming attempts by ISPs or government to block Tor use. }} Users falling into one of the three groups described above should consider using Tor bridges. Before taking this step, please review The Tor Project's [https://2019.www.torproject.org/docs/bridges dedicated bridges page] to better understand their design and operation. It is also recommended to review [https://2019.www.torproject.org/docs/pluggable-transports how Obfsproxy works], since it is the most commonly used application for connecting bridges. Always remember that bridges are not bullet-proof. The following is a reminder about bridge versus non-bridge anonymity: [https://lists.torproject.org/pipermail/tor-talk/2012-May/024378.html Quote] [https://www.torproject.org/about/people/ Roger Dingledine, cofounder] of [https://www.torproject.org Tor]:
[...] 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. [...]
Quote question:
If that is true, that also means, that bridge users are sufficiently more vulnerable to attacks, which are circumvented by entry guards?
[https://lists.torproject.org/pipermail/tor-talk/2012-May/024378.html Quote] Roger Dingledine, cofounder of Tor:
[...] They're probably more vulnerable, but I don't know if I'd say "sufficiently". [...]
If a user is only concerned with connectivity (getting {{project_name_short}} connected) and local ISPs do not usually hinder connections to the public Tor network, then something simpler than Bridges can be tried; see: [[Bridges#Better_Connectivity_without_Real_Censorship_Circumvention|Better Connectivity without Real Censorship Circumvention]]. == Additional Information and Recommendations == {{mbox | type = notice | image = [[File:Ambox_notice.png|40px|alt=Info]] | text = For safety reasons, the first run of {{project_name_short}} will not automatically connect to the public Tor network. Instead, user networking decisions are guided by [[Anon_Connection_Wizard|Anon Connection Wizard]] which automatically starts. }} When deciding on the type of bridge to configure, it is recommended to: * Prefer [https://2019.www.torproject.org/docs/bridges#PluggableTransports {{Code2|obfuscated bridges}}], since they are harder to identify than other bridges. * Use less well-known bridges, since it is safer. Some bridge addresses are freely provided by the Tor website or by email upon request, meaning adversaries likely use these methods to obtain bridge information. The Tor Project has some protection against adversary threats, but they are far from perfect. * Avoid using a meek provider that also runs DNS core servers, like Google's (now defunct) bridge. Google sees forty percent of Tor Exits' DNS traffic and so using them as a bridge aids website fingerprinting attacks. That said, there is evidence that website fingerprinting is more difficult to mount than previously thought. See: [https://nymity.ch/tor-dns/tor-dns.pdf The Effect of DNS on Tor’s Anonymity] * Note that domain fronting [https://blog.torproject.org/domain-fronting-critical-open-web has been pulled by Google and Amazon], limiting the meek pluggable transport options to meek_azure only in Anon Connection Wizard. * For greater safety, use a {{Code2|private obfuscated bridge}} run by a trusted friend or organization in a different country. In this case "{{Code2|private}}" means that the bridge is configured with the option {{Code2|PublishServerDescriptor 0}}. [https://2019.www.torproject.org/docs/tor-manual.html.en#PublishServerDescriptor Tor manual: PublishServerDescriptor] Without this option set, The Tor Project can learn about the bridge and may distribute its address to others, potentially handing this information to an adversary seeking to generate a list of all known bridges. Please note that it has been assessed as difficult beyond practicality to [[Hide_Tor_from_your_Internet_Service_Provider|Hide Tor use from the Internet Service Provider]] with proxies, bridges, VPNs or SSH tunnels. = Finding a Bridge and Choosing the Right Protocol = In order to use bridges, the address of at least one bridge must be known in advance. It is preferable to have a {{Code2|private obfuscated bridge}} because the alternative -- {{Code2|public obfuscated bridges}} -- are more likely to be censored, since they are publicly listed. The Tor Project distributes {{Code2|public bridge}} addresses in several ways, including from their [https://bridges.torproject.org/ website] and via email. The easiest way to find a list of public bridges is from [https://bridges.torproject.org/options The Tor Project Bridge Database]. In early 2017, The Tor Project advice regarding recommended bridges changed: https://gitlab.torproject.org/legacy/trac/-/issues/18072 This pluggable transport has been deprecated by The Tor Project in favor of [https://2019.www.torproject.org/docs/pluggable-transports.html.en obfs4, meek, Format-Transforming Encryption (FTE) and ScrambleSuit].
... in Tor Browser to obfs4, given that we now have several high capacity obfs4 bridges and obfs4 is more likely to work in more regions than obfs3."
As time has gone on, more {{Code2|obfs4}} bridge operators have come online, and {{Code2|obfs4}} is now routinely recommended by Tor developers over {{Code2|obfs3}}, because the former: https://blog.torproject.org/recent-and-upcoming-developments-pluggable-transports#obfs2_deprecation
... should be able to defend more effectively against active probing.
As a consequence, obfs3 bridges have been deprecated as a configurable pluggable transport option in Tor Browser. https://2019.www.torproject.org/docs/bridges.html.en#PluggableTransports https://2019.www.torproject.org/docs/pluggable-transports.html.en Also see: [https://gitlab.torproject.org/legacy/trac/-/wikis/doc/PluggableTransports/Obfs4Evaluation obfs4 Transport Evaluation].
The obfs4 protocol was developed and is in the process of being deployed by the Tor Project in response to the vulnerability of the obfs3 protocol to detection via active probing attacks. It is expected to supersede the obfs3 protocol as the front-line Pluggable Transport used by most Tor users.
 The Tor Project provides a database of [https://bridges.torproject.org/bridges?transport=obfs4 {{Code2|public obfs4 bridges}}]. A more exhaustive list of public obfuscated bridges is available at [https://bridges.torproject.org/options The Tor Project Bridge Database]. {{Code2|obfs}} and {{Code2|obfs2}} bridges are no longer available since they: https://tb-manual.torproject.org/circumvention/
... are now deprecated and were replaced by {{Code2|obfs3}} . . . and {{Code2|obfs4}}.
Do not select the "IPv6 compatible" check box when [https://bridges.torproject.org/options sourcing bridges] from the database, as they [https://phabricator.whonix.org/T509 cannot be used in {{project_name_short}}] yet. {{Anchor|How to Use Bridges in {{project_name_short}}}} = How to Use Bridges in {{project_name_short}} = It is possible to configure {{Code2|obfs4}} and {{Code2|meek_azure}} ([https://forums.whonix.org/t/meek-lite-a-new-pluggable-transport-in-whonix-14/4500 {{Code2|meek lite}}]) bridges. Two options. Choose either option '''A)''' or '''B)'''. * '''A)''' [[Anon_Connection_Wizard|Anon Connection Wizard]] GUI application - recommended for most users. See instructions below. Or, * '''B)''' [[Tor#Manual_Bridge_Configuration|Manual Bridge Configuration]] - advanced users. {{Box|text= '''1.''' Start Anon Connection Wizard. {{Start_Anon_Connection_Wizard}} '''2.''' Use the Bridge Configuration Page {{Anon_Connection_Wizard_Use_Bridges}} }} = Experimental Bridges = == Snowflake == === Introduction of Snowflake === Snowflake is: https://gitlab.torproject.org/legacy/trac/-/wikis/doc/Snowflake
...a [https://gitlab.torproject.org/legacy/trac/-/wikis/doc/PluggableTransports pluggable transport] that proxies traffic through temporary proxies using ​[https://webrtc.org/ WebRTC], a peer-to-peer protocol with built-in NAT punching. It aims to work kind of like flash proxy, but without flash proxy's problems with NAT.
=== Setup Snowflake === {{Box|text= On Whonix-Gateway. '''1.''' Edit the Tor configuration file. {{Open /usr/local/etc/torrc.d/50_user.conf}} '''2.''' Paste the following setting. The line starting with ClientTransportPlugin was taken from the Tor Browser folder file. grep "ClientTransportPlugin snowflake" ~/.tb/tor-browser/Browser/TorBrowser/Data/Tor/torrc-defaults ''What is the link to the torrc-defaults file The Tor Project git?'' The path was adjusted from ./TorBrowser/Tor/PluggableTransports/snowflake-client to /usr/bin/snowflake-client to be compatible with these instructions. The line starting with Bridge was taken from this command: 
~/tor-browser/Browser/TorBrowser/Data/Tor/torrc
It was previously: 
Bridge snowflake 0.0.3.0:1 2B280B23E1107BB62ABFC40DDCC8824814F80A72
{{CodeSelect|code= UseBridges 1 ClientTransportPlugin snowflake exec /usr/bin/snowflake-client Bridge snowflake 192.0.2.3:80 2B280B23E1107BB62ABFC40DDCC8824814F80A72 fingerprint=2B280B23E1107BB62ABFC40DDCC8824814F80A72 url=https://1098762253.rsc.cdn77.org/ fronts=www.cdn77.com,www.phpmyadmin.net ice=stun:stun.l.google.com:19302,stun:stun.antisip.com:3478,stun:stun.bluesip.net:3478,stun:stun.dus.net:3478,stun:stun.epygi.com:3478,stun:stun.sonetel.com:3478,stun:stun.uls.co.za:3478,stun:stun.voipgate.com:3478,stun:stun.voys.nl:3478 utls-imitate=hellorandomizedalpn Bridge snowflake 192.0.2.4:80 8838024498816A039FCBBAB14E6F40A0843051FA fingerprint=8838024498816A039FCBBAB14E6F40A0843051FA url=https://1098762253.rsc.cdn77.org/ fronts=www.cdn77.com,www.phpmyadmin.net ice=stun:stun.l.google.com:19302,stun:stun.antisip.com:3478,stun:stun.bluesip.net:3478,stun:stun.dus.net:3478,stun:stun.epygi.com:3478,stun:stun.sonetel.net:3478,stun:stun.uls.co.za:3478,stun:stun.voipgate.com:3478,stun:stun.voys.nl:3478 utls-imitate=hellorandomizedalpn }} '''3.''' DNS resolving in Whonix-Gateway. Snowflake-client needs to resolve the -front domain to an IP address, in order to connect to the server; however, this DNS resolving will fail with [[Whonix-Gateway_System_DNS|the default Whonix gateway DNS configuration]]. {{box|text= {{Whonix-Gateway_System_DNS_over_Clearnet}} }} '''4.''' {{Restart_Tor}} '''5.''' Done. The procedure is complete. }} AppArmor has appropriate permissions for Snowflake operation. [https://github.com/Whonix/anon-gw-anonymizer-config/blob/master/etc/apparmor.d/local/system_tor.anondist /etc/apparmor.d/local/system_tor] already contains /usr/bin/snowflake-client ix,. Snowflake forum discussion: * https://forums.whonix.org/t/replacing-meek-snowflake/5190 * https://forums.whonix.org/t/use-snowflake-in-whonix-to-bypass-tor-censorship/13441 === Optional Snowflake Configuration === ==== Use AMP cache rendezvous for Snowflake ==== Optional. wkrp [https://github.com/net4people/bbs/issues/109 stated in a post]:
by default in Tor Browser, Snowflake does rendezvous using a domain-fronted HTTPS request. Now there is an alternative (backup) to domain fronting rendezvous: AMP cache rendezvous. If one rendezvous method is blocked, there is a chance the other will work.
Replace the second line in /usr/local/etc/torrc.d/50_user.conf with: [[Undocumented]]. === Debugging Snowflake === ==== Snowflake Usage Verification ==== Optional. Make sure Tor is using snowflake. To check if Tor is indeed using snowflake, we use nyx or onioncircuits. We are connecting to the Tor network through snowflake if: * In [[Tor_Controller#Nyx|nyx]], the guard node is a local address, like 192.168.0.1; * or in [[Tor_Controller#Onion_Circuits|onioncircuits]], the guard node IP is Unknown. ==== Snowflake log analysis ==== Optional. '''1.''' Enable and view Snowflake log. We can enable the snowflake log for debugging purposes by appending -log snowflake.log -log-to-state-dir to the ClientTransportPlugin snowflake... line in /usr/local/etc/torrc.d/50_user.conf. '''2.''' We can view the snowflake log with: {{CodeSelect|code= sudo less /var/lib/tor/pt_state/snowflake.log }} '''3.''' Tor data directory. Note that we can always find the Tor DataDirectory with the following command: {{CodeSelect|code= anon-verify -v | grep DataDirectory }} DataDirectory /var/lib/tor = Unsupported Pluggable Transport = == WebTunnel == WebTunnel is an [[undocumented]] pluggable transport. == Rationale for Unsupported Bridges == Why are some pluggable transports unsupported? This is a technical explanation. Users are free to skip it. The situation is similar to how it was for [[#Snowflake|Snowflake]] for [https://forums.whonix.org/t/replacing-meek-snowflake/5190 a long time]. WebTunnel is unavailable from packages.debian.org. It is therefore difficult, maintenance time intensive for {{project_name_long}} to install WebTunnel in {{project_name_long}} by default. Related: [[Dev/Default_Application_Policy|Default Application Policy]]. Without volunteer development contributions to {{project_name_long}} this will probably take a few years, if it ever happens. References: * https://forums.whonix.org/t/adding-webtunel-bridges-to-whonix/19675/1 * https://blog.torproject.org/introducing-webtunnel-evading-censorship-by-hiding-in-plain-sight/ * https://community.torproject.org/relay/setup/webtunnel/ = Warning: Bridged Networking = Do not change VirtualBox settings on the host operating system for {{project_name_gateway_short}}'s first or second network interface to a bridged network! This is [[unsupported|unsupported]], untested and should not be necessary. This is elaborated in wiki chapter [[Whonix-Gateway_Security#Warning:_Bridged_Networking|Whonix-Gateway Security, Warning: Bridged Networking]]. = Troubleshooting = == Check Tor Network Connection is Using a Tor Bridge == Concerned bridge users can complete a simple check. {{Box|text= '''1.''' Open [[Tor_Controller#Nyx|Nyx]] as follows. {{Start_Arm}} '''2.''' Use the right arrow button to navigate to page 2 of 5 in Nyx. '''3.''' If a bridge is in use, the circuit information will be similar to this. 
192.168.0.1 UNKNOWN 1 / Guard
'''4.''' If a bridge is ''not'' in use, the circuit information will be similar to this. 
IP Nickname 1 / Guard
The IP is the real IP (''not'' 192.168.0.1) of the Guard, and the Nickname is the name of that Guard relay. '''5.''' Exit Nyx by pressing the following. 
q
q
}} == Connection Issues == After configuration, connection problems can relate to firewall settings that block outgoing connections to the ports provided by the bridge. To check the {{Code2|port}} the bridge is using, see the following example. 
bridge 109.195.132.77:22321
In this example, the IP address is {{Code2|109.195.132.77}}, while the the port is {{Code2|22321}}. Try using a (private) (obfuscated) bridge that uses port {{Code2|80}} or {{Code2|443}}, as these ports are mostly used for web browsing and therefore usually unblocked. == Trying Packet Size and Timing Obfuscation for obfs4 == If a provided {{Code2|obfs4}} bridge does not work, the user can try enabling packet size and timing obfuscation by changing the iat-mode value in each last line to either 1 or 2. 1 = Enabled: ScrambleSuit-style with bulk throughput optimizations. 2 = Paranoid: Each IAT write will send a length sampled from the length distribution (expensive). See: https://lists.torproject.org/pipermail/tor-commits/2014-August/079402.html == Better Connectivity without Real Censorship Circumvention == If a user is only concerned with connectivity (getting {{project_name_short}} connected) and there is no need to ''attempt'' to [[Hide_Tor_from_your_Internet_Service_Provider|Hide Tor use from the Internet Service Provider]] and/or local ISPs do not usually hinder connections to the public Tor network, then something simpler than [[Bridges]] can be tried. The following setting only establishes Tor connections to public Tor network relays that listen on ports {{Code2|80}} and {{Code2|443}}. {{Box|text= '''1.''' Edit the Tor configuration file. {{Open /usr/local/etc/torrc.d/50_user.conf}} '''2.''' Add the following setting. https://support.torproject.org/#tbb_tbb-firewall-ports {{CodeSelect|code= FascistFirewall 1 }} '''3.''' Save the file and have the changes take effect. {{Reload_Tor}} The procedure is complete. }} == Missing ClientTransportPlugin Line == When a user has configured the following. {{CodeSelect|code= bridge obfs4 ...:... ... cert=... iat-mode=0 }} But forgot to add the corresponding line. {{CodeSelect|code= ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy }} Then warnings will only be shown in logs. 
[warn] We were supposed to connect to bridge '...:...' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
== Missing ClientTransportPlugin Executable == 
[warn] Could not launch managed proxy executable at '/usr/bin/obfs4proxy' ('No such file or directory').
= Deprecated Tor Pluggable Transports = === Scramblesuit === {{Code2|scramblesuit}}: Unrecommended (see footnote). Use the provided {{Code2|obfs4}} instructions instead. [https://gitlab.tails.boum.org/tails/tails/-/issues/7909#note-8 Quote intrigeri] (Tails developer):
On tor-talk we've been told "You shouldn't prioritise ScrambleSuit because it is superseded by obfs4", and there are now pressing plans in the Tor Project to deprecate obfs2 and obfs3 in favour of obfs4. Hence rejecting this ticket, and focusing on [https://gitlab.tails.boum.org/tails/tails/-/issues/7980 #7980] [obfs4 support] instead.
[https://blog.torproject.org/recent-and-upcoming-developments-pluggable-transports Also see Tor Announcement under heading "obfs4 and scramblesuit"] * Old instructions: [[Deprecated#scramblesuit]] === Flashproxy === {{Code2|flashproxy}}: Unrecommended (see footnote). Use the provided {{Code2|obfs4}} instructions instead. [https://gitlab.torproject.org/legacy/trac/-/issues/17428 Flashproxy has been removed from Tor Browser], therefore it can be considered deprecated. * Old instructions: [[Deprecated#flashproxy]] = See Also = * [[Lantern]]: An alternative censorship circumvention tool documented for [[Qubes|{{q_project_name_long}}]] only. * ''Unfinished'': [[Censorship Circumvention Tools]] other than bridges. = Appendix = == Hosting Bridges == While most of this chapter is dedicated to bridge use, this section clarifies a few concepts about Tor Bridge hosting, although detailed how-to instructions are not provided. To help others you must reside in a country that does not censor Tor and have a reasonably fast connection. The VM or host in use should have port forwarding enabled to allow direct connections because all bridge server types require this, including Snowflake. Volunteer Snowflake instances run proxies to the bridge and are not bridges themselves. These proxies can be run behind a NAT because clients use the built-in NAT punching properties of WebRTC to connect. The proxies then open a WebSocket connection to the Snowflake bridge and relay data between the WebRTC connection with the client and the bridge. The Snowflake bridges cannot run behind a NAT and are similar to all other existing pluggable transports in this regard. https://gitlab.torproject.org/legacy/trac/-/wikis/doc/Snowflake Using bridge users' traffic to mask your own onion service traffic is difficult to do properly. https://github.com/mikeperry-tor/vanguards/blob/master/README_SECURITY.md#the-best-way-to-run-tor-relays-or-bridges-with-your-service This may be of questionable efficacy if traffic is not heavy and the bridge traffic of other pluggable transports is easily able to be excluded by advanced adversarial traffic analysis. In order to implement a similar defense using a Snowflake proxy (as opposed to a bridge), a custom client needs to be written that would encapsulate your Tor traffic and send it through a TCP WebSocket connection to the Snowflake bridge. This measure is ineffective for the same reasons bridge cover traffic is not. For other traffic to provide effective cover, client traffic needs to be mixed with concurrent, relayed Tor relay traffic; this may require a relatively high speed main network relay to be in use frequently enough to help. Note that website fingerprinting of client traffic is not a severe enough threat to warrant this type of defense for clearnet-destined tor traffic, but it is helpful to protect against end-to-end correlation attacks. https://lists.torproject.org/pipermail/tor-dev/2020-January/014127.html https://2019.www.torproject.org/docs/faq.html.en#BetterAnonymity == Active Probing == Various jurisdictions utilize active probing in order to block circumvention proxies, including different versions of Tor and the detection and blocking of bridges. Perhaps the most infamous example is the probing system used by the "Great Firewall of China" (GFW). The Tor Project first began exploring this issue in [https://gitlab.torproject.org/legacy/trac/-/issues/4185 October 2011]. At that time it was discovered that: https://blog.torproject.org/knock-knock-knockin-bridges-doors
...connections to US-based Tor bridge relays were being regularly cut off after a very short period of time. At the time we performed some basic experimentation and discovered that Chinese IPs (presumably at the behest of the Great Firewall of China, or GFW) would reach out to the US-based bridge and connect to it shortly after the Tor user in China connected, and, if successful, shortly thereafter the connection would be blocked by the GFW. There wasn't time for a detailed investigation and analysis at the time, but that kernel eventually grew into the investigation detailed below. We were, however, able to determine that limiting connections to the bridge relay to only the single IP expected to be its client would, in fact, block the probes and allow the connection to remain open for an extended period (>48 hours in our testing).
The Tor Project identified two types of probing: # Garbage binary probes: when an SSL connection took place, arbitrary binary data was sent to the non-China side of connections originating from China to TCP port 443 (HTTPS). [https://en.wikipedia.org/wiki/Deep_packet_inspection Deep packet inspection (DPI)] was suspected because the probe occured soon after the connection was established. At that time probing did not occur when the obfsproxy or plain-text protocols were used, presumably because a SSL handshake does not take place. # Tor probes: China-based Tor clients connecting to US-based bridge relays were probed at 15 minute intervals. The bridge received probes from China-based hosts that: established a TCP connection, performed a SSL negotiation, followed by a SSL renogotiation and the building of a one-hop circuit (including a BEGIN_DIR cell). To prevent probing, Tor developers then responded by changing the list of supported SSL ciphers included in the "hello" packet sent to Tor clients in China. They did note that ongoing Chinese censorship efforts would necessitate the development of new Tor protocols, handshakes and extensions over time, such as improved obfsproxy protocols. Further investigation of the GFW active probing system in 2015 revealed: https://blog.torproject.org/learning-more-about-gfws-active-probing-system * Bridges detected and blocked by the GFW remain blocked. However, a small window of opportunity was available around every 25 hours when Tor clients in China could connect to bridges. * TCP headers of active probes suggest the thousands of IP addresses are controlled by a single source and not independent computers. * The GFW also targets other circumvention systems like SoftEther and GoAgent. Suggesting the active probing system is modular in nature and can be configured to detect newer, proxy-based circumvention tools. * Bridges are probed by the GFW using the standard Tor protocol, as well as obfs2/3. * Tor probes had increased in frequency from 15 minute intervals to near real-time -- active probes emerged half a second after a bridge connection was established. * The GFW sensor is unable to reassemble TCP streams. In 2019, The Tor Project noted: https://blog.torproject.org/new-release-bridgedb-071
When the Great Firewall's active probing attack discovered a bridge, the GFW used to block the bridge by its IP address ''and'' port, which conveniently left other transport protocols that ran on the same IP address, say obfs4, reachable. This behavior changed recently, and bridges are now blocked by their IP address. This means that a protocol that is vulnerable to the GFW’s active probing attack (e.g., vanilla Tor, fte, and obfs3) can get the entire bridge blocked—including obfs4, which is resistant to active probing! The new BridgeDB release addresses this issue by only handing out a bridge’s probing-resistant protocols if the bridge supports protocols that are both vulnerable ''and'' resistant to active probing. For example, if a bridge supports both vanilla Tor and obfs4, then we ''only'' hand obfs4 to users.
Research suggests [https://www.cs.kau.se/philwint/scramblesuit/ ScrambleSuit] and [https://github.com/Yawning/obfs4/blob/master/doc/obfs4-spec.txt obfs4] can successfully defend against probing attacks, but their ongoing effectiveness will remain an open research question. The take-home message is that {{project_name_short}} users in heavily censored nations like China and Iran will require an obfs4 bridge or other probe-resistant protocols to try and circumvent censorship. For further reading on this topic, see: * [https://ensa.fi/active-probing/imc2015.pdf Examining How the Great Firewall Discovers Hidden Circumvention Servers] * [https://aaltodoc.aalto.fi/bitstream/handle/123456789/102539/master_Liubinskii_Pavel_2021.pdf?sequence=1&isAllowed=y The Great Firewall’s active probing circumvention technique with portknocking and SDN] * [https://medium.com/mobile-asia/demystifying-the-great-firewall-of-china-22f4a97550cc Demystifying the Great Firewall of China] * [https://www.usenix.org/system/files/conference/foci18/foci18-paper-dunna.pdf Analyzing China’s Blocking of Unpublished Tor Bridges] * [https://www.cs.kau.se/philwint/gfw/ How the Great Firewall of China is Blocking Tor] * [https://censorbib.nymity.ch/pdf/Frolov2020a.pdf Detecting Probe-resistant Proxies] = Footnotes = {{reflist|close=1}} = License = {{License_Amnesia|{{FULLPAGENAME}}}} {{Footer}} [[Category:Documentation]]