Slashdot Mirror


VPN Providers Say China Blocks Encryption Using Machine Learning Algorithms

An anonymous reader writes "The internet control in China seems to have been tightened recently, according to the Guardian. Several VPN providers claimed that the censorship system can 'learn, discover and block' encrypted VPN protocols. Using machine learning algorithms in protocol classification is not exactly a new topic in the field. And given the fact that even the founding father of the 'Great Firewall,' Fan Bingxing himself, has also written a paper about utilizing machine learning algorithm in encrypted traffic analysis, it would be not surprising at all if they are now starting to identify suspicious encrypted traffic using numerically efficient classifiers. So the arm race between anti-censorship and surveillance technology goes on."

27 of 111 comments (clear)

  1. Havoc by Anonymous Coward · · Score: 5, Interesting

    This has been causing havoc and reduces availability and integrity of our VPN access to our Chinese clients. The insane part is, most of them are in the aerospace and defense industry and are usually mostly owned by the Chinese government. It's indiscriminate. So far steganography techniques have worked, at the reduction of speed and standardisation, but it's hard to explain to clients why they suddenly can't access network resources and expect your company to fix everything.

    1. Re:Havoc by Anonymous Coward · · Score: 2, Interesting

      What steganography techniques? Like masking your VPN link as streaming audio/video?

    2. Re:Havoc by Anonymous Coward · · Score: 5, Interesting

      Yes, basically. We created software which encapsulates the connection in another protocol and re-encodes the data, shoved it in a VM and put one here and over there. We made it modularised so we can create support for new protocols and encoding easily. It's slower and usually requires a higher tolerance latency and bandwidth configuration for the protocol you are tunnelling but I'm surprised we whipped it up so quickly and it works.

  2. This is true by sadboyzz · · Score: 5, Informative

    I was just in Beijing for two weeks. I have access to two OpenVPN servers, one in New York another in California. These are personal servers so they aren't on the IP based blacklist. However, my connection from Beijing to either of the two would crap out after a day or two, and the only remedy was to change the OpenVPN server port.

    It seems right now they update their blacklist every 24~48 hours. I did not test whether the amount of traffic (idle vs. busy) would affect the time it takes them to block you. Blacklists last longer than two weeks, as the original ports I used was still blocked by the time I left. SSH connections does not seem to be affected at this time.

    1. Re:This is true by GameboyRMH · · Score: 2, Funny

      SSH connections does not seem to be affected at this time.

      Can you find a solution to your problem then?

      *Jeopardy music*

      --
      "When information is power, privacy is freedom" - Jah-Wren Ryel
    2. Re:This is true by VortexCortex · · Score: 5, Funny

      SSH connections does not seem to be affected at this time.

      Can you find a solution to your problem then?

      *Jeopardy music*

      Let's see what Tim has. You've written, "Don't do business in China", I'm sorry, we were looking for "SSH tunneling". Susan, you've written, "Port Changing Cron Job", no, that's incorrect as well. Yiu? You've written, "There is no Problem"... No, that's incorr--- Wait, the judges say we'll accept that answer, Yiu Wins!

    3. Re:This is true by sadboyzz · · Score: 4, Insightful

      I find SSH tunneling to be much less efficient than OpenVPN. With OpenVPN I can have a more-or-less usable remote VNC desktop from Beijing to New York, which is not possible using SSH tunneling.

      Anyway, that is not a real solution, as there is nothing to prevent them from cutting off SSH connections when they feel like it. There is no technical solution to a political problem.

    4. Re:This is true by LordLimecat · · Score: 2

      Why not run OpenVPN (An SSL vpn) over TCP 443? I mean, unless they intend to block SSL as well...

    5. Re:This is true by sadboyzz · · Score: 4, Informative

      Yes, I did, it does not work, they are able to distinguish VPN from HTTPS traffic. Their detection scheme doesn't seem to care about the port number.

  3. Re:"Arm race"? by SJHillman · · Score: 3, Funny

    It's actually a race between severed zombie limbs.

  4. Noise. by Anonymous Coward · · Score: 5, Insightful

    Raise the noise floor, hide your encrypted data among legitimate looking traffic. For various meanings of legitimate. One can only fathom the amount of useless garbage that gets passed on backbone links. From malfunctioning programs, unknown millions of installations of random programs phoning home for updates, spam, web bots, ddos, facebook. An endless sea of data for your subversive little packets to get lost in.

    Less efficient? Sure. But a lot harder to find.

    So what if they have adaptive learning sniffers. We can invent adaptive learning garbage a whole lot faster than they can keep up.

    1. Re:Noise. by cpghost · · Score: 2

      So what if they have adaptive learning sniffers.

      If they had this, they would have solved the spam problem by now... Speaking of spam: by intelligently encoding your encrypted data as spam, you could pass through the sniffers too.

      --
      cpghost at Cordula's Web.
    2. Re:Noise. by nurb432 · · Score: 2

      That used to be a good idea, but as more and more governments get access to supercomputers that they can dedicate to 'monitoring', it wont work for long. Its really not hard to pick out that needle in the haystack if you have the resources.

      And remember in countries like china, they dont care what you are transmitting, the act of hiding is enough to get you jailed or executed.

      --
      ---- Booth was a patriot ----
    3. Re:Noise. by snemarch · · Score: 2

      So, we encode the bitstreams as "viagra" for 1, "penis!" for 0? (same length strings, obviously, to make the processing more efficient).

      --
      Coffee-driven development.
  5. Is that a DOS vector? by bigtrike · · Score: 4, Interesting

    You might be able to use this to simulate encrypted traffic to something legitimate and cause it to be blocked.

    1. Re:Is that a DOS vector? by bigtrike · · Score: 2

      I may be making bad assumptions here, my TCP and UDP knowledge is pretty rusty. It seems like if the algorithm wasn't smart enough to keep track of the full connection state, you could spoof a protocol appropriate TCP or UDP packet from the remote IP and port to avoid a block. Alternately, you might be able to avoid detection by using a common port like 53 for your UDP VPN and spoofing valid DNS response packets. If that caused problems for your VPN client, you could set a flag on them that causes them to be dropped or allows you to drop them before they confuse the client such as the fragment bit or the evil bit.

  6. Tunneling through SSH comes to mind. by Anonymous Coward · · Score: 5, Interesting

    The interesting question is if they man-in-the-middle it.

    1. Re:Tunneling through SSH comes to mind. by PlusFiveTroll · · Score: 3, Informative

      Being that his computer already knows the signature of his server, it would show up very quickly.

    2. Re:Tunneling through SSH comes to mind. by postbigbang · · Score: 2

      Deep packet inspection can turn up lots of easily identifiable behavior. Port scrambling, intentional service misidentification, mixing bogus streams with encrypted ones, bursting traffic over multiple IPv6s, all can make a difference.

      But an ssh link is easily identifiable. They don't have to read anything, just block stuff. Experience as a teacher, 100% of what you do gets seen; what goes through is an algorithm that changes as they like it to.

      They'll perform one block, but it seems tough for them to have lots of blocks running concurrently. Cat and mouse, and it'll be that way for the foreseeable future.

      --
      ---- Teach Peace. It's Cheaper Than War.
  7. Targetting commercial VPN providers? by Keruo · · Score: 3, Interesting

    I'm assuming they're targetting commercial vpn providers rather than companies using VPN?
    If not, I'd like to get some address where to register corporate endpoints which should be excluded from filtering.
    Otherwise managing workstations and servers located in China might become rather tedious.
    Atleast this IPSEC VPN to China which I'm using to post this message seems to work just fine right now.

    --
    There are no atheists when recovering from tape backup.
  8. Only big pipes are affected by cpghost · · Score: 5, Interesting

    If you need a narrow band VPN, you could always encrypt it in such a way that it can't be detected by the sniffers. For example, use something like the technique used by port knocking, i.e. utilize the time domain for your encrypted channel. In other words, don't send encrypted data directly, just send regular data and modulate the time intervals between the packets to reflect your encrypted data.

    --
    cpghost at Cordula's Web.
    1. Re:Only big pipes are affected by slew · · Score: 2

      If you need a narrow band VPN, you could always encrypt it in such a way that it can't be detected by the sniffers. For example, use something like the technique used by port knocking, i.e. utilize the time domain for your encrypted channel. In other words, don't send encrypted data directly, just send regular data and modulate the time intervals between the packets to reflect your encrypted data.

      That's likely to be really low bandwidth and a bright target for thier firewall learning algorithms. Modulating the time intervals on a high-latency connection with the typically large amount of buffering will be troublesome if the just randomly drop packets on suspicious connections and wait for TCP/IP retransmit. Of course you could hack your TCP/IP stack to be aware of this, but that's quite a bit of work.

  9. It may be bad, but... by MightyMartian · · Score: 2

    It certainly sucks, and is bad for business, but slowing down or shutting down VPN links is one thing, decrypting them is another.

    But honestly, I've heard of ISPs in the West using deep packet inspection to weed out encrypted traffic and shape it down into the mud.

    --
    The world's burning. Moped Jesus spotted on I50. Details at 11.
  10. The Arm Race? by Revotron · · Score: 2

    All I think of when I hear that phrase is something akin to a leg race. I imagine a bunch of Chinese nationals racing each other on a track while doing handstands.

    It's kind of funny, the things one can extrapolate from a simple grammatical error.

  11. We've also run into this. by jafo · · Score: 4, Interesting

    Over about the last 2 weeks, one of our hosting clients OpenVPN connections to their machines in China have been failing. We can still SSH into the machine in China, glad they haven't blocked that. We ended up setting up a block of several hundred ports with DNAT to the normal OpenVPN port, and then set up 64 (the max allowed) servers in the client config so it can cycle between them. That's been effective so far.

    It took a while to figure out, because I was able to send test traffic via "date | nc -u server 1194", and that would go through, but the OpenVPN connection wouldn't.

    Sean

  12. The problem with information suppression by kawabago · · Score: 2, Insightful

    When an authority suppresses a minority, the minority builds resentment. If there is no outlet, the resentment grows into rebellion. If the authority suppresses the dissent it doesn't go away. It festers. Eventually all of the minorities in China will all be unhappy and ready for a full revolt. If authority tightens it's grip, the country will explode. Angry upset minorities rebelling simultaneously across all of China would be more than the authority can suppress. It will become like Syria. If China does not change course, Syria is it's future.

  13. Re:10 years from now... by Galactic+Dominator · · Score: 2

    gravity change waves

    Now that you've summited Mt Stupid, I invite you to climb back down and join the rest of us on the Plane of Reality.

    --
    brandelf -t FreeBSD /brain