Stop using obfs4 protocol for bridges or anything else. The developer has been saying this for years. : OpSec | Torhoo darknet markets

This is no news.

As the maintainer writes back in 2023, obfs4 passed it's shelf-life expired date years back. Yes, can only agree, government censorship has matured a lot since 2014 (first release of obfs4).

What's annoying is the statement "there are massive issues in the protocol", and then no explanation, nothing in the backlog. What the maintainer say is an obfuscation it self. One thing is clear, it's possible to detect the Tor use with modern network analyzers, and that's bad. But if there is other issues, is unclear.

Tails with Tor Browser does not provide alternative obfuscation protocols.

Best option if Tor traffic must be hidden is to use a VPN connection to a country where Tor is allowed. The user must ensure that there are no DNS-leaks or WebRTC-leaks, thus this would also reveal Tor usage.

Seems a misunderstanding in the language. There is a difference between circumvention and hiding.

Circumvention is when you don't care if Tor is detected but only want to bypass network filters of any kind to get your connection across the firewall. Circumvention is used in network environments where lets say the ISP doesn't want Tor running but in general accepted sense Tor usage is allowed.

Hiding is when you care if Tor is detected and you must hide the fact you're using Tor. Hiding is used in restrictive network environments where the government forbids VPNs (like China) or at the very least such capability is neutralized as much as possible.


With that linguistic confusion cleared lets focus on OBFS4. OBFS4 was never about hiding Tor usage but circumventing restrictive environments to allow Tor usage.





Correctly configured on both client and server VPN, SSH or modern(!) proxy tunnels like XTLS.

Despite what is claimed under

[whonix org/wiki/Bridges]

Please note that it has been assessed as difficult beyond practicality to Hide Tor use from the Internet Service Provider with proxies, bridges, VPNs or SSH tunnels.

and the pure assumption (not based on any facts or research) from

[gitlab torproject org/legacy/trac/-/wikis/doc/TorPlusVPN#VPNSSHFingerprinting]

Once the premise is accepted, that VPN's and SSH's can leak which website one is visiting with a high accuracy, it's not difficult to imagine, that also encrypted Tor traffic hidden by a VPN's or SSH's could be classified. There are no research papers on that topic.

such attacks aren't practical against correctly configured VPN solutions. Although for anonymity reason (global adversary perspective) it wouldn't be recommend to connect VPN before Tor, if you have no choice or want to mask completely Tor usage, this can be the way.

Tor provides additional protections against this type of attack. Another note is when the research for these attacks had been presented it would come from adversary view of determining if you use Tor inside VPN [VPN(Tor)]. Nowhere did any researchers present concrete evidence or assumptions such adversary can leverage these attacks to see websites you'll visit within that encapsulated tunnel. Such would mean the VPN tunnel is broken beforehand.

Adding OBFS4 connection or going one step further and using only .onions would make Tor usage undetectable from any other VPN connection in the scenario of Tor inside VPN. Note again the circumvent vs hiding aspect.





Firewall restrictions are in many cases unique to the ISP or network you are on. To perhaps illustrate what is meant by circumvention lets take the scenario being on a hotel network or hotspot at airport both usually make you pay. Since we are a bit technically inclined we can bypass it by preparing in advance.

If common tricks like VPN with 80/443/high port numbers, TLS-CRYPT, obfs4, ssh, ssl don't work there's always another solution.

You can run a simple VPN server but channel it through port 53 (DNS) and connect to it before entering any information or payment details. Majority of places are misconfigured and will allow valid DNS requests to get the actual IPs of services. Such setup can be achieved with iodine. The bandwidth is asymmetrical and limited but it would get you through. Once connected to the VPN you can now connect to Tor.

Adding OBFS4 connection can be additionally beneficial as in the hiding example.



Now the basics are covered.





Despite the overblown title by /u/socat2me there is some truth to the words. OBFS4 in its default state has been for some time now detected by different regimes who crack down on such connections on their countries networks. OBFS4 doesn't hide well the fact you are connecting to Tor.

However OBFS4 isn't useless and is overall better to use it than most other suggested pluggable transports.

Not a very discussed option but IAT (Inter-Arrival Time) mode is something you've all probably seen at the end of your OBFS4 bridges. Some have IAT-MODE 0 while others 1 and 2.

[whonix org/wiki/Bridges]

Trying Packet Size and Timing Obfuscation for obfs4

If a provided 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. [18]

IAT mode helps screw up any timing signatures for restrictive firewalls by changing the timing between different sets of bytes essentially splitting larger packet into chunks.

[github com/Yawning/obfs4/blob/master/transports/obfs4/obfs4.go]

Standard (ScrambleSuit-style) IAT obfuscation optimizes for bulk transport and will write ~MTU sized frames when possible.

If you've read a bit more on the quoted Go file you'll see performance is impacted if you enable the paranoid (2) option.

[computerscot github io/tor-obfs4-bridge-iat-mode-2.html & jmwample github io/ptrs/]

iat-mode=0 (no obfuscation) / Pass-through
iat-mode=1 (split data into fixed-length packets) / Pad to MTU
iat-mode=2 (split data into variable-length packets)

If you are a visual learner I suggest the following website (WARNING JS ENABLED) demonstrating & explaining every OBSF4 byte

jmwample github io/ptrs/

Remember IAT mode works correctly only when both sides enable it. If server has it on 0 but you put 1 in your torrc client config, you won't benefit.

Excellent tutorial how to create a private or public OBFS4 bridge with IAT mode 2 (or 1)

computerscot github io/tor-obfs4-bridge-iat-mode-2.html

I did read some research though suggesting the juice isn't worth the squeeze. I apologize I can't find the links to that perhaps someone can dig find it. However users in places like Iran or Turkmenistan and other places have reported success with public OBFS4 bridges but with IAT-MODE=2.

Correctly configured private OBFS4 bridges with IAT-MODE=2 are currently working in China for at least a couple of weeks. A very viable option if you can spin up a few instances per month.

Additional bypass methods which can make your server less likely to get blacklisted by GFW would be to place the servers in Chinese administered regions or friendly to it countries.

Currently other type of Tor-provided transports don't work in China at all or are available for very small period of time (like webtunnel).



It does seem Dread would benefit from writing up on some additional techniques & tools to bypass restrictive regime firewalls.

least obvious fed

thank you for posting this

it's still the primary bridge type because the purpose of bridges is firewall evasion and obfs4 is simple and cheap to setup
the problem arises when some opsec "gurus" recommend it for hiding Tor usage

obfs4 is not designed to hide Tor usage
everyone should keep that in mind

Such a shame TailsOS is still not supporting webtunnel.

In the countries with Great Firewall, private Obfs4 bridge is the easiest and probably only way to by pass the GFW. I am open to hear better solution though!

FUCK WHICH ONE OF YOU IS WATCHING ME WATCH MINECRAFT PORN HUH.....HUH.....!!!!!!!