Went to china some years ago and my pptp vpn blocked after a day. Switched to ssh and after a day it was rate limited to basically nothing, but I could avoid that by switching port every morning.
Trying to get off the hook on a technicality isn't going to work. Lots of people use VPNs completely in the open without getting jailed, because they're not otherwise of interest, but if you are being targeted, nobody is going to care about your "sshing to aws" excuse. And ssh tunneling web traffic looks quite different from normal ssh usage anyways.
I assume the timing patterns and amounts of data would likely be distinct between SSH and web. "Normal" SSH usage would mostly consist of much lighter packets, such as user keystrokes and terminal screenfuls of text. Typing tiny commands and getting a few kilobytes of output. SSH file transfers happen occasionally, sometimes with a large bulk of data.
Active web browsing requires downloading a crapton of files with wildly different sizes and sporadic timings between them.
Add normal user interaction, API requests, ad cycles, long video streams that won't max out all bandwidth, all happening at once across multiple tabs. The client also sends much more data with each TLS handshake and all those HTTP headers.
This could probably be masked by deliberately filling idle periods with garbage data just to appear as a stable data stream both ways.
Forget using a real web browser over an SSH proxy. What using elinks on a remote host with ssh? I bet somebody using elinks across ssh is virtually indistinguishable from somebody using a text editor.
SSH encryption only hides the content, not how much is being sent and when. When your browser fires off a bunch of requests to load a webpage, the timing is different from running typical commands on a server and receiving the output.
> At least legally I can claim that I'm just sshing to my aws server and not be jailed for using vpn.
Your mistake is assuming that China has rule of law. If you're in China and you upset Xi enough, you get jailed/disappeared even if you technically didn't break any laws on the books.
Could be a use case for X-Windows with ssh -X [0]? (so your web browser is actually running outside the GFW, it's just the window updates that are coming over the SSH tunnel).
any ssh traffic that does not look like ssh traffic (few bytes send to server, some more bytes returned) gets either terminated or slowed down to a crawl
Does this mean that in addition of the classic fail2ban, geoip firewall, or forever super slow login banners, we could also have a honey pot sending a lot of data with a traffic pattern similar than web browsing ?
I was told that SOCKS proxies (which let you tunnel over SSH) are popular in China. It's super easy to setup and you don't need to install anything. You just need to SSH into any Linux EC2 instance outside of your network with ssh -D $port_number $username@$hostname and change a simple setting in your browser to proxy through that node using SOCKS5. It's nice because you still control the remote host (no need to trust some third party VPN) and the traffic is encrypted between your remote host and your local host (where it counts)... Anyone snooping would just think that you're SSHing into your EC2 instance for work purposes and not realize you're using it to browse the net.
You were told wrong. If you uses SSH as a proxy, the connection will be slowed down to a crawl very soon. GFW distinguishes this from SSH command typing by looking at the traffic. This has been in place for at least a decade.
that's mentioned at the end of Page 17. The author tells it's a short term solution: "This is merely a stopgap measure, as the censor can enable their censorship for UDP."
It doesn't seem that there are any (long term) solution to bypass the rules ...
It does seem like this GFW scheme can be tuned to severely degrade the reliability of any unapproved high entropy traffic. However, this single scheme doesn't cover many other types of circumvention traffic, several of which are noted in the beginning of the paper. This scheme primarily applies to "fully encrypted" traffic - not SSL/TLS, etc.
So for now, circumvention can live on, but this explains to everyone using fully encrypted protocols exactly why their connections would have been degraded over the past couple years. In the long term, steganography will probably work well as long as users are able to endure much higher costs for traffic (low ratio of true data to apparent data) and as long as the steganographic systems are effective at hiding any statistical fingerprints (very difficult). Protocol mimicry is another strategy, but a paper cited in this work details why successful protocol mimicry is very difficult.[0]
Attempts to disguise circumvention traffic as typical traffic is very difficult, because a lot of fingerprinting information can be gleaned from handshakes and headers. The draw of fully encrypted traffic is that it provides very little variation which can be used to fingerprint and classify different types of usages. However, it's also easy to detect and block en masse -- that much is obvious, but this paper does a great job of showing how China does it and inferences can be made from that to provide a view into China's priorities (how much cost they're willing to incur, rates of false positives they feel is acceptable). Overall, China's blocking current appears to be fairly conservative here, with relatively low rates of false positives.
In wider context, China is constantly updating their detection schemes, they're quite competent at it, and anything which doesn't match typical traffic is at risk.
Hiding the encrypted messages so that it looks like other normal traffic. Like encoding your encrypted message (subtly) in the pixels of an image (like noise).