Hacker News Reader

Comment by humanfromearth | Hacker News Reader

They control the physical network. As long as they have that control they will be able to do what they want. The only way to deal with these fuckers (not just Iran) is to start using collectively Ipsec or something similar. All SSL movement is just the beginning. I'm sure every big service will try to encrypt it's traffic more and more to protect itself from governments that try to criminalize their users.

Forcing countries like China, Iran and US to go into dark ages if they don't use the new all encrypted networks.

It's a shame that we are so paranoid as a species that we need to do that, but I don't see any other way.

I know this is extreme, but I don't want to see the freedom I enjoy right now taken away by these obsolete power hungry entities.

View on HN

>Forcing countries like China, Iran and US to go into dark ages if they don't use the new all encrypted networks.

The problem is some governments would be perfectly happy with that. In fact for the most repressive ones it's long term goal.

China wants to create a separate internet for Chinese users and they're half way there. They have their own local censored versions of Google, Twitter and Facebook. Soon most internet users in China won't care if the rest of the internet disappears. Likewise for Iran, except they have been more open about it [1].

[1] http://online.wsj.com/article/SB1000142405274870488940457627...

Maybe but they'll lose the productivity gains from networked organizations and communities. China can grow a long way without those gains, but they'll eventually hit a wall.

>Maybe but they'll lose the productivity gains from networked organizations and communities

Absolutely but the effect will be not be huge in my opinion because of the language differences. All my Chinese friends here in the EU still use mainly Chinese language website, most of which are based in China, especially the social networking ones.

Companies aren't going to manage inventory, customer relations or finance over open channels. So they'd reduce the gains from networking their own internal communications.

They could try to mitigate by rationing secure channels, or allowing them with backdoors, but this still sacrifices the spontaneous creativity of a truly open system.

You make a good point. It certainly would discourage or kill small businesses but, as you suggest, I'm sure larger more powerful ones will get special treatment (native ones particularly so). Considering China was willing to let Google leave the country it appears that the balance of power is shifting already.

I think that on the Internet TLS and SSL are fast approaching their sell-by dates [1].

We can do secure comms over HTTP - all it takes is a binary protocol like TLV, encrypting that, and implementing a well thought through approach to key management. Ideally something derived from the Needham-Schroeder protocol, but if we take on some lessons from PGP and the like, using timestamps instead of nonces.

The Internet is just a piece of wire - what travels across it is up to us. This goes back to the idea of building platforms rather than applications.

Maybe my ramblings here are a bit too much up in the clouds, but I think I'm going to build something that does secure comms over HTTP...

[1] Iran notwithstanding, the recent TrustWave snooping story shows that SSL is even losing its usefulness inside organisations! If you're interested, the story is here:

http://www.theregister.co.uk/2012/02/09/tustwave_disavows_mi...

Deep packet inspection allows you to block any well known protocol.

TLV (http://en.wikipedia.org/wiki/Type-length-value) isn't recognisable as a protocol. It is something you'd have to hand-roll, i.e. serialize to. The resulting byte array would be encrypted using anything you like (I'm using RSACryptoServiceProvider), so it'd be unrecognisable to DPI.

Not being familiar with specific DPI implementations I would imagine if such filtering was white list -based then anything unrecognisable would be blocked?

The obvious workaround is to uuencode your TLV data and then wrap it in <HTML><PRE></PRE></HTML>. If it's properly formatted HTML, and the body isn't recognizable as, say, a ZIP file, DPI will pass it.

Granted, someone could do entropy detection, and e.g. pass only things that look statistically like valid English/Persian/etc. text. But that needs more compute power, and can be worked around as well using statistical methods similar to Huffman coding.

It'd be awesome to hear from someone with product experience.

My experience of DPI is limited to Tenix diodes (which are white-list based, and are more focused around stripping malicious code by converting known objects to another format, eg .jpg to .png and back, or Word to PDF and back), or McAfee's Secure Web (used to be Web Washer), which does URL filtering, SSL scanning, etc. Also white list based.

The DPI in the product I work on is blacklist- and standards-based. i.e. it involves actually parsing most common formats, making sure that they are valid documents with no out-of-bounds values that could cause e.g. buffer overflows, and blacklisting known attacks.

FWIW our product can do this very quickly (we sell a 1U which can inspect 8 Gb/s).

Reply on news.ycombinator.com