5 ms·
I used to live in a country who is also a customer of GFW. Before v2ray came out, I had figured out devising any random protocol would defeat it. I would pass m
by hks0 1y ago
I used to live in a country who is also a customer of GFW. Before v2ray came out, I had figured out devising any random protocol would defeat it. I would pass my SSH connecting used for socks5 through ROT13 or any ROTn, then the firewall won't gradually slow it down towards total stall after a few kilobytes. OpenSSH yells its name and version in plain text upon connection.
A few years later (still before v2ray) they got more aggressive: Unknown protocols were stalled after a few kilobytes. I then learned if I pretend I'm doing something legitimate (!) such as downloading favicon.ico within a proper HTTP channel, they won't touch my "packets" (the favicon content was my packet). I think there was also a Iodine project doing the same with ping packets but it was slower than favicon-as-packets for me. Today I see v2ray has taken it to the maximum extent, suggesting valid web page front for an IP, valid https certificates, etc.
When I started making money I was thinking about renting many IPs and send my traffic as round-robin to them as the detection relied heavily on IP consistency. That is, connections were fingerprinted by IP.
I don't live there anymore and don't get to verify this hypothesis, but given the leaked source codes it's an intersting weekend project.
What else is also interesting, I looked at traffic decoders in the list of leaked source files: TCP, HTTP, QUIC, ... but no mention of UDP, which made no difference in bypassing GFW. I guess the same IP rate limiter was at work with UDP at a lower level.
- hiddendoom45 1y agoFrom my own personal experience with an outline server running on the same IP over 3 years, the GFW consistently ends up blocking it around 3 days after I first connect. Outline does use shadowsocks to obfuscate but I suspect the traffic detection is what triggers it after 3 days of observations. Running multiple servers and repeatedly cycling through them is an experiment I want to try the next time I'm there. I've also observed similar behavior with the vpn I'm using as backup where the server I'm using tends to get blocked in around the same timeframe. It's using openvpn/wireguard as the underlying protocol which doesn't try to obfuscate itself so I suspect traffic pattern analysis plays a larger role in what gets blocked than the protocol itself. The exception was my recent trip week-long trip where I was mostly cycling between two servers without noticing either being blocked.
- hks0 1y agoMakes sense; the "3 days" you mention reminds me of something sad ~10 years ago. At an expo, there was this company "Dowran" with a banner boasting about "adjustable internet disruption patterns on demand" and other corporate catch phrases. I can assume there's an operator who installs GWF and puts "3" as part of installer wizard.
- protocolture 1y ago>GFW consistently ends up blocking it around 3 days after I first connect I saw a lot of speculation years ago that the GFW used to flag connections for human review. 3 days sounds like support ticket turnaround.
- cookiengineer 1y ago> I would pass my SSH connecting used for socks5 through ROT13 or any ROTn, then the firewall won't gradually slow it down towards total stall after a few kilobytes. OpenSSH yells its name and version in plain text upon connection. Could you elaborate on that more? I'd love to dig into an implementation that does this, in case you still have the tools/scripts/programs available. I'm asking because for the last couple years I've been on and off working on my warps [1] soft router prototype which aims to hide in plain sight using exfil network protocols. (Think of it like DNS/HTTP smuggling but with the idea to use similar techniques in other network protocols, too) [1] https://github.com/tholian-network/warps https://github.com/tholian-network/warps
- hks0 1y agoThe original PoC I had was incredibly simple: Just a python script that read traffic on a port on localhost, rotate each byte by a hard-coded number like 13, and send it over the wire. The counter part would run on the target server, read the byte and undo the rotation. It has zero (minus?) cryptographic security, but that's not the purpose here anyway. The PoV forwarder was transparent and could only tunnel port 22 of target server to 22000 of localhost. Later I made a more elaborate version where it implemented its own HTTP and SOCKS4/5 proxy servers; I think you won't like it :D I wrote it in Java using Netty more than a decade ago, and published to Github when I relocated. Using Java I could run it directly as an android app or on a PC more easily. This is the project: https://github.com/hkoosha/massrelay https://github.com/hkoosha/massrelay Using Netty's vocabulary: If you add one extra HTTP handler to the pipeline, you get what I initially implemented in various forms: - An HTTP handler that reads a header, say `Cache-Control: max-age=N` where N is the rotN to rotate bytes. - Next handler that starts rotating traffic bytes with the given `N` For favicon-as-packet, my implementation was again with massrelay project but I forgot all the details. It shouldn't be hard: Netty keeps track of the connection state (packet number, etc...) and the handlers wrap/unwrap the traffic within favicon as transferred within HTTP channel. Netty is a beautiful framework. I see you made your warps project in go, so the concepts might make more time to implement if you want to translate directly to a go project; Or you can just forget about massrelay and implement within your go project from scratch the way it makes sense, since the idea is pretty itself simple. (That being said, I think GWF has advanced a lot, that's why something proper like v2ray works better now).