Option 1 is unacceptable -- the overhead of having all of these connections encrypted is not a viable option.
What are the 'overheads' in using SSL? How much harder does the server have to work, and - in practice - what sort of performance impact does this have?
I don't have any numbers, but...
SSL is encrypted, so the decryption has to take place on the server to make sense of the data. There's also the key negotiation that takes place at the beginnign of the SSL session. This load is pretty hard on the machine.
Lots of apps have installed SSL acceleration boards into their servers to speed things up -- the h/w is faster than the software. Other use huge servers as proxies that decrypt everything so that the app servers don't have to do the work. (The data is not encrypted near the servers, but this is generally behind a firewall, anyway).
I've seen performance numbers with SSL on and off, and the difference is suprising. I think we were using some type of Sun boxes (can't remember what type) and I think all of them had SSL accelerators in them. They were dedicateed web servers and did the SSL on behalf of the app servers. For even simple pages (actually, the time difference gets worse with simple, static content), the response times were doubled or worse.
There's another effect with HTTPS that's unfortunate, which is that most browsers will not cache anything that comes down over SSL (including images!), which means that everything on your page will get re-loaded every time you show it (even images). That sucks because you now have estra requests to the server, and they all take longer. :(
-chris
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
