The place I work has https-everywhere as a policy. We had to fire a vendor called HubSpot in part to maintain that policy. HubSpot's service uses a subdomain of each customer's domain to provide their service, something like "info.example.com".
And they also use a content distribution network. They will deploy an https certificate across that CDN, but they charge US$600 a month for that service. Because we didn't want to pay that fee, we couldn't use https on the subdomain dedicated to HubSpot work.
I suppose web properties distributed by some global CDNs are stuck on http for that reason.
Everyone have covered most of the points . Adding a few more .
HTTPS usage is increasing with browsers enforcing websites to be on HTTPS. Like Chrome from version 55 (Not Sure) shows RED Insecure for sites on HTTP and Green Secure before the URL.
My traditional answer involved the cost of SSL certificates and the perceived difficulty of provisioning & deploying them. But LetsEncrypt has eliminated a lot of those concerns, and once they get wildcard certs that's going to make things even easier.
But even with LetsEncrypt on the table, I have clients who can't force or even reliably enable HTTPS on their sites. The issue is third-parties, specifically advertisers and SaaS platforms.
Clients fall in love with services for things like forms and polls or fancy animated charts, and sometimes the big draw is price more than anything. But not all of these services are profitable or even savvy enough to support HTTPS. So, clients end up with a choice between delaying HTTPS adoption for a little longer or taking on the expense of choosing another service and migrating years of existing third-party integrations to the new platform.
Advertisers make it worse, especially when you're dealing with remnant ads which could be pretty much anything from anyone. Not all these ads serve their creative from HTTPS-enabled servers, even if the ad service itself does. So you can end up with an HTTPS page trying to load HTTP ad creative and having mixed content issues. If the browser blocks that mixed content, it could affect page layout and other scripts running on the page that expect it to be there. All it takes is for someone's boss to pull up the company's site once and get a broken layout. Then, you can expect the order to come down to "fix the site" by disabling HTTPS.
If all humans require access to fresh water and shelter over their heads, then why don't all humans have access to fresh water and shelter over their heads?
The answer is circumstance.
Hipkiss already gave the correct answer, so I want to add another piece to always keep in mind: HTTPS is IT security. Most server breaches today are not caused by 0-day attacks, but because people fail to configure their servers properly. Setting up security is difficult. Because it is difficult and tedious and either requires expensive specialists or people to think hard and do things they don't know and don't understand, many website owners do not want to add TLS to their website. It costs a lot of money (man-hours) and they have no guarantee that what they did works properly. Why invest if the current setup works? Why add additional factors which might disrupt the system and cause down-time? No one wants that. So, people don't upgrade to TLS.
HTTPS requires an SSL cert that requires to be setup on the website. Usually these are quite expensive. But with the recent (2016 I think) release of mozilla's letsEncrypt certbot, one can install FREE SSL certs on a website.
Additionally, there can be issues when loading a webpage over http and resources over https and vice versa.
I can't remember the exact figure but I know a huge number (the majority) of websites don't actually have SSL on their websites.
Peter Scheler
JS enthusiast
Udayaditya Singh
1.The real problem, is that with HTTPS you lose the ability to cache.
2.small performance hit when using HTTPS, since "the SSL initial key exchange adds to the latency."
3.For sites that don't have any reason to encrypt anything—in other words, you never log in, so there's nothing to protect—the overhead and loss of caching that comes with HTTPS just doesn't make sense. However, for big sites like Facebook, Google Apps, or Twitter, many users might be willing to take the slight performance hit in exchange for a more secure connection. And the fact that more and more websites are adding support of HTTPS shows that users do value security over speed, so long as the speed difference is minimal.Although servers are faster and implementations of SSL more optimized, it still costs more than doing plain http
4.Perhaps the main reason most of us are not using HTTPS to serve our websites is simply that it doesn't work with virtual hosts. Virtual hosts, which are what the most common cheap Web hosting providers offer, allow the Web host to serve multiple websites from the same physical server—hundreds of websites all with the same IP address. That works just fine with regular HTTP connections, but it doesn't work at all with HTTPS.
There is a way to make virtual hosting and HTTPS work together—the TLS Extensions protocol—but it's only partially implemented. Of course that's not an issue for big sites, which often have entire server farms behind them. But until that spec—or something similar—is widely used, HTTPS isn't going to work for small, virtually hosted websites.
5.There is no real reason the whole Web couldn't use HTTPS. There are practical reasons why it isn't happening today, but eventually the practical hurdles will fall away. Broadband speeds will improve, making caching less of a concern, and improved servers will be further optimized for secure connections.