No wonder, according to an article someone wrote, where they tested IP addresses for this kind of block, more than 225 million IP’s are affected.
I can confirm that 16kb is enough to bootstrap snowflake, meaning 16kb whitelists do not affect snowflake reachability. However there is something else that does now. A dynamic system of punishment when you accidentally connect to random IPs that censors deem bad, it’s uncertain how or why it happens, it literally random. This especially affecting any p2p “spam” your system creates: such as torrents, dht and i2p. Snowflake can be counted as p2p spam if you accidentally connect to “bad ip”, so if your session drops and and suddenly all of cdn77 gets intercepted at handshake, that’s why
These censorship modules are like layers. Dynamic punishment acts above 16kb whitelists and is temporary, but packet manipulation software can only punch through either one, not both…
But is it enough to use Snowflake?
Do you mean the broker reachability, or just a bootstrap including the p2p connection?
Are those “layers” really that complicated? Do they really have filters like: “if a client connects to IP “A”, or any of that sort, then he gets banned from such for a random amount of time spanning from 1 minute to 4”, etc?…
Originally it was just dht from couple years back https://ntc.party/t/16713 now it devolved into this https://ntc.party/t/22222 where all major hosters are not reachable. Even git.kernel.org is not working for me right now, and not only me. People even on Twitter been posting about RKN blocking kernel.org I think it’s related
Yes, just tested it. Snowflakes not using tls/https, they use webrtc. Censors only killed off https with this INSANITY, something not even China dared to do. At this rate if webtunnel dies, obfs4 might go back into fashion. To unblock cdn77 for snowflake bootstrap, people can use zapret specifically with padencap and hostfakesplit strategies. It will restore handshake and first 16kb of data, enough to get snowflake going. Webtunnels more vulnerable right now and obfs4 could be new “underdog”
If anyone reading this and is node operator PLEASE, DO NOT HOST on major hosting providers like aws, akamai, vultr, cdnext, cdn77, scaleway etc. They all screwed right now
1 Like
Thanks for clarifying.
*Bridge node operators, and if you want to know more about the affected providers, you can find the whole list here. (Russian tech article site, mind you) Most residential connections are most likely not affected.
As I understand it, these modules are software. They can even conflict with each other. There’s a known anti-fake module, 16 KB. Perhaps something new has appeared, but there’s little information yet.
A utility for testing blocking types. It may help bypass bridge blocking.
I’m no longer seeing blocked access to at least following providers: hetzner, cdn77, scaleway, aws, akamai, fastly, frantech
cdnext, vultr, ovh, digitalocean however are still not available according to this checker RU :: TCP 16-20 DPI Checker
personal checks below
cdn77 
(www.cdn77.com)
$ curl -v4 --connect-to ::89.222.123.18:443 --max-time 1 https://example.com
* Connecting to hostname: 89.222.123.18
* Connecting to port: 443
* Trying 89.222.123.18:443...
* TCP_NODELAY set
* Connected to 89.222.123.18 (89.222.123.18) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
cdnext 
(ip.me)
$ curl -v4 --connect-to ::212.102.35.236:443 --max-time 1 https://example.com
* Connecting to hostname: 212.102.35.236
* Connecting to port: 443
* Trying 212.102.35.236:443...
* TCP_NODELAY set
* Connected to 212.102.35.236 (212.102.35.236) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* Operation timed out after 1001 milliseconds with 0 out of 0 bytes received
* Closing connection 0
curl: (28) Operation timed out after 1001 milliseconds with 0 out of 0 bytes received
That being said, 16kb throttle thingy is still there, but at least there is more room to breathe now
1 Like
I noticed something about obfs4 bridges and major hosting providers with 16kb throttle thing.
Me and a friend were testing private obfs4 bridge and I noticed that the same 16kb apparently apply to all ports and to junk traffic of obfs4 when bridge is hosted on major providers, I will attach shark screenshot so I am more credible.
Connection freezes at random points, where maximum it can sometimes reach is 95% bootstrap and then does general socks failure error. Similar to how random bootstrapping was behaving with snowflake and cdn77
However, I have no idea how it works or what censors are smoking, but feeding it whitelisted sni (yes, to raw IP on random port) somehow punches through, much like with tls/443 you just need to know whitelisted sni for that hoster. Then you can use zapret’s custom scripts and add obfs4’s bridge with strategy that uses fake-unknown instead of fake-tls with any-protocol=1 and cutoff=d2 enabled.
According to the statistics, the number of snowflake bridge users has dropped, but I don’t see any reports of problems.
Most obfs4 bridge connections are blocked on most residential DPI-enabled providers because of them looking like a snippet of code with “fully encrypted traffic”. It doesn’t right away mean that it’s a manual block at all. You can get around that specifically, sometimes it’s that the bridge is blocked by IP/port or you can get under some 16kb block.
https://ntc.party/t/обход-блокировки-протокола-obfs4/19048/12
Is it possible to use stun.vk.com for snowflake bootstrap and to deploy peers in belarus and kazakhstan? They recently allowed max.ru to be made for foreigners so I doubt they gonna block voice connections to friendly nations now, and in all their wisdom, max messenger uses webrtc, same as snowflake so protocol should be immune
I can’t explain this drop in bridge users, as there were no reports of problems. It might be related to whitelisting in Moscow, but I’m not sure.
Before you start messing with zapret, you can actually verify obfs4 is good or not by doing verbose curl -v with –connect-to ::obfs4:port option and any random domain like https://example.com
You supposed to see generated client hello in curl and broken ssl error reply when it’s not ip ban. You won’t get anything if it’s ip ban. Basically you looking for existence of 3-way-handshake, it doesn’t exist on ip bans
The new block against VLESS appears to be affecting bridges.