5 ms·

Seems like UDP is completely exempt, which would allow UDP-based VPNs, like Wireguard through. SSH is also exempt...

by Ballas 3y ago

WinstonSmith84 3y ago
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 ...
- throwawayadvsec 3y ago
  steganography?
  - Ballas 3y ago
    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).
- reaperman 3y ago
  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. 0: https://people.cs.umass.edu/~amir/papers/parrot.pdf https://people.cs.umass.edu/~amir/papers/parrot.pdf
  - blablablub 3y ago
    all https traffic to servers outside of china gets slowed down to a crawl after the first MB of send data.
sysstemlord 3y ago
I'd go for ssh if I was trying to bypass it. At least legally I can claim that I'm just sshing to my aws server and not be jailed for using vpn.
- yorwba 3y ago
  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.
  - 6LLvveMx2koXfwn 3y ago
    > And ssh tunneling web traffic looks quite different from normal ssh usage anyways. Could you explain this further, this seems counter to my understanding of encrypted traffic!
    - yorwba 3y ago
      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.
    - praash 3y ago
      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.
lordnacho 3y ago
Why would they let that happen? Doesn't seem to make any sense to me if it's how you describe it.
- Ballas 3y ago
  Yes, that is why I also found it interesting. As to their motives - I cannot comment.
Hikikomori 3y ago
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.
blablablub 3y ago
Wireguard is detected within the first minute of usage and blocked. The ping is a dead giveaway.
- Ballas 3y ago
  Interesting. I was just going on my limited scan through the linked PDF, which evidently was not thorough enough.
jongjong 3y ago
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.
- netheril96 3y ago
  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.

Seems like UDP is completely exempt, which would allow UDP-based VPNs, like Wireguard through. SSH is also exempt...

by Ballas 3y ago

Seems like UDP is completely exempt, which would allow UDP-based VPNs, like Wireguard through. SSH is also exempt...

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 ...

throwawayadvsec 3y ago
steganography?
- Ballas 3y ago
  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).
reaperman 3y ago
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. 0: https://people.cs.umass.edu/~amir/papers/parrot.pdf https://people.cs.umass.edu/~amir/papers/parrot.pdf
- blablablub 3y ago
  all https traffic to servers outside of china gets slowed down to a crawl after the first MB of send data.

sysstemlord 3y ago

I'd go for ssh if I was trying to bypass it. At least legally I can claim that I'm just sshing to my aws server and not be jailed for using vpn.

yorwba 3y ago
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.
- 6LLvveMx2koXfwn 3y ago
  > And ssh tunneling web traffic looks quite different from normal ssh usage anyways. Could you explain this further, this seems counter to my understanding of encrypted traffic!
  - yorwba 3y ago
    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.
  - praash 3y ago
    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.

lordnacho 3y ago

Why would they let that happen? Doesn't seem to make any sense to me if it's how you describe it.

Ballas 3y ago
Yes, that is why I also found it interesting. As to their motives - I cannot comment.

Hikikomori 3y ago

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.

blablablub 3y ago

Wireguard is detected within the first minute of usage and blocked. The ping is a dead giveaway.

Ballas 3y ago
Interesting. I was just going on my limited scan through the linked PDF, which evidently was not thorough enough.

jongjong 3y ago

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.

netheril96 3y ago
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.