Slashdot Mirror
Why Doesn't Every Website Use HTTPS?
suraj.sun writes "HTTPS is more secure, so why isn't the Web using it? You wouldn't write your username and passwords on a postcard and mail it for the world to see, so why are you doing it online? Every time you log in to Twitter, Facebook or any other service that uses a plain HTTP connection that's essentially what you're doing. There is a better way, the secure version of HTTP — HTTPS. But if HTTPS is more secure, why doesn't the entire Web use it?"
Ok... In reverse order of significance:
1. Expense (at least traditionally) of SSL Certificates. Although today that's not such a big issue, and an SSL certificate costs about the same as your domain registration. However, if you have multiple subdomains you still need a more expensive certificate.
2. Complication. It can be a highly confusing process for someone who's not an expert to do the certificate request process and the associated installation of the certificate. I know the first time I tried to do it, it went horribly wrong and I spent a day trying to sort it out.
3. Client Performance: SSL websites are slower than non-SSL websites. Not such a big deal again these days, but I remember when I had to wait it would seem forever for the images on my online banking site to load, cursing them every time for such a graphically-intensive SSL site.
4. IP addresses: This is a big one, if you host multiple websites on your server, and you only have a single IP address, you can't host more than one SSL certificate. So you need more IP addresses (which is not easy nowdays). Big deal for small company hosted websites, which are often on shared IPs.
5. Server Performance: A server that can cope with one million users per day using HTTP will not be able to cope with anywhere near that number of connections over HTTPS for obvious reasons. So you not only need a certificate, you potentially need a whole new server architecture to deal with it. Scale this up for a big business like Twitter or Facebook and you're talking implementation costs in high millions of dollars.
Please read my Canon EOS tech blog at http://www.everyothershot.com
I suspect that some are merely clueless, and some are mostly concerned with preventing persistent "lockout" type attacks at the lowest possible cost. You'll notice, for instance, that most sites that authenticate over HTTPS, then drop back to HTTP, go back to HTTPS and demand the original password if you try to do things like change the password(and possibly certain other operations considered sensitive), even if you have the session ID.
Obviously, that does nothing to prevent assorted public-wifi hilarity; but it makes it comparatively difficult(difficult enough that social engineering or just guessing that the password is 'password123' because they always are is easier) to permanently compromise the account and generate a customer support/being flagged as a spam host cost problem.
Webmasters who think that this is actually good security are fools. Webmasters who think that it blocks a certain class of especially costly attacks, while being much cheaper than full HTTPS, are entirely correct. And, given how little one pays for access to many sites that do this, they probably don't care too much unless something attracts mainstream attention *cough*firesheep*cough*...
Also, HTTPS does not play well with proxy caches or load balancing.
This is the main reason we have not been implementing it. Our environment relies heavily on caching and loadbalancing. We are trying to find ways around it though, especially to get all session-data to use HTTPS (but a requirement is that users are not scared with warnings about part of the content being unencrypted).