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.
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. :)
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
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.
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
The fact that it can muck up cheap-n-cheerful 'zillion sites on one host' arrangements unless everybody's TLS ducks are in a row probably counts as a fairly significant cost, as well. Especially on the low end.
Also, HTTPS does not play well with proxy caches or load balancing.
- 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.
True.
Even with the mighty Google I can see the lag while using the secure version. And secure Wikipedia version stops working sometimes. Hell, I'm writing this on a website without HTTPS, maybe /. web masters could answer why is it like that, too.
Hey...1998 called
Oh man! Did you warn them about the World Trade Center?
Let q be a radix > 1. I am in ur base-q, killing 10 d00ds.
But as we've seen proven, the CPU load isn't as big of an issue as is claimed.
The reports where people said it was, were from an awful long time ago, discussing high loads and CPUs that were measured in Mhz (i.e., Ghz CPUs weren't even imagined yet).
Right now, we have to look at a few issues.
1) Users are familiar with typing http:/// . If you went https only, without a redirection from http:/// you'd lose traffic. Simple fix, do a redirection.
2) Not everyone supports https still. If you include a piece from a 3rd party, you'll either get a broken lock, or the 3rd party data won't show.
3) Google Adsense doesn't support it. Still. And people have been asking for years. They are a major revenue source for a lot of sites.
4) Hosting https sites still require a unique IP for each site. If I, a a hosting provider, have 1000 sites on a server, I'd rather use one IP, than 1000 IPs.
5) SSL certs must be renewed. You must have the cooperation of the provider. Certs are no longer $100/yr, if you shop around a little. Trustico has provided perfectly functional certs for $20/yr for a long time (with discounts for multi-year purchases). I've been using them for several years. For a blog that has very cheap hosting, even the $20 doesn't necessarily make sense.
6) The time where there were huge compatibility issues with SSL implementations in browsers is gone, but you will still find the occasional app that doesn't have SSL compiled in by default, but that has become rare. At very least, all modern browsers support https:/// out of the box, regardless of where you are at.
The biggest issue is, users don't generally care. On my site, I have a warning every page if you're viewing insecure, and encouraging you to click the link to switch to the https version. Less than 10% of the users ever switch up to the https version. The only time I enforce it is when a users logs in. When they try to log in, it forces them to https, and keeps them there for the duration of their session.
Serious? Seriousness is well above my pay grade.
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).
We use Pound for load balancing which makes requests to the cache servers, works great, very configurable, supports sessions, etc.
neorush
"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."
... and you would be incorrect. Name-based Virtual Hosting cannot be done with HTTPS. The reason is that the name of what is being requested is also encrypted in the SSL data. The only way for a web server such as Apache to know what virtual host to use is to look at the name. In order to get the name it would have to SSL decrypt the request. In order to SSL decrypt the request it needs to know what SSL key to use. In order to know what key to use, it would need to look it up in the name-based virtual host record. In order to do that, it needs to know the name... oops.