bbs
bbs copied to clipboard
net4people
Weird and wonderful
We've seen a tightening of restrictions this year in Iran, Russia, and other countries. The counter-censorship measures that tend to get blocked are the ones everyone uses. If you're a firewall operator, and you see 1,000,000 people all using a certain method, then that's where you'll concentrate your efforts.
From the individual's point of view, it makes sense to keep in reserve a few "weird and wonderful" methods -- oddball techniques that very few people use. You're more likely to survive if you're not the low-hanging fruit.
I've compiled a couple of lists of these "last resort" methods. These methods are intended to be obscure rather than speedy. One list is at the bottom of the "summary of methods" post on the old blog here:
- Iodine DNS tunnel
- pingtunnel ICMP tunnel
- V2Ray + meek
- SS over SSH over VLESS
- Shadowsocks over Restls
A second collection of "last resort" methods is on the new blog here:
- OpenVPN over Shadowsocks
- WireGuard over Xray
- Tor obfs4 bridge with iat-mode=2
- OpenVPN + Cloak
- OpenVPN + Obfs4
- WireGuard + TCP
- Obfuscated SSH
Hopefully one of these will work if you ever find all your preferred methods have been blocked.
To add another trick to the list: you can revive a vanilla Tor bridge with a fake, whitelisted SNI. Just change a single line in C Tor and you're good to go, at least in Iran. You'll also need traffic shaping and more in China, but that project is long dead due to changes in GnuTLS and OpenSSL.
Tor obfs4 bridge with iat-mode=2
I don't think this is accurate. What really works in IR is Tor Snowflake - https://metrics.torproject.org/userstats-bridge-combined.html?start=2023-05-30&end=2023-08-28&country=ir
you can revive a vanilla Tor bridge with a fake, whitelisted SNI. Just change a single line in C Tor and you're good to go, at least in Iran.
More details on this point:
https://ntc.party/t/tor-relay-tls-clienthello-sni-fingerprinting/3922
Iranian ParsOnline ISP has a regexp filter for the domain generation algorithm used in Tor for ClientHello SNI field.
www\.[a-z]{4,25}\.comhttps://gitlab.torproject.org/tpo/core/tor/-/blob/21b3397f9b0803134bc458b83cd161de259887fd/src/lib/tls/tortls_openssl.c#L1082
You can connect to the majority of Tor relays, but the connection would freeze if this type of SNI is used along with ClientHello size <= 256 bytes. Changing the domain name even slightly, like .com to .org allows to connect to Tor Relay. This filter seem to be applied only to known Relays IP addresses in Tor network.
- Iodine DNS tunnel
For use cases involving Iodine, consider dnstt: it likely has better performance, and can work with DoH and DoT resolvers.
DNS and ICMP tunnels are very slow, but I agree that they can be used in case of dire need. Other tools worth people's attention:
Stunnel - Universal TLS wrapper with socks5 built-in
Tinc - A peer-to-peer mesh-like VPN with long history, the first release was made in late 90s.
SoftEther - A TLS VPN but more like an ethernet wire emulator. You can even run non-IP protocol on it. It comes with a standalone GUI server manager. (Important: fresh installed SoftEther contains certificates that immediately trigger blocking. Either configure it to use your own certificate under SSH or connect GUI server manager via an existing proxy to configure its certificate.)
@nametoolong
Since you mentioned traffic shaping, I wonder if anyone has ever used "Dust" v1 and v2 and its ongoing successor project "ShapeShifter" Transports. Dust's presentation looked promising when it was introduced and it makes me wonder why we do not hear about this project very often!
I did some experiments with Dust. Its concept was really fancy; it was complicated and not as performant as ScrambleSuit; its shaping layer was a parrot that researchers have doubt on. The community later moved on and made heavier use of tunneling-based solutions.
I believe protocol mimicry has its advantage. With mimicry, a user can easily find an unblocked spot in the feature space. For large-scale deployment, however, everyone wants stability. Maybe you remember constantly changing protocols a decade ago? Mimicry encourages constant cat-and-mouse game as despised by proxy operators, who generally prefer the higher adversarial computational cost associated with identifying an encrypted tunnel. Since the cat-and-mouse game never stops, protocol mimicry might have a second spring in the future when circumvention becomes more decentralized.
For use cases involving Iodine, consider dnstt: it likely has better performance, and can work with DoH and DoT resolvers.
Is DNS-over-HTTPS blocked in China?
Is DNS-over-HTTPS blocked in China?
In general, yes, DoH is blocked in China (see e.g. Section V-E of this), but dnstt can also run in a plain UDP/53 mode like Iodine. It's not good for circumvention except against a naive censor, because the hostname of the dnstt server is exposed in DNS messages, but the same concern exists with Iodine on UDP/53. The benefits of dnstt is that it can go a lot faster and it is always encrypted to prevent inspection or tampering by the intermediate resolver.
@wkrp Thanks. I have added dnstt to the "weird and wonderful" list as a modern replacement for Iodine.
- #336 -- using residential proxy services to shape traffic patterns
- https://github.com/quiet/quiet-lwip -- use audio to run TCP connections, and therefore proxy traffic through arbitrary VoIP services
