SSL over AJAX
- Published November 7th, 2005 in Web/W3C, /dev/random
As everyone knows, SSL over HTTP (HTTPS) adds a large overhead and naturally things act slower comparing with non-encrypted HTTP. If you think, what is the purpose of encrypting with 128 bits an image or a block of text that is anything but private? None.
So, this morning I had the idea of selecting which content to go through the HTTPS server. On the traditional thin client web application this was not possible but with AJAX one could achieve it. Basically the idea is to just use SSL on what you really need to. For example, when establishing a login with a user, the data would be sent through a private SSL tunnel which could be handleded by AJAX. This seems very nice to me. I’ll be willing to write a white-paper on this if anyone’s interested or if there’s nothing similiar already.
The problem is that browsers will warn you that there is unencrypted content, and the regular user will not understand which content is encrypted (secured) and which is not. That will help phishing attacks (and other attacks…), since the users will already be used do see warnings and just ignore them.
It is, IMO, a very bad idea.
– mori
You got a point there that I didn’t think before.
But on the other hand you could have phishing over SSL with an anonymous certificate. Which users do really check if the certificate belongs to someone known? Actually, how many users really care if it is https or not?
Mário,
Yes, what you’re saying really makes sense to me as well, although, i should warn you… Make sure you make the solution degradable, or you’ll end up having a very sleek solution but at the same time, inaccessible. One of the key actions of a website will depend on whether the user has Javascript enabled or not. It’s easy to insert behaviour onLoad.
I haven’t seen anything written about this particular subject, but that doesn’t mean it doesn’t exist. ;) I can -almost- assure you, though, that nothing of the sort exists written in Portuguese.
Cheers.
SSL isn’t just for encryption. It’s also for integrity (no man in the middle). Even if people don’t care if the certificate is valid, the SSL is still doing something. It’s assuring that the contents are still coming from the site you connected to (even if it is a *bad* site).
The fact that few people don’t care if they are using SSL or not, or if the certificate is legit or not can’t be an excuse for implementing very poor security measures. That’s simply bad development. Otherwise banks wouldn’t use SSL, “no one cares, so let’s not care also”.
When you mix SSL and plain HTTP, you’re looking for trouble. And you will get trouble :) I’m not even sure browsers will allow that kind of mix in javascript, and I really hope they don’t.
Security wise, it’s a VERY BAD IDEA :)
– mori
I really have to disagree with mori on this one.
I think what mario’s trying to get is some sort of simple, one shot, ’ssh tunnel’ over HTTP with JavaScript (And I’m also guessing being HTTP is not important here. The important this would be the ability to tunnel stuff securely with some “built-in” gadget thats present on the client side. AJAX per instance).
And I really see the point. There is a lot of traffic to save if you only communicate some minor content (the sensitive one) encrypted.
Although, I’m not a security expert (and mori does seem to have something to say on this field) and, therefore, all my ideas are like WEP. Full of goodwill, maybe using good concepts, but not therefore secure.
How big is the overhead really?
I would think that nowadays the major causes of overhead would be solved by fast enough machines…
Most architectural weaknesses (delays) of SSL sessions are handled by pipelining, are’t they?
Do you have example code of connecting to the server using HTTPS?
Thanks
Bob