Limited use cases but for moving info in and out of a system like this you should be able to use this https://en.m.wikipedia.org/wiki/Chaffing_and_winnowing
This is a really cool idea. Thanks for sharing.
How the great firewall of China detects and blocks fully encrypted traffic [pdf]
21–30 of 289 posts
Re: How the great firewall of China detects and blocks fully encrypted traffic [pdf]
#22Yeah already 10-12 years ago was clear. My university vpn only worked for a few days while studying in China. But there is this tiny little vpn software being spread around. Not sure if it's true but I remember it's falun gong teaming up with the CIA. Which at the time was able to go undetected, I think they keep rotating the IPS or something. Was interesting how fast that tool spread "offline" between international…
Nearly the same experience with my campus life.
Re: How the great firewall of China detects and blocks fully encrypted traffic [pdf]
#23I was wondering about simply using VPNs, which is not mentioned in the article at all, but checking GFW on Wikipedia, it tells: > The use of VPNs in China can provide individuals access to the international internet, but in China, it can be a potential legal risk. In 2017, the Chinese government declared all unauthorized VPN services to be illegal.[94] An example of the use of this punishment is Vera Zhou, a student…
And for those who don’t feel in legal jeopardy many VPNs are still being blocked and reconfigured in an endless arms race between the provider and the GFW
Re: How the great firewall of China detects and blocks fully encrypted traffic [pdf]
#24I was wondering about simply using VPNs, which is not mentioned in the article at all, but checking GFW on Wikipedia, it tells: > The use of VPNs in China can provide individuals access to the international internet, but in China, it can be a potential legal risk. In 2017, the Chinese government declared all unauthorized VPN services to be illegal.[94] An example of the use of this punishment is Vera Zhou, a student…
A lot of people actually use VPNs in China (since 2010 even), and some of them call it "加速器" which basically means "booster" (for your internet). Some use it for lower latencies when playing foreign games. The issue is that VPN connections get easily blocked. We aren't really worried about legal issues.
Except for that one time when police (of a certain district, not everywhere in China) knocked on people's doors to inspect their phones for VPNs during the "white paper protest" I believe.
Re: How the great firewall of China detects and blocks fully encrypted traffic [pdf]
#25I remember having to deal with the early GFW about 20 years ago when I was working for a company that had some employees on a site in Shanghai. Every morning, our colleagues in China would open their mail client and it would connect to our server abroad. The first person would usually be OK, but for everyone else, the connection would fail. At the time, almost nothing was known of the GFW and it wasn't as clever as i…
We have a satellite office in Dubai. I know their static IP. When they connect to our imap/smtp server they are coming in from another IP. I never looked into it deeply but assumed their connection is being diverted for inspection. (If true, they would probably not be below performing industrial espionage with the data they are accessing)
Is the IMAP/SMTP connection not encrypted?
Re: How the great firewall of China detects and blocks fully encrypted traffic [pdf]
#26Earlier quoted context omitted.
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.
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.
> 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!
Re: How the great firewall of China detects and blocks fully encrypted traffic [pdf]
#27The algorithm found seems so unintuitive that I wonder if it was not found by the AI. " Allow a connection to continue if the first TCP payload (pkt) sent by the client satisfies any of the following exemptions: Ex1: popcount(pkt) len(pkt) ≤ 3.4 or popcount(pkt) len(pkt) ≥ 4.6. Ex2: The first six (or more) bytes of pkt are [0x20,0x7e]. Ex3: More than 50% of pkt’s bytes are [0x20,0x7e]. Ex4: More than 20 contiguous by…
Looks more like it was found using random forests.
Re: How the great firewall of China detects and blocks fully encrypted traffic [pdf]
#28Earlier quoted context omitted.
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.
> 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!
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.
Re: How the great firewall of China detects and blocks fully encrypted traffic [pdf]
#29Earlier quoted context omitted.
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.
> 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!
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.
Re: How the great firewall of China detects and blocks fully encrypted traffic [pdf]
#30I remember having to deal with the early GFW about 20 years ago when I was working for a company that had some employees on a site in Shanghai. Every morning, our colleagues in China would open their mail client and it would connect to our server abroad. The first person would usually be OK, but for everyone else, the connection would fail. At the time, almost nothing was known of the GFW and it wasn't as clever as i…
We have a satellite office in Dubai. I know their static IP. When they connect to our imap/smtp server they are coming in from another IP. I never looked into it deeply but assumed their connection is being diverted for inspection. (If true, they would probably not be below performing industrial espionage with the data they are accessing)
At that level, there is no reason to proxy it through a different IP address. If you control the network, you can just make the packets come from the original, real address.