Encrypting and obscuring data between site/user without SSL

Question

Im trying to figure out what the best way to encrypt data sent between a webpage and the user(both ways) is, when hosted in an environment that doesn't support SSL. The purpose of encryption would be obscuring content for delivery through filters that aid in internet censorship. What ways would that be possible to acomplish for normal visitors without any effort on their part?

Any steering you guys could provide is greatly appreciated, Thanks!

Answer 1

There is no easy way to do this in a secure manner. Simply obscuring the content will give you no additional security. I'll give you an overview of the possible ways to realise such a system, and then I'll conclude by telling you why they don't work well enough, unfortunately.

Key-Exchange protocols and encryption

The basic idea of these protocols is to securely exchange a secret (the shared secret) and use it to encrypt communication.

First approach (flawed, as we'll see)

• Have both parties participate in a Diffie-Hellman key exchange

  • Both agree on $G$ and $P$ (see RFC 3526)
  • Both generate a random value $X$.
  • Both exchange public value $Y = G^X \mod P$
  • With each other's $Y$, they generate secret key: $K = Y^X \mod P$

• Now that both parties share a secret, use AES encryption (for instance) to encrypt the data being transmitted, using the shared secret to derive an AES encryption key.

This is easily implemented in JavaScript.

The great problem with this approach is that it's susceptible to a Man-in-the-middle attack. Unless you add some form of authentication, for instance using a pre-shared key, an attacker would simply intercept and relay the comunication: Alice ←→ Eve ←→ Bob. The Communication between Alice and Eve, and between Eve and Bob is now secure, the communication between Alice and Bob isn't.

Possible fix:

If there is a shared secret, one that is either transmitted securely through some other means or shared beforehand, you can authenticate messages using a Message authentication code.

This "solution" however isn't very good. It basically means:

In order to exchange a secret, first exchange a secret.

Which in practice means this approach will typically lead to an insecure crypto-system. This also happens to be the main problem with One-Time Pads.

You could use asymmetric keys for this, and build a Public Key Infrastructure to overcome this limitation, but then you'd basically implement almost all of SSL. It's worth mentioning again that 99% of security flaws are caused by mistakes in the implementation, rather than insecure protocols.

Second approach (totally doable, reasonably complicated)

We saw that the basic problems comes down to exchanging a secret. In order to authenticate both parties to each other (this is important, authenticating the client isn't enough!), we can use a password. This way, we can exchange a secret and know that we exchange it with the right person.

An example of a protocol designed for this purpose is the Secure Remote Password protocol (SRP). I'll not explain the protocol here, wikipedia does a far better job doing that.

Third approach, just implementing SSL

You could also basically implement SSL using your server-side language and JavaScript on the client. Now, SSL is quite complicated. The probability of a programming error leading to an insecure cryptosystem is very high.

It also requires you to have your own public key infrastructure. Meaning your clients have to get the right keys in order to communicate with your server.

In practice

This kind of thing is almost never done in practice. There are systems like Kerberos which, using a special key server, implement this kind of approach for client-server communication in closed networks, but I've never encountered anything like it on the world wide web.

• If you just want to avoid being detected by Deep packet inspection, merely obfuscating the data will be enough. But you have to obfuscate at the TCP level, which normally means re-implementing whole protocols.

• If you have to safeguard against decryption or de-obfuscation of your data after the fact, you need to use proper encryption that provides a few properties:

  • Authentication (you know exactly who you're talking to, both client and server)
  • Encryption (your communication is secret)
  • Perfect forward-secrecy (compromise of the long-term keys [like RSA keys] does not lead to a compromise of the short-lived encryption keys, i.e. does not compromise your past communications [this is the huge problem with PGP encrypted instant messaging])
  • Malleability (adversaries can easily fake the transcript of your messages after the fact, so that your scheme now provides deniability).

One protocol which provides all of these is Off-The-Record Messaging (OTR). This is a fantastic protocol, it's used for Instant Messaging however, not for web-pages.

Conclusion

I think I've taken more than enough of your time to demonstrate: there isn't an accepted or appropriate way to do it. But you can fiddle about until you find something that fits your (watered down) attack scenario. The Secure Remote Password protocol is the best way of doing this.

It will be much easier, and well worth your time and effort, to just change the rest of the system so that you can implement real SSL. That's the right way to do it.

Answer 2

Actually, NoSSL has been created exactly for this purpose. It is open source and free.

You can download it here: http://www.nossl.net