Why is HTTP still commonly used, instead what I would believe much more secure HTTPS?
SSL/TLS has a slight overhead. When Google switched Gmail to HTTPS (from an optional feature to the default setting), they found out that CPU overhead was about +1%, and network overhead +2%; see this text for details. However, this is for Gmail, which consists of private, dynamic, non-shared data, and hosted on Google's systems, which are accessible from everywhere with very low latency. The main effects of HTTPS, as compared to HTTP, are:
Connection initiation requires some extra network roundtrips. Since such connections are "kept alive" and reused whenever possible, this extra latency is negligible when a given site is used with repeated interactions (as is typical with Gmail); systems which serve mostly static contents may find the network overhead to be non-negligible.
Proxy servers cannot cache pages served with HTTPS (since they do not even see those pages). There again, there is nothing static to cache with Gmail, but this is a very specific context. ISPs are extremely fond of caching since network bandwidth is their lifeforce.
HTTPS is HTTP within SSL/TLS. During the TLS handshake, the server shows its certificate, which must designate the intended server name -- and this occurs before the HTTP request itself is sent to the server. This prevents virtual hosting, unless a TLS extension known as Server Name Indication is used; this requires support from the client. In particular, Internet Explorer does not support Server Name Indication on Windows XP (IE 7.0 and later support it, but only on Vista and Win7). Given the current market share of desktop systems using WinXP, one cannot assume that "everybody" supports Server Name Indication. Instead, HTTPS servers must use one IP per server name; the current status of IPv6 deployment and IPv4 address shortage make this a problem.
HTTPS is "more secure" than HTTP in the following sense: the data is authenticated as coming from a named server, and the transfer is confidential with regards to whoever may eavesdrop on the line. This is a security model which does not make sense in many situations: for instance, when you look at a video from Youtube, you do not really care about whether the video really comes from youtube.com or from some hacker who (courteously) sends you the video you wish to see; and that video is public data anyway, so confidentiality is of low relevance here. Also, authentication is only done relatively to the server's certificate, which comes from a Certification Authority that the client browser knows of. Certificates are not free, since the point of certificates is that they involve physical identification of the certificate owner by the CA (I am not telling that commercial CA price their certificates fairly; but even the fairest of CA, operated by the Buddha himself, would still have to charge a fee for a certificate). Commercial CA would just love HTTPS to be "the default". Moreover, it is not clear whether the PKI model embodied by the X.509 certificates is really what is needed "by default" for the Internet at large (in particular when it comes to relationships between certificates and the DNS -- some argue that a server certificate should be issued by the registrar when the domain is created).
In many enterprise networks, HTTPS means that the data cannot be seen by eavesdroppers, and that category includes all kinds of content filters and antivirus software. Making HTTPS the default would make many system administrators very unhappy.
All of these are reasons why HTTPS is not necessarily a good idea as default protocol for the Web. However, they are not the reason why HTTPS is not, currently, the default protocol for the Web; HTTPS is not the default simply because HTTP was there first.
While there are great answers already given, I believe that one aspect is overlooked so far.
Here it is: Plain HTTP is the default protocol for the web because the majority of information on the web doesn't need security.
I don't mean to belittle the question, or the security concerns of some web sites/applications. But we can at times forget how much web traffic:
- contains only completely public information
- or has little or no value
- or where having more visitors is seen as increasing the value of the site (news media, network effect sites)
A few quick examples, I'm sure you can quickly make more in your mind:
- Almost all company websites, sometimes called "brochure-ware sites", listing public information about a company.
- Almost all of the news media, blogs, TV stations, etc that have chosen advertisement support as their primary monetization strategy.
- Services which may offer logins and additional personalization, but who also give away their content for free to anyone browsing anonymously (YouTube fx).
Http was always the default. Initially https was not needed for anything, it was pretty much an addition tacked on as it became obvious security was needed in some circumstances.
Even now, there are so many web sites which do not need https that it is still not a convincing argument to replace http entirely.
With ever more effective mechanisms for running TLS secured connections, the CPU overhead is becoming much less of an issue.
No one has pointed out a clear problem that arises from using http as default, rather than https.
Hardly anyone bothers to write the full uri when requesting a resource that needs to be encrypted and/or signed for various purposes.
Take gmail as an example, when users are visiting gmail.com, they are in fact visiting the default protocol of http, rather than https. At this point security has failed in scenarios where the adversary is intercepting the traffic. Why? Because its possible to strip html from https request, and point them to http.
If https was in fact the default protocol, your sessions to websites would have been protected.
To the question why http is chosen over https, the various answers above applies. The world is just not ready for widespread use of encryption yet.
In addition to the reasons others have given already:
Additional work required to set up HTTPS on the server
The server administrator needs to configure certificates for each domain. This involves interacting with a certificate authority to prove you are the genuine owner of the domain and obtain certificate renewals. This might mean manually generating certificate signing requests and purchasing renewals, or setting up an automated process to do so (such as certbot using Let's Encrypt). In either case, it's more work than not using HTTPS.
Additional IP addresses required
This is not really an issue since SNI (Server Name Identification) support became widespread in browsers and SSL client libraries.
Traditionally, however, it was necessary to use a different IP address for each distinct site using SSL on a particular server and port. This intefered with the ability to do name based hosting (virtual hosting) - a widely used practice allowing many different domains to be hosted from the same IP address. With HTTPS, regular name based hosting doesn't work because the server would need to know what hostname to present in the SSL/TLS validation layer before the HTTP request, containing the hostname, can be decrypted.
Server Name Identification (SNI), which effectively implements name-based hosting at the SSL/TLS layer, removes this limitation.
Slow pace of change
HTTPS was a modification to an existing protocol, HTTP, which was already very much entrenched before many people were starting to think about security. Once a technology has become established and as ubiquitous as HTTP was, it can take a very long time for the world to move to its successor, even if the reasons for changing are compelling.
Thomas has already written an excellent answer, but I thought I'd offer a couple more reasons why HTTPS is not more widely used...
Not needed. As Jesper's answer insightfully points out "the majority of information on the web doesn't need security". However, with the growing amount of tracking taking place by search engines, ad companies, country-level internet filters and other "Big Brother" programs (eg. NSA); it is raising the need for greater privacy measures.
Speed. It often feels slow because of the extra round trips and extra requests for certificate revocation lists (OCSP etc.). Thankfully SPDY (created by Google, and now supported in all major browsers), and some interesting work from CloudFlare are helping shift this.
Price of certificates. Most certificate authorities charge exhorbitant amounts of money (hundreds of dollars) for a certificate. Thankfully there are free options, but these don't get as much publicity (not sure why?).
Price of IP addresses. Until IPv6 becomes widespread, websites will face the rising scarcity (and thus cost) of IPv4 addresses. SNI is making it possible to use multiple certificates on a single IP address, but with no SNI support in Windows XP or IE 6, most sites still need a dedicated IP address to provide SSL.
Increase in server CPU usage.This is a common belief, but according to Google "SSL/TLS is not computationally expensive any more".
The real answer is that SSL certificates in their current form are comically hard to use. They are so unusable that it threatens the security of certificates, as people take shortcuts to just get stuff done. I say this as somebody who routinely deals with 2-way SSL (PKI certs), the TLS stack incompatibilities that are created by the complexity of the spec, and the crazy number of combinations of configurations (cipher limits, options, language specific library bugs, etc) that are called "TLS".
See the rise of LetsEncrypt as evidence that this is true.
Caddy is a reverse proxy project that uses LetsEncrypt. It can renew certificates while the server runs, and people use really short expirations because renewals are automated.