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?"
I’m no HTML technician, however I would assume it requires significantly more processing power. Your personal blog or website with 10 hits a day sure, run it over https and you probably wouldn’t notice much difference (aside from the cost of your own unique IP address). A large scale site however would probably have more hardware and bandwidth requirements to implement https on everything.
And I don’t think it’s laziness. A lot of sites will do the login and purchasing bits over https, and have the rest of the site regular old http. It’s probably more effort to do this kind of mixed environment than just make the whole damn thing over https. The only reason for this that I can see is if there was a significant cost associated with encrypting everything un-necessarily.
Maybe because it requires certificates that cost money and annoy users when they expire?
Facebook and twitter don't have secure logins?!
That's one more reason for me to never sign up with them.
They have secure logins, just not secure sessions after you've logged in.
For the company I work for it's because Certs cost money, and self-signed certs are a pain for users.
Subject says it all. It's expensive to get a signed SSL certificate. If I'm not doing commerce through the website, and it's just a blog of some sort, I'm not going to pay extra money for a certificate when I'm not making any money off it. A self-signed cert is fine for personal use, and I use it for my webmail portal, but it doesn't exactly look professional, or even legitimate, to joe user out there.
*most* commercial websites do actually have an SSL cert for their e-commerce operations. For most, if not all, of the sites I ever use (except Slashdot), I can simply change the http to https and the site will work fine. But I don't really see the point in a website using https for anything that doesn't involve the exchange of personal or financial information. It's unnecessary overhead, and expense, for these websites. HTTPS does add extra sever load on their systems, you know. :)
1. it costs money to get an SSL from a recognised signing company
2. SSL for virtual hosts is not supported by Internet Explorer (yet another problem with IE)
....every [sub]domain needs a dedicated IP for the certs to work properly.
Dunno about Twitter, I'll never use the site. But Facebook does support full HTTPS connections, and there's an option in your profile to force Facebook to use https on every connection on your account.
Yep, the one-line answer is:
It's too CPU-intensive for the server.
Cost could be an issue but it's like $100 a year? Hardly a problem for anything but the most amateur of blogs.
"When information is power, privacy is freedom" - Jah-Wren Ryel
Implementing HTTPS isn't quite as simple as just turning something on and walking away. For larger web-based infrastructure, the best practice involves use of SSL terminators to maintain performance at scale; the encryption load of doing SSL or TLS at the actual web server itself is a Very Bad Idea when you're handling a lot of traffic. But those devices are not cheap, and there's a substantial amount of effort in both architecting them into an environment and keeping them running well; it's like any other IT infrastructure, in that it adds cost and complexity. In some cases, other aspects of the environment would have to grow as well...if the IDS and/or IPS sensors, for example, wouldn't see traffic in that section that is 'in the clear' between the web servers and the SSL accelerators, the organization would have to decide between purchasing more of these (much more expensive) security devices and giving up visibility into attacks over what is likely their highest-risk bit of attack surface. For smaller sites, the complexity is lower but cost is a more significant factor, as (for much smaller sites) the challenge and uncertainty of maintaining certificates. And for what? For most sites I can think of, I would be hard-pressed to make a business case in support of ubiquitous SSL...why should the New York Times spend so much just to make sure someone else can't see what news I'm reading? Even if they sniff my account credentials off the wire, what harm could really be done with it that would justify the expense?
Simply put, it's not free, and in most cases, the cost of security would be greater than the cost of the risk being mitigated.
For your security, this post has been encrypted with ROT-13, twice.
For instance, a large website where the primary goal is public commenting on interesting tech stories, or a public online encyclopedia - the whole point is that it's public, so encrypting it makes no sense.
And SSL encryption has a non-zero cost: it takes cycles to encrypt and decrypt on each end, and costs something to get a certificate.
I am officially gone from
Part of this was discussed long ago, 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.
You can't handle the truth.
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.
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
Blessed are the pessimists, for they have made backups.
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.
1) SSL certificates are not free
2) SSL key exchanges are horribly expensive compared with serving a web page
3) Right now EVERY web site would require a unique IP address
Enough reasons?
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
Facebook fairly recently added an option to always use https.
Twitter announced a few days ago that it was adding the same option. No idea if they've implemented it or just announced it though.
If HTTPS becomes ubiquitous, then there will be much more opportunity, as well as more incentive, to break the encryption consistently and therefore nullify the security.
On the other hand, if everything is encrypted, the traffic that truly NEEDS encryption will be less likely to call attention to itself, because the 'needle' will be in a bigger 'haystack'.
All in all I think it'll end up being a wash.
'The Economy' is a giant Ponzi scheme whose most pitiable suckers are the youngest among us and the yet-unborn.
- For HTTPS to work seamlessly it requires a certificate signed by a trusted 3rd party, which usually (but not always) costs money. This would disadvantage smaller websites/businesses.
- HTTPS also (currently) requires a separate IP address per certificate. This would mean the current practice of hosting large numbers of domains on one IP using name-based virtual hosting would not be viable, which is something the shared hosting industry really relies on. IP addresses are also a very limited resource at the moment.
- HTTPS cannot be cached between the user's browser and the server. Even the user's browser uses more conservative caching which will further reduce performance.
Maybe you should choose a provider which does not rip you off.
chat was disabled
Sigh... I considered that a feature.
And regarding virtual hosts this problem has been solved as well, see http://en.wikipedia.org/wiki/Server_Name_Indication This technology is still not universally available
A better URL is
http://en.wikipedia.org/wiki/Server_Name_Indication#No_support
Its a good solution if you want to get rid of 50% + of your users.
Although theoretically you are correct that in a decade or so it will be a usable solution.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
The correct answer is that since everybody chooses either "password", "123456" or "iloveyou" to guard their life secrets then there's no point in encrypting anything.
No sig today...
THe problem is that the browsers persist under the myth that certs can ONLY be used for proving the identity of a host; and completely disregard the fact that an equally valid and completely unrelated task is traffic encryption.
The trouble is, identity checking and encryption are inseparable.
Public key encryption doesn't allow Bob to securely exchange data with Alice: it allows Bob to securely exchange data with someone claiming to be Alice who has given Bob what she claims to be Alice's Public Key.
Without some way for Bob to verify that the person claiming to be "Alice" is, indeed, the real Alice that's about as much use as an ashtray on a motorbike.
Where self-signed certificates are useful is when you've independently verified that the site you are connecting to is genuine (translation: you have crossed your fingers and decided that your piss-ant little site is not interesting to the black hats) - but the browser can't know that you've done that. The only responsible thing the browser can do is warn you that (as far as it is concerned) the connection could still be insecure before displaying the "secure connection" symbol.
If you're using self-signed certificates then you need to be in close enough touch with your users to reassure them about the browser warnings. If you have too many users for that to be practical then you shouldn't be using self-signed certificates. Otherwise, you're acting like my bank, who cold call me and then wonder why I won't answer their security questions - they know they're genuine, but they can't get it into their heads that the customer doesn't know, and shouldn't assume, that.
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
A couple of years ago, I saw a comparison of Apache/Red Had vs. IIS/Windows that left a lot of people scratching their heads. The central test of the comparison was a comparison of a couple of hundred clients trying to read the same files from the server at the same time. Anyone that knows networking basics would know that 100 clients trying to create http sessions over tcp/ip would each require the files to be spooled to them one at a time and the maximum through put of the 10baseT network they were using would be 10Mbps / (8 data bits + 1 stop bit) = 1.111MB/s which is exactly what the Red Hat server maintained. The windows server magically transported 100MB/s over the same wires! How could this be?!? My thoughts about this have always been that IIS was not using http over tcp/ip, it was using http over udp. That meant that all 100 clients could be added to a multicast group and receive the files at the same time. This does mean that you could never attain the same throughput over https, though, because each session would be forced to be separated.
Just a quick thought..
Qybix ----- I do not have a belief system; I'm an Anti-theist and proud of it! Saying that not believing in anything i
How is it Microsoft's responsibility that people are still using a ten year old operating system?
Calling XP a 'ten year old operating system' is hyperbole. Until Vista, it was the latest OS that Microsoft was shipping, so it's been under five years since there was a replacement available, four since Vista was available to the general public (January 2007). The system requirements for Vista were so high that it wasn't shipped with a lot of entry-level machines, especially netbooks. Microsoft was still shipping XP until January 2009 - two years ago.
So, it's not so much a matter of people using a ten-year-old operating system as people using an operating system that was still being shipped on brand new machines a little over two years ago. Is it Microsoft's fault that people are still using this OS? Absolutely! People would be complaining very loudly if they weren't still actively supporting an OS that they only stopped shipping two years ago!
I am TheRaven on Soylent News
Forget about the computation on the server to encrypt everything, and about the computation on the client to decrypt everything. HTTPS requires three connections where HTTP requires only one.
In short, because you need to have a signate ring, a sculptist, and a wax candle, in order to seal the envelope. LIcking glue is faster and cheaper.
People forget what security is really about. It's about stopping people that you actually can stop from doing something that they're actually trying to do. It's not about stopping Ethan Hawk from opening your e-mail, and it's not about stopping an infant from stealing your car.
Chances are that no one is actually trying to break into your twitter account. Unless someone is, or you suspect someone is, there's nothing to secure.
By the way, it's safer to walk around with a body-guard. Have you hired one?
To protect against a man in the middle attack. The certificate ensures you are connecting to the server at the end and not some intermediate or impostor that's relaying the messages or posing as the server.
Because that would provide no assurance that you are communicating with the server at the end and not some evil computer in between you and that server. It would make the encryption completely useless if you didn't know if the encrypted connection you've negotiated is with the server you want or is with an impostor.
Because people trusted the connection between their computer and their ISP and onward not to be easily to eavesdrop or intercept. With open wireless networks, this is not the case. As an aside, I've long thought that the existence of open wireless networks was the main problem here and nobody should be using those, but that's my opinion.
...slows down browsing, and who gives a crap, for most sites it doesn't matter anyway.
If Google really cared they would fix Android Chrome to reflow text, instead of discriminating