Why Doesn't Every Website Use HTTPS? 665
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?"
Certificate? (Score:4, Interesting)
Maybe because it requires certificates that cost money and annoy users when they expire?
long discussion (Score:3, Interesting)
Part of this was discussed long ago [slashdot.org], with browsers treating self-signed certificates worse than they treat plain unencrypted traffic, even when passwords are passed around in plain text, nothing will change, because it is a major PITA to deal with browser issues as well as with CAs.
Here is a hint: create more incentives to use HTTPS, not fewer, and more people will use them.
This is not going to be fixed until stupid browsers stop treating a new connection to a website, that is using a self-signed certificate as some sort of a virus, while absolutely not doing the same for plain HTTP connections.
Why do certs cost $$$? (Score:2, Interesting)
This is something that has really bothered me.
I understand that a self-signed certificate is vulnerable to MitM... however, it's still better than plain-text! And we could be a little smarter about this too, couldn't we?
SSH is a perfect example. When you first connect via SSH, you confirm that you trust the certificate. Your client then remembers the certificate for future use. Why doesn't web technology do this?!?
Instead, when you self-sign a cert, browsers throw a hissy fit and shows a huge warning.
I understand that you need a certificate chain for banks and things like that... Fine. Let them pay money for that. But at least give us the option of having self-signed certs that function. No, it's not as secure as a certificate chain, but it is better than plain-text.
It's XP's fault. (Score:5, Interesting)
Today one of the major reasons is that IE on XP does not support the SSL/TLS extensions for virtual hosting.
When he says,"it's only partially implemented" he means everywhere but IE(any version) on XP.
http://en.wikipedia.org/wiki/Server_Name_Indication [wikipedia.org]
SSL issues (Score:4, Interesting)
It's more expensive in terms of processing power, you add latency due to negotiation, you lose caching across sessions, moving the user across servers is not as easy, you lose some amenities like sendfile() support, you have to manage certificates, you have to buy certificates, and in most real-world settings it's a minor security improvement anyway because the biggest security issue is the user's own worm-infested machine.
Some reasons (Score:5, Interesting)
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.
Re:Haven’t we been here before? (Score:5, Interesting)
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*...
Re:Correct (Score:5, Interesting)
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).
Re:Correct (Score:3, Interesting)
On point #4, it's been awhile since I played with webserver setup, but SSL certificates for public sites are usually tied to the server DNS name, not its IP. I'm pretty sure this means you can have more than one webserver/hostname entry, all with the same IP, and use host header names (IIS) or Name-based Virtual Host Support (Apache/others) to determine which site and certificate to connect the user to.
There's still the occasional hiccup in recognizing certificate authorities, even big ones. My cell phone carrier's and my cable provider's accounts website renewed their certs recently, about six months apart; both times Firefox and mobile Safari failed to recognize the authority (Verisign!!), i.e. it didn't think the SSL session had been hijacked or that the server was mis-configured. Both browsers were up to date at the time. The connections were still encrypted, the certificate info looked in order, but I could not TRUST that I was connected to the right server if the browsers didn't! The next updates to both fixed this, but this should not be happening in this day and age.
I've also dealt with server applications which don't permit SSL and non-SSL connections at the same time, it's all or nothing. This meant content authors and admins for that content management system-driven public website could not log in and work securely, without pointlessly forcing every public visitor into a secure session, too.
None of these are reasons not to use SSL, of course, just that there are still some technical hurdles that crop up, sometimes unexpectedly.