First I’d like to start with a part of the story, which shows you where I get my idea from:
Romain Gaucher posted an interesting idea about Obfuscation and Spam Bots in his blog and said, that his basic idea of reversing the form field names in combination with a Vigenère cipher algorithm implementation in Javascript would be great. So I had a look on some resources and then I did exactly that and Romain also posted it here.
Here you can find the two POCs:
Romain’s first version:
http://rgaucher.info/beta/bots/jsReverse/
My modified version:
http://rgaucher.info/beta/bots/jsVigenere/
OK, because of this I had to think about some cryptography stuff and I also wrote to Romain in a mail, that an asynchronous encryption algorithm would be much better. So, then I was playing around with some RSA stuff to have a look on how something like this could be implemented.
That was the point when I’ve seen that we can do much more interesting stuff with cryptography then just prevent our forms against evil spam bots and here we come to the stuff which matches to the title of this blog posting.
The following graphic shows a theoretical approach on how we can have a secure data transfer over the insecure HTTP:
1.) A client performs a normal request, for example to login.php on a server.
2.) Out of random values the server no generates a public/private key-pair, for example with the RSA algorithm and send the public key then to the client.
3.) Now the client also generate such a key-pair but with JavaScript because else we have to transfer some data on an unencrypted way. The public key then will be sent to the server and because of what I describe here’s nothing more then a normal key exchange and someone can interact as a hop, catch the keys and use for both sides his own private key we should do that now on an encrypted way, which’s possible because we already get the public key of the server.
4.) The server gives back an encrypted OK message that everything works fine.
5.) Now, the client can login and his credentials will be encrypted with the servers public key on the client side through Javascript and afterwards they will be sent to the server.
That’s how we can implement something which’s not exactly HTTPs but it’s very usefull to have something like what I’ve described for example if you haven’t got the possibility to use HTTPs for any reason.
Both of us, Romain and also me are doing some research in this at the moment and I don’t know how long it will take until one of us have something to present but what I’ve heard from Romain, he has already some interesting stuff and I really looking forward to it.
In (one of) my next blog postings, I’ll show you how we can use this concept to prevent against many vulnerabilities like some XSS or SQL-Injection stuff 
12 Comments to “Secure Data Transfer over HTTP without SSL”
- 1 Pingback on Apr 5th, 2007 at 11:57 am
But what if you have an active attacker who replaces the server’s public key with their own public key, before sending it to you, and replaces your public key before it gets tot eh server, and executes a Man in the Middle attack? Nothing.
With SSL this is solved using signed certificates, and without them SSL would be completely useless. This protocol has nothing of the sort.
I don’t see you point Kuza55, the server generates the public and the private keys. If the public key is not the good one associated to the current private key (let’s say stored in the session), then you cannot decrypt the data and will not read the content.
For what I’m doing now, I try to do something more pragmatic than Sven, I should release a kind of framework which assure that the data that the client send to the server are safe for a Man-In-The-Middle attack (RSA Based too).
Hi kuza55,
of course you’re absolutely right on that an this was exactly what I meant with:
“The public key then will be sent to the server and because of what I describe here’s nothing more then a normal key exchange and someone can interact as a hop, catch the keys and use for both sides his own private key we should do that now on an encrypted way, which’s possible because we already get the public key of the server.”
So an attacker have only one point where he can attack this method and that’s when the server sends his public key to the server. It’s true that this isn’t good at all but this is the main problem we’ve got all the time when we exchange public keys. Think about PGP/GPG for mails, there we have the same problem but we circumvent it with signing the others keys but this is not practicable for the idea described here. If you kuza55 or someone else know a way around this please let the world (including me) know
That’s the thing. SSL solves this issue by having trusted 3rd parties sign certificates. We even have Cacert ( http://www.cacert.org/ ) which will sign certificates for free. Why replace something which works with something that doesn’t?
To answer this question is quiet easy from my point of view:
Because if you’re hosting for example your blog somewhere and you don’t have the money to buy an SSL certificate, then you can still login into your blog this way much more secure then you normally do and I think you agree with me, that this method isn’t perfect at all but it’s more secure than normal HTTP data transfer is.
Argh, sorry was thinking to close to what I did, even if Sven explained me this before X(
So well, with this method, I dunno if we can say that you reduce the attack area, it just raise the hacker bar upper than the low hanging fruits.
If you could verify the authenticity by sending the seed to the random generator… but well, it’s gonna be one level more again, not a real solution. So maybe thinking about removing decryption/key generation on the client side…
Well just as I already said, we’ve got the same problem here, we have in all public key exchanges. I still think, that it’s useful for example when I’m in a public WLAN and like to login into my blog without the use of SSL because if someone want to get my login credentials, he have to be prepared for it with his own keys and that’s normally not the case.
Anyway, it is just an idea and now I focused myself the next day to work on the last phrase of my blog posting because there we don’t have such problems and I think it’s really useful to get a higher protection.
By the way, thanks to both of you for the feedback
I was toying with the idea to write asymmetric crypto in JS a couple of years ago. One big problem was that RSA requires precise integer multiplication on very (!) large numbers. Back then JSs MAXINT was way to small. Did that change? Or do you plan on implementing your own Bignum-code?
Hi Martin,
I’m really not a crypto guy (even if I’m really interested in this topic) and so I can’t answer your question for sure but at least the following implementation looks very good to me:
http://www.hanewin.net/encrypt/rsa/rsa-test.htm
David Spahiro has also a quite good Big Integer’s like library in JavaScript, you can find it here:
http://www.ohdave.com/rsa
kuza55 is quite right when s/he says this architecture is vulnerable to a MITM (man in the middle) attack. However, if you’re using this as part of a pre-established user-server relationship (such as logging into your blog), you can get around the MITM. You simple need to confirm that the public keys that you sent back and forth are the right ones. You can do this by setting up a shared secret beforehand. For example, the server could, once the encrypted channel is established, but before any sensitive data is sent, send a hash of its public key and the shared secret. You type in your shared secret and the JavaScript checks the hash. Then, the JavaScript computes the hash of your public key and the shared secret and sends it to the server, who verifies it. If everything works out, you know there’s not MITM. This is about as secure as SSL (except that XSS, keyboard loggers and the like can reveal your shared secret), the only downside is you need to set up the shared secret beforehand. Really though, if you’re using a shared secret, you could just use symmetric crypto and be done with it. (Please, consult Applied Crypto or some other reference before putting time into this, the detail are very important, and I’m just going off the top of my head here. The general concept is sound, though.)