Tearing Down China's Great Firewall
quadsoft writes to tell us The Toronto Star has a look at three University Toronto computer geeks who are working hard to circumvent the internet censorship problems like those found in China. From the article: "But the computer smarts of Ron Deibert, Nart Villeneuve, and Michael Hull, combined with their passion for politics and free expression, have led them to develop a highly anticipated software program that allows Internet users inside China and other countries, such as Iran, Saudi Arabia and Burma, to get around repressive censorship and not get caught."
First, the very fact of using encryption makes you stand out in the crowd. Do that a bit too often, and someone could very well come knock on your door.
Second, SSL can be defeated. I am pretty sure that all PC in China have a Chinese Government Certification Authority listed in their SSL root file. That is enough for mounting a man-in-the-middle attack against SSL. Now you have dissidents who believe they are safe because of SSL, but in fact the firewall is reading their exchanges. Knock, knock?
The article actually points to a much better solution: just use port 80, but rewrite the page to avoid the keywords that the firewall is looking for. For example, "New York Times" could be rewritten to "New Grok Dime", or whatever. That way, the traffic remains stealthy.
I don't see the big deal. Most people around here know that you just need to get a secure connection to a proxy server in a non censoring country and then you can access the web without trouble. A guick google search will turn up lots of companies that offer web proxing for a very small charge (avoid all the 'free' proxy lists since many of then are honey pots).
Unless the gov't is specifically spying on you this is more than enough.
Peace, or Not?
That's not how public/private key cryptography works. If it did, any script kiddie could grab the private key in transmission.
The reason the private key is called so is becasuse it is never transmitted. It stays on the machine that came up with it.
Here's how it works, and we can assume both machines do the same thing for each other. One comp comes up with a private key and public key pair, where things encrypted with the public key can only be decrypted with the private key (and not with the public). Then, the machine can send the public key plaintext (or with some other form of encryption, which we can assume can be cracked much easier than the key pair cryptosystem we're using for the bulk of the data). The receiving machine uses the public key to encrypt it's data and sends the encrypted data.
Now if we assume any transmitted data can be evesdropped upon, the hacker has our public encryption key and the encrypted data... but he doesn't have the private encryption key! The data is useless to him! (Unless the key pair is weak, the data is weak, or the hacker has the hardware to brute force keys, but we'll assume the users are smart enough to avoid the first two and the cryptosystem uses a long enough key to make the last one futile.) The first computer gets the encrypted data and decrypts it with the private key.
A similar process, reversed, is used in certificates. They are encrypted with a private key, and the public key is made available. Assuming sufficient mechanisms are in place to assure that the public key does in fact belong to the original computer, any message decryptable with the public key shows that the message must have originated from the only legitimate computer with the private key.