Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

VPN Providers Say China Blocks Encryption Using Machine Learning Algorithms

timothy posted about a year ago | from the man-vs-state-with-a-cast-of-millions dept.

AI 111

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

cancel ×

111 comments

Sorry! There are no comments related to the filter you selected.

Havoc (5, Interesting)

Anonymous Coward | about a year ago | (#42347811)

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.

"Arm race"? (-1)

Anonymous Coward | about a year ago | (#42347909)

I see the editors are working hard today.

http://en.wikipedia.org/wiki/Arms_race [wikipedia.org]

Re:"Arm race"? (3, Funny)

SJHillman (1966756) | about a year ago | (#42348001)

It's actually a race between severed zombie limbs.

Re:Havoc (0)

Anonymous Coward | about a year ago | (#42348089)

That's probably the idea. They want you to send emails which they will glean intelligence from.

Re:Havoc (2, Interesting)

Anonymous Coward | about a year ago | (#42348163)

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

Re:Havoc (5, Interesting)

Anonymous Coward | about a year ago | (#42348339)

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.

Re:Havoc (1)

Anonymous Coward | about a year ago | (#42349281)

Sun-Tzu: "The best defense is when your enemy does not know where to attack"

Seems like you're blowing it there

It may be bad, but... (2)

MightyMartian (840721) | about a year ago | (#42348451)

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.

Re:It may be bad, but... (1)

mabhatter654 (561290) | about a year ago | (#42349267)

Whoa there.. Your implying the Chinese are buying the tech from Western Capitalists? But they LOVE FREEDOM.

Of course if said companies don't work with China, China will just keep the software, lock their sales guys in jail, and still not pay anything.

We need to get "Voice of America" to help out with Chinese censors!!!

Re:It may be bad, but... (1)

AK Marc (707885) | about a year ago | (#42350271)

Of course if said companies don't work with China, China will just keep the software, lock their sales guys in jail, and still not pay anything.

So selling things illegally is ok, so long as you suspect they might steal it if you don't sell it to them?

And yes, the west sells it to anyone, even if they wouldn't steal it. How else did Blue Coats end up doing national firewalls for oppressive middle-east regimes?

Re:It may be bad, but... (1)

mabhatter654 (561290) | about a year ago | (#42350811)

There is no law that says citizens of the USA can't sell Internet filtering software to oppressive countries. China has "most favored nation" status, so other than military goods, they actually have higher status than Canada or Mexico (because we use that status to bully their lawmakers around on IP issues).

It's not like US companies are selling systems to catalog people for the gas chamber or anything. Hell, the "illegal" chemical weapons Saddam used on rioting Kurds were SOLD to him by the US military suppliers. Saddam was tried for war crimes... His suppliers weren't.

Internet filtering OTHER COUNTRIES free speech is just fine. If it works well the govt will buy some for schools!

Re:Havoc (0)

Anonymous Coward | about a year and a half ago | (#42355103)

We have the same problem with a division of our company there. Fortunately it is just sales staff, but we still have to protect bid information.

Ca and mouse game, and I agree about the performance hit.

good luck with that (1)

Anonymous Coward | about a year ago | (#42347841)

bits will copy, packets will route.

Re:good luck with that (1)

Anonymous Coward | about a year ago | (#42347935)

"The network interprets censorship as damage and routes around it" and all that, eh?

Re:good luck with that (1)

LordLimecat (1103839) | about a year ago | (#42350087)

Im gonna go out on a limb and say that the AC GP hasnt dealt with chinese ISPs or VPN inside the GF.

Re:good luck with that (0)

Anonymous Coward | about a year ago | (#42350433)

but ports and addresses that aren't white-listed will be blocked...

This is true (5, Informative)

sadboyzz (1190877) | about a year ago | (#42347947)

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.

Re:This is true (2, Funny)

GameboyRMH (1153867) | about a year ago | (#42348055)

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

Can you find a solution to your problem then?

*Jeopardy music*

Tunneling through SSH comes to mind. (5, Interesting)

Anonymous Coward | about a year ago | (#42348117)

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

Re:Tunneling through SSH comes to mind. (3, Informative)

PlusFiveTroll (754249) | about a year ago | (#42348209)

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

Re:Tunneling through SSH comes to mind. (1)

MightyMartian (840721) | about a year ago | (#42348583)

Providing you do your key exchange in a secure manner, that shouldn't be a problem. While I usually use OpenVPN for infrastructure VPN, I've used SSH tunneling for quick and dirty connections at airports and hotels and the like.

Re:Tunneling through SSH comes to mind. (2)

postbigbang (761081) | about a year ago | (#42348677)

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.

Re:Tunneling through SSH comes to mind. (1)

mabhatter654 (561290) | about a year ago | (#42349315)

There's no PROFITS in peace, so don't fund teaching.

Re:This is true (5, Funny)

VortexCortex (1117377) | about a year ago | (#42348213)

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!

Re:This is true (1)

GameboyRMH (1153867) | about a year ago | (#42348245)

LOL! XD

Re:This is true (1)

Anonymous Coward | about a year ago | (#42348789)

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

Can you find a solution to your problem then?

*Jeopardy music*

Yiu? You've written, "There is no Problem"... No, that's incorr--- Wait, the judges say we'll accept that answer, Yiu Wins!

Wait, what's that? Oh, I'm sorry Yiu, the judges correctly point out that you failed to use the form of a question! I'm sorry, and better luck next time.

Re:This is true (1)

PerfectionLost (1004287) | about a year ago | (#42349247)

Oh man you just made my day.

Re:This is true (1)

Vexler (127353) | about a year ago | (#42350439)

You forgot to indicate how much each contestant wagered... oh wait, Yiu would just make the other two pay for him. Sorry, my bad.

Re: This is true (1)

grcumb (781340) | about a year ago | (#42353245)

Yiu wins!

Sucks to be Yiu.

Re:This is true (1)

MangoCats (2757129) | about a year ago | (#42353255)

Steganography will drive the analysis bot programmers absolutely nuts, they'll either have to shut everything down, or let some amount of stego traffic through.

Re:This is true (4, Insightful)

sadboyzz (1190877) | about a year ago | (#42349455)

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.

Re:This is true (1)

CastrTroy (595695) | about a year ago | (#42348091)

I imagine that it would be quite easy to identify what traffic is going over VPN links. The network equipment in between knows the port you are connecting to, and the IP Address. Also, encrypted data looks a lot different than unencrypted data. VPN was never designed to be hard to detect, just hard to decrypt. It's a direct end-to-end connection.

Re:This is true (2)

LordLimecat (1103839) | about a year ago | (#42350137)

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

Re:This is true (0)

AK Marc (707885) | about a year ago | (#42350487)

The ports should be encrypted. The port of VPN traffic should be ESP port or something like that. The 25/110 port inside the packet is encapsulated and encrypted. But you could do something insane like tunnel IPSEC over GRE over random ports, but the VPN packets are easy to identify, just look for packets with payload that's random. That's why stenography should work. If they know what to look for, it won't be as much help, but it's the most convenient form of non-random (but still secure) encryption. That should be sufficient to beat most automated sniffers.

SSL? (1)

dickens (31040) | about a year ago | (#42348099)

What about SSL? We're looking into expanding our use of an SaaS ERP system into China. If it requires SSL will it stop working some day?

Re:SSL? (1)

snemarch (1086057) | about a year ago | (#42350891)

Not as long as you accept MITM SSL certificates, no :-)

Re:This is true (0)

Anonymous Coward | about a year ago | (#42348483)

Seems to me there is a need for a protocol like TOR which will have encrypted data stenographically embedded into a normal HTTP media type payload. Obviously there would be increased latencies, but it would beat these adaptive filters i would think.

Re:This is true (1)

tlhIngan (30335) | about a year ago | (#42349427)

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.

Traffic analysis and classification require... traffic!

After all, one can open a TCP connection out or into China, and if you leave it idle (other than keep alive) no traffic analysis system can determine its purpose - VPN or otherwise because there's no traffic to classify.

You create a VPN tunnel and used it enough that the traffic classifier could determine it was a VPN connection. An SSH session is more idle - probably just to issue commands and maybe transfer the occasional file, so the traffic classifier couldn't really figure out what the traffic was because the samples available was much too small.

Re:This is true (1)

LordLimecat (1103839) | about a year ago | (#42350099)

Im kind of curious whether running OpenVPN over TCP 443 might avoid the block by appearing as standard HTTPS traffic. Anyone tried this?

Re:This is true (4, Informative)

sadboyzz (1190877) | about a year ago | (#42350213)

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.

Re:This is true (1)

dargaud (518470) | about a year ago | (#42351721)

Can't you encapsulate VPN within https ? Sure the server has to be aware of the scheme but it shouldn't be too hard...

Re:This is true (1)

LordLimecat (1103839) | about a year and a half ago | (#42355649)

In theory OpenVPN is SUPPOSED to be SSL, but from what Im reading something about the handshake and the way traffic is transmitted is tipping the Chinese GFC admins off. I did a little reasearch after I posted above and others report the same as he does-- that theyre really good about distinguishing VPN from non VPN traffic.

Re:This is true (1)

beefsack (1172479) | about a year and a half ago | (#42356441)

I've been living in southern China for the past year and the last month has been a nightmare. It seems if you're pumping a significant amount of traffic over an encrypted channel, they block the remote server but only for the specific port.

I have a handful of personal OpenVPN servers and made the mistake of transferring a lot of data over 22 (SSH) and port 22 for that server was blocked. As the parent post suggests, it seems to be updated every 24-48 hours, usually every 24 hours though.

I found a good technique for those running private OpenVPN servers is to use iptables to forward a large number of external ports to the internal OpenVPN port, so that means once you see the port get blocked, you just increment your client port without needing to modify the server and you can connect fine again.

This has made it significantly hard to work from China, to the point where I'm considering leaving.

Re:This is true (0)

Anonymous Coward | about a year and a half ago | (#42357779)

Yup, I've been in Shenzhen for the past 3 years, and I'm now in the process of moving to Hong Kong as i'm unable to work effectively.

Noise. (5, Insightful)

Anonymous Coward | about a year ago | (#42348021)

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.

Re:Noise. (2)

cpghost (719344) | about a year ago | (#42348247)

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.

Re:Noise. (1)

TheGratefulNet (143330) | about a year ago | (#42348805)

a funny thought: tunneling 'IP over ebay'. ha!

chinese are big sellers on ebay, now. that comms path WILL stay open, no matter what. they need to keep selling dangerous things to us. we all know that.

and so, format your data as fake replies to a fake seller in china. sure, the frag/reassem logic is going to be a bitch, but you'll get your data tunneled thru there, and even better, ebay pays the comms cost!

Re:Noise. (1)

slew (2918) | about a year ago | (#42350577)

Ebay is something like the 150th most popular site in China. It is dwarfed by TaoBao. The typical chinese user wouldn't probably notice much...

Re:Noise. (0)

Anonymous Coward | about a year ago | (#42348941)

So just encode your content through this [spammimic.com] , then tunnel the output through your VPN?

Re:Noise. (2)

snemarch (1086057) | about a year ago | (#42350919)

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

Re:Noise. (2)

nurb432 (527695) | about a year ago | (#42348499)

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.

Re:Noise. (0)

Anonymous Coward | about a year ago | (#42349619)

No, no, I wasn't really looking at pr0n all night. I was working. I just use this program that hides my VPN traffic in pictures of naked ladies to fool the Great Firewall.

Is that a DOS vector? (4, Interesting)

bigtrike (904535) | about a year ago | (#42348061)

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

Re:Is that a DOS vector? (1)

Necroman (61604) | about a year ago | (#42348167)

I would imagine they are watching the handshaking and looking for certain patterns at the start of TCP sessions. If the streams match a certain pattern (VPN connection handshake), then the connection will be added to the global blacklist at the next update. For VPNs that do their negotiation fully over UDP, the firewall probably just has to look for a specific set of packets between 2 systems over a short period of time.

Protocol/Application detection isn't all that hard with the right tools.

Re:Is that a DOS vector? (2)

bigtrike (904535) | about a year ago | (#42348553)

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.

Re:Is that a DOS vector? (1)

slew (2918) | about a year ago | (#42350281)

Seems unlikely to avoid detection using a port like 53 (DNS services, something that filter all the time). Actually it's probably pretty easy to look at most standard port traffic and infer that they are being used for non-standard purposes.

To make matters worse, even non-chinese ISPs have been known to intercept DNS requests [dnsleaktest.com] and substitute their own responses

Re:Is that a DOS vector? (1)

aaarrrgggh (9205) | about a year ago | (#42351985)

Oooh... handshake via ad network!!

Re:Is that a DOS vector? (1)

aaarrrgggh (9205) | about a year ago | (#42351979)

Is there a way to port-knock the handshake? Or perform the handshake through stenography?

Re:Is that a DOS vector? (1)

mabhatter654 (561290) | about a year ago | (#42349805)

That's why they force all the major companies to locate servers in China. I'd venture there is minimal cross-talk between Chinese sites like Yahoo and their American counterparts.

Yahoo certainly isn't internally redirecting Chinese to Yahoo.com even if they ask... Where in Europe, local country sites might all have the same "front door" server.

Targetting commercial VPN providers? (3, Interesting)

Keruo (771880) | about a year ago | (#42348189)

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.

Re:Targetting commercial VPN providers? (0)

Anonymous Coward | about a year ago | (#42349103)

No. It is both IPsec (business to business) and dial-in types.

Re:Targetting commercial VPN providers? (1)

Anonymous Coward | about a year ago | (#42349571)

Man, you wasted a perfectly good post that should have ended with "NO CARRIER" :)

Only big pipes are affected (5, Interesting)

cpghost (719344) | about a year ago | (#42348297)

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.

Re:Only big pipes are affected (2)

slew (2918) | about a year ago | (#42348591)

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.

10 years from now... (1)

slashmydots (2189826) | about a year ago | (#42348595)

Good luck blocking pairs of devices with entangled quantum particles. They travel through the fabric of reality or whatever, not copper cables. Place one inside the country and one outside and that's point to point and untraceable as far as we know.

Re:10 years from now... (1)

Galactic Dominator (944134) | about a year ago | (#42348651)

So you've found a way to violate causality and transmit information FTL? Please do share the details of how this works.

Re:10 years from now... (0)

Anonymous Coward | about a year and a half ago | (#42355405)

The speed of light is only a limit on how fast information can move "through" space. Deforming space(space can move much faster than light) or finding a way to transmit information some other way than through space, can allow information to be "faster than light".

Re:10 years from now... (1)

slashmydots (2189826) | about a year and a half ago | (#42356385)

That is absurd. I'm fairly certain that gravity change waves can travel faster than the speed of light and time dilation variance effects can travel faster than the speed of light. Like if something gigantic suddenly increased in mass, the gravity a quarter lightyear away is altered instantly, not 3 months later and that's "information" about the mass of the object.

Re:10 years from now... (2)

Galactic Dominator (944134) | about a year and a half ago | (#42356503)

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.

Re:10 years from now... (1)

slashmydots (2189826) | about a year and a half ago | (#42359659)

Hey asshole, learn physics. Black holes...gravitational sheering...ever heard of it? Changes in gravity from a non-spherical object spinning even? Gravity itself doesn't travel in waves form but alterations in gravity level aka the bending of space does alter in realtime over distance faster than the speed of light. Thus, gravity change waves or gravitational delta or whatever the hell. Either way, you're wrong.

Re:10 years from now... (1)

slashmydots (2189826) | about a year and a half ago | (#42356395)

Read any single article ever posted on slashdot about entangled particles maybe? They all end promising instant transmissions across the Earth or to other planets.

Re:10 years from now... (1)

Anonymous Coward | about a year ago | (#42348665)

LOL. From the future are we?

Re:10 years from now... (0)

Anonymous Coward | about a year ago | (#42352943)

Good luck blocking pairs of devices with entangled quantum particles.

Easy. Just cut the fiber used to send those entangled quantum particles (or how do you suppose they get those entangled quantum particles?). Or just look for and block apparent white noise transmissions on the classical channel (without the classical channel, you cannot transmit any information using quantum entanglement).

They travel through the fabric of reality or whatever, not copper cables.

Typically, they travel through optical fiber. They can also travel through air or even empty space, but that's not very practical if you don't have a sight-connection to your destination. But you're right in that to my knowledge there's no known mechanism for transmission of quantum states via copper cable.

Place one inside the country and one outside and that's point to point and untraceable as far as we know.

With one pair of entangled particles, you can securely transmit one bit. After that, you've used up that entanglement. If all you want to send is a single bit, I think there are easy to handle steganographic protocols which you can even do in your head.

Hindsight (1)

backslashdot (95548) | about a year ago | (#42348715)

The biggest mistake made in design of the web protocol was starting out with a non encrypted protocol http. In 20/20 hindsight it should have always been https and nothing else. I look for the day when browser makers disable http.

Re:Hindsight (0)

Anonymous Coward | about a year ago | (#42348967)

We didn't have the computing power for it, not by a long shot.

Re:Hindsight (0)

Anonymous Coward | about a year ago | (#42349391)

Plus encryption was highly restricted for export as an "ordnance" during the early days of the web and before.

Re:Hindsight (1)

isorox (205688) | about a year ago | (#42349775)

Plus encryption was highly restricted for export as an "ordnance" during the early days of the web and before.

I don't believe Switzerland ever had restrictions on exporting encryption.

Re:Hindsight (0)

Anonymous Coward | about a year ago | (#42349453)

That's an old myth.

Re:Hindsight (1)

AK Marc (707885) | about a year ago | (#42350583)

Encryption takes trivial computing power, and all the major sites offer encryption, and when they made the change didn't suffer noticeable performance hits.

Re:Hindsight (1)

swb (14022) | about a year ago | (#42349685)

When HTTP was first developed, wouldn't continuous encryption have been considered too expensive, computationally?

I am not a web site guru, but IIRC there was a good market for encryption offload cards at one time but I don't know how common they are anymore given the use of virtualization and the general increase in CPU power over past systems.

It was probably also a headache from a certificate perspective. You can use it with self-signed certificates, but you have to generate them, etc and traditionally this has been more difficult (perhaps "badly documented" is a better way of saying it) and browsers barf on them.

It might have made more sense if HTTP had been setup similar to the way SSH works where the encryption is handled more automagically, then everything would have been encrypted by default, and HTTPS could have been used for "trusted" SSL sessions with the usual certificate stuff.

The Arm Race? (2)

Revotron (1115029) | about a year ago | (#42348923)

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.

IPoVoIP (1)

HideyoshiJP (1392619) | about a year ago | (#42349417)

Two dialup modems on each end of a VoIP session. It could totally work. Totally.

Are they basically using entropy detection? (0)

Anonymous Coward | about a year ago | (#42349473)

That was TBDR (too boring)

So are they basically using entropy to detect probable encryption?

Ultimately a waste of time (1)

Anonymous Coward | about a year ago | (#42349621)

The Chinese are wasting there time, buying a year or two of incomplete censorship at the cost of giving everyone the means to defeat such methods afterwards, when new software methods are developed and become universally available.

Consider the problem. You wish to kill the use of encryption so you have the capability of inspecting any data block that travels across the Internet. Luckily, such censorship is fighting maths, and will always lose accordingly. Here's why.

Attempts to block encryption are actually attempts to identify the use of encryption- a mathematical impossibility UNLESS you already know all possible permutations of 'legal' data that might travel across the network. All you can do is attempt to identify SUSPICIOUS data with some statistical level of success, and obviously that success level must be very high to make the method viable and successful.

Thus, the people fighting the block simply have to use methods that make the detection system generate far too large a percentage of false positives. For those using encryption, this is simply an issue of SIGNAL-TO-NOISE ratios. That is to say, you accept the encrypted data will be, say, 5% of the data stream, wasting 95% of the bandwidth, but forcing false positive detection rates into the stratosphere.

Of course, we all suspect that China is targeting casual users of VPNs, not hardcore security agencies (who would simply use stenography to encode sensitive data in JPGs, video or audio streams). On the other hand, people who go to the trouble of using VPNs are going to find away to defeat signature detection too. This leaves us with the understanding that China is currently doing this censorship because, currently, some bunch of bods in Chinese universities or software houses are making a VERY good living by persuading the Chinese government to waste their money paying for such short-term and self-defeating services.

The article makes reference to machine-learning (which always translates to a bunch of low paid grunts in a warehouse tediously sitting in front of terminals where they get to input new data rules on the basis of the intercepted data presented to them- this is how Google works too- there is no such thing as AI in any real sense). Luckily, the internet 'learns' too through the combined actions of many thousands of individuals who wish to protect it.

A final thought. The Internet is the most perfect intelligence gathering tool ever invented. This function is degraded when governments are stupid enough to publicly attack its freedoms. Bashing the Internet brings short term political gains to governmental opportunists, but drives the security services up the wall. The desire to encrypt is driven by petty action against users, like the Bittorrent prosecutions. Those that MUST encrypt have always done so and will always do so. It is much like the situation with online ads and ad-blockers. The use of ad-blockers grows when the 'offensiveness' of online-ads grows. Thus the ad people have a massive incentive to NEVER irritate users with ads that do bad things. However, like China, they are too stupid to get this, so they make their ads more irritating and more dangerous (serving scareware), so the use of ad-blockers grows.

 

Steganography still works (1)

John Holmes (2619159) | about a year ago | (#42349749)

Just post some nice pictures on a forum and embed your message. Put your data in plain sight.

Re:Steganography still works (1)

slew (2918) | about a year ago | (#42350001)

Just post some nice pictures on a forum...

and after that forum becomed a popular route for circumvention, they block that whole website in China via IP filtering, DNS and connection blacklisting...

Certainly anything might for a while, but then there are countermeasures...

How long until the US implements this? (0)

Anonymous Coward | about a year ago | (#42350145)

This has got to be a testing phase before the US starts trying to mandate this on their networks. How long do you think it will be? Obama's still got 4 more years, after all...

We've also run into this. (4, Interesting)

jafo (11982) | about a year ago | (#42350219)

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

Disgusting (0)

Anonymous Coward | about a year ago | (#42350269)

Machine learning holds a great promise for the future of humanity. We aspire to create an artificial general intelligence and many advances in all sorts of fields (medicine, education, auto, social networking, recommendation, assisting disabled persons, etc).

It's a sad day when freedom of speech is being limited by applying highly flexible self adapting algorithms such as this one.

Borg (1)

ThatsNotPudding (1045640) | about a year ago | (#42350527)

Crap; the Borg have learned our 'rotate the frequencies' trick.

The problem with information suppression (2, Insightful)

kawabago (551139) | about a year ago | (#42350955)

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.

Re:The problem with information suppression (1)

Anonymous Coward | about a year and a half ago | (#42355247)

In the subject of rebellion: You are forgetting something. China is not Syria and they are a nuclear power. They have too many people already.
If rebellion becomes widespread, A few 50 megaton thermonuclear bombs detonated in selected problem areas would solve the problem very quickly.

We need to stop playing cat 'n mouse here (1)

Anonymous Coward | about a year ago | (#42352279)

The only effective way to fight this is just to let China go. They don't want traffic they don't like? Fine, f 'em. Drop ALL traffic into their ISPs. Companies who keep playing ball with them will only have themselves to blame when the cost of doing business is so high that it's infeasible.

Re:We need to stop playing cat 'n mouse here (0)

Anonymous Coward | about a year ago | (#42352631)

I suppose that you cannot distinguish the people from the government.

Quit using common stuff (0)

Anonymous Coward | about a year and a half ago | (#42355949)

Low hanging fruit is SSH and SSL VPN signatures. Protocol encapsulation tricks are now mandatory. Say that DNS based VPN tunnel by Dan Kaminsky (OzymanDNS) , or abusing the ability to send payload data in TCP SYN packets to emulate UDP...

My OpenVPN out of China is down. (0)

Anonymous Coward | about a year and a half ago | (#42356785)

Yes. My OpenVPN connection to my home PC in the USA has been down for several weeks. It gets the initial packet, after the OpenVPN handshake, and then after that it's 100% of packets dropped to/from the OpenVPN server port. I still have SSH access to my home PC in the USA.

I had originally tried using SSH tunneling before, with no luck because the DNS entries are poisoned as well. It wasn't until I got a tip on reddit.com/r/linux that you can set firefox to send DNS queries through the SSH tunnel (SOCKS proxy). This works well, but is about 1/5th the performance of my OpenVPN connection using udp.

Cisco is claiming here that they've got hardware for sale that can specifically target and block *all* encrypted VPN traffic, 100% of the time. Hopefully OpenVPN can update their protocol or do something that can make it harder to identify!

Challenge Accepted. (1)

zacherynuk (2782105) | about a year and a half ago | (#42357829)

Swapping steganographic images with an acoustic coupler & Kermit could be fun.

Or perhaps create a fake conversation over a normal VOIP channel, using WAV / VOC files padded with data, using, for example:

http://www.heinz-repp.onlinehome.de/Hide4PGP.htm [onlinehome.de]

Re:Challenge Accepted. (1)

zacherynuk (2782105) | about a year and a half ago | (#42357919)

Hell, actually, thinking about it; the ultimate solution is to ship my mother in law over to China. Have my wife call her for a 'quick chat' (This will ensure the line is pretty much open non-stop with perfectly generated random speech) then pass my data over the line using real-time Steganography [wordpress.com] with ZRTP

Tor/Onion? (1)

lars_boegild_thomsen (632303) | about a year and a half ago | (#42357987)

I don't live in China so I haven't had a chance to test this, but I would guess Tor/Onion is more or less the ideal way of keeping a stable connection out of China. Just run a private exit node outside China. Tor change the tunnel connections regularly to obscure it's existence.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>