A few years after HTTP appeared, around when W3C was founded in 1994, it was clear that an unencrypted and unauthenticated connection was too much of a liability for a lot of serious stuff, such as e-commerce, which everyone wanted to do on the web. (In those days, mass Deep Packet Inspection was not technically feasible, so the ubiquitous snooping which we have to day was not the main driver.) There were, among the ideas, two secure versions of HTTP proposed, one known as S-HTTP and the other, as HTTP-S. To cut a long story short, HTTP-S prevailed.
There was a technical decision as to whether to make HTTPS protocol an extension of the existing HTTP protocol, used to look up URIs which started with "http:", or to give it its own URI prefix.
When you look at that design choice, you have to remember that the URL is being used to communicate between two people, for example, the person who writes the link containing the href with the link, and the person who later sees the link and clicks ion it. Lets look at some of the arguments.
| To use the existing http: | Make a new https: URI prefix |
|---|---|
| This gives the link follower the task of ensuring that the communications happen securely* | This gives the person making the link a way to ensure that the communications of the link follower |
| Allows a smooth upgrade of HTTP to be more secure HTTP | Creates a separate space, a "secure web" in which only good things happen. |
| Keeps the web one web | Gets information about security levels confused with the identity of the resource. |
* By "secure" I will normally mean in this article "with encryption and authentication".
There may have been important other reasons and arguments, so the historian is invited to check the email archives, but looking back with 20 year hindsight and experience, it seems that the overriding concern must have been that someone making the link had the ability to insist that the link follower gets a secure experience. You imagine a bank wanting to print "https://bankofexample.com/foo" and be sure everyone who read it gets to the right bank, without being spied on or diverted, and has a secure session with them. The bank using the same prefix 'http:' would not give that assurance. It turns out not that was not the most important assurance to give.
Now, an overriding concern is that the user who follows the link should be protected from being spied on, phished, scammed, or impersonated, and it is the browser's job to make that so, and, crucially, make the user the clearly aware of the level of security, and why they are trusting whom.
What has changed? Well, Some people feel that in fact looking back the decision to make the https: URI space was in fact even at that time a mistake. Now also, you can argue that things have changed in that people are individually more aware, and individually under attack. It is not now the link maker's task to ensure the user is secure. It is the user's task to ensure that their interactions are secure.
There is a currently (2014, 15) a massive move to get the web secure in the sense of encrypted and authenticated. Of encryption and authentication, the encryption part is the part which has garnered the most attention, both among its promoters and those in governments who protest against it has giving too much power to users, criminals included, compared with law enforcement. Projects such as LetsEncrypt and the EFF's HTTPS everywhere for example promote a wholesale move to the HTTPS protocol.
The concerns behind the need for security are valid. There is a lot of abuse which it would prevent. The problem with "https: everywhere"1 drive is when the "s" is put into the URI. The problem is of course that moving things from http: space into https space, whether or not you keep the rest of the URI the same, breaks any links to. Put simply, the HTTPS Everywhere campaign taken at face value completely breaks the web. In a way it is arguably a greater threat to the integrity for the web than anything else in its history. The underlying speeds of connection of increased from 300bps to 300Gbps, IPv4 has being moved to IpV6, but none of this breaks the web of links in so doing.
A proposal then is to do HTTPS everywhere in the sense of the protocol but not the URI prefix. A browser gives the secure-looking user interface message, such as displaying the server certificate holder name above the document, only when the document has been fetched in an authenticated over an encrypted channel. This can be done by upgrading the HTTP to include TLS in real time, or in future cases by just trying encrypted version first. There has been some discussion of this from including a RFC2817 (2000) "HTTP Upgrade to TLS" (Though that was motivated apparently by the need to save low-numbered ports, an issue I omitted from the table above.).
The HTTP protocol can and by default is upgraded to use TLS without having to use a different URI prefix. The https: prefix could even in fact be phased out, and instead user education focussed on understanding the level of assurance being given about the level of security, including authentication of the other party, encryption of the communication, and the anonymity, traceability, or strong authentication of the user to the other party.
This is the first of four related notes:
1 Note this we are talking about the general drive for "https:" URLs everywhere, not the specific "HTTPS EVerywhere" project of EFF which looks for examples of things which availenble in both spaces in different places, generated a map of these, and a browser extension to make the bowsere authmatically redirect from the http: to the https: version.