I live in mainland China, and recently, Shadowsocks and obfs4 became unavailable in my area. However, after wrapping Shadowsocks traffic in HTTP (HTTP PHT), Shadowsocks became available again.
The method I used was to use the gost software to set up a Shadowsocks+PHT transport mode proxy (as shown in the diagram).
I think a similar method can also restore the availability of obfs4 in China. Of course, I think it would be better to directly enable the FTE bridge.
Did you tried wrapping traffic with Yggdrasil? I just wonder if it is blocked in China and if it can be used for censorship circumvention.
Do you believe they are blocking Fully Encrypted Protocols in your area like it was detected in past? AFAIK China has used this kind of censorship only for short periods of time, it will be something new if this lasts for long.
You can try using webtunnel bridges as they also use HTTP as transport (in this case websockets). You can request a bridge in https://bridges.torproject.org
You could use FTE if you want if you set it manually in tor and run your own bridge. But FTE is unmaintained since a decade and AFAIK it was detected by censors.
Yes, FTE was detected and therefore unable to connect.
However, strangely, my server and FTE use a similar principle (wrapping Shadowsocks AEAD encrypted traffic in HTTP/1.1, using GET and POST methods for transmission), but it hasnât been blocked by the GFW.
By the way, Chinaâs internet censorship is not âuniformly implementedâ. For example, in my location (Henan Province, China), obfs4 can connect via IPv6, but in other provinces, itâs not possible.
Similarly, recently, some provinces in China have started indiscriminately blocking TLS communications that use the GTS WR2 intermediate certificate, but this hasnât happened here.
I havenât tried it yet, Iâll test Yggdrasil later to see if it can bypass the GFW.
(ADHDing)
The developer of Yggdrasil has made it clear many times (in a chat room) that while yggdrasil does work like a censorship circumvention tool, it isnât meant for that sort of thing. So itâs not something that people should count on long term.
With Shadowsocks, you can try the prefix support in the Outline client.
Disguise connections with a prefix to bypass protocol allowlists
As of Outline Client version 1.9.0, access keys support the âprefixâ option. The âprefixâ is a list of bytes used as the first bytes of the salt of a Shadowsocks TCP connection. This can make the connection look like a protocol that is allowed in the network, circumventing firewalls that reject protocols they donât recognize.
Here is some analysis of various prefixes against fully encrypted protocol blocking in Russia this year.
Sorry, Yggdrasilâs configuration is still a bit complex for me (ADHD patientâs complaint).
Iâm more used to graphical operations, so I couldnât perform the test.
Good idea, Iâll go try it later
With Shadowsocks, you can try the prefix support in the Outline client.
Great! Outlineâs prefix function works perfectly.
However, Iâm thinking about whether a similar method can be used for the obfs4 protocol? This way, we can also restore obfs4âs availability in China/Russia.
It is somewhat possible to do something similar with obfs4, though itâs not as flexible. The bytes at the beginning of an obfs4 handshake represent an Elligator public key representative, which (by design) looks random. You can repeatedly generate public keys until you get one with a representative whose prefix is less random than usual (all printable ASCII, for example). You canât really specify an exact prefix, unless it is quite short. In other words, with obfs4, you can do the âaltering popcountâ defense but not really the âcustomizable payload prefixâ defense.
I thought I had a patch somewhere to make obfs4proxy use client public key representatives whose prefix was all printable ASCII, but I cannot find it now. As I recall, the patch was not very invasive, just a loop around ntor.NewKeypair.
