Traditionally, websites have used HTTP (HyperText Transfer Protocol) by default and only used HTTPS (HTTP Secure, or HTTP over TLS, or HTTP over SSL) when they were processing particularly sensitive data like credit card information. I’ll look at why this was the case and why we should start using HTTPS for all website traffic.
While this post is particularly pertinent to those people and organizations that operate their own websites, e.g., Troutreach Technologies' clients and potential clients, the information should be useful to all Internet users.
HTTP vs. HTTPS, without getting too technical
HTTP is the protocol (rules) for transferring website data across the Internet. While the actual structure is complex, the important thing to note here is that all data is transferred in plain text that is easily readable. Anyone/anything capable of viewing or intercepting this traffic can read, or record, the traffic. What might that be? A compromised WiFi router at your favorite coffee shop, a shopping center, the airport, or even in your own home/office.
HTTPS expands upon the transfer mechanisms of HTTP to encrypt the data so that merely monitoring the traffic does not disclose sensitive contents. Two different forms of cryptography are employed: Public key cryptography (which implies public/private key pairs, also called asymmetric key cryptography) and symmetric key cryptography (which implies a single, shared, private key).
Symmetric key cryptography uses a single key to both encrypt and decrypt traffic. It has the advantage of being reasonably efficient but anyone knowing the key can either create or read traffic. To be secure, the key must be kept secret, and hopefully change often.
To use symmetric key cryptography, two parties agree upon a shared key and use it to encrypt anything they send and decrypt anything they receive. Third parties cannot read the traffic unless they know the shared key.
Public key cryptography uses a pair of keys, a public key and a related private key. These keys are related such that when either key is used to encrypt data the other must be used to decrypt data. It doesn’t matter which key is used for encryption, just that the other is used for decryption. Public key cryptography has the disadvantage of requiring significant computing resources for both encryption and decryption. This disadvantage precludes using it for all traffic.
In use, the public key is provided by the website to any requestor, e.g., a site visitor’s browser. The private key is never disclosed.
Here’s the sequence in a nutshell:
- The client (browser) sends a request to the server (website) to establish a secure connection. (We configure the server to tell the browser to request a secure connection if the browser doesn’t request the secure connection initially.)
- The server responds with the public key and a signed (encrypted with the private key) site certificate.
- The browser decrypts the certificate and follows a certificate path to a known Certificate Authority (CA) to verify the validity of the site’s certificate.
- If the site’s certificate is good, the sites determine a shared, asymmetric, key to use for further traffic.
Traditional Barriers to HTTPS
There are several factors that impeded implementation of HTTPS, some technical, some economic, some perceived, and some external.
Technical barriers:
- To use HTTPS a site used to be required to reside on a dedicated IP address. Many/most shared hosting vendors/accounts, used by virtually all Troutreach clients, either didn’t provide dedicated IP addresses or charged extra for them. This limitation was dictated by the early HTTPS protocol and corresponding browser limitations.
- Certificate creation and installation was complex.
Economic Barriers:
- Certificates were only available if purchased from a relatively small list of Certificate Authorities (CAs), or their agents. Costs varied widely from about $35/year and upward. While not expensive in absolute terms it was significant relative to other website costs.
- Most hosting vendors charged extra fees for a dedicated IP address.
- Some hosting vendors only provided dedicated IP addresses on their more expensive hosting plans.
Perceived Barriers:
- Website performance. Encrypting/decrypting data takes computing resources. Many felt that the increased resource consumption and resultant increases in response times were prohibitive.
- We don’t need it! Many/most sites are happy to have their messages read by the widest possible audience.
Lack of External Incentives:
- The public was, and still is, reluctant to look for sites that run with secure mechanisms.
- Outside forces, particularly major search engines, didn’t value secure sites over insecure sites in their rankings.
- Browsers (Chrome, Firefox, Internet Explorer, Safari, Edge, etc.) didn’t care.
What's Changed?
I'll discuss what's changed in an upcoming blog post.