While Google promotes HTTPS Everywhere, browsers have been working with a certifying authority oligopoly for many years promoting and enforcing an industry based on perception.
https: The good and the bad
The ‘s’ in https stands for ‘secure’ and indicates use of the SSL or TLS protocol.
The SSL protocol serves 2 primary purposes:
- Verification: Also called ‘trust’ – an initial ‘handshake’ procedure verifies the web server.
- Encryption: Communication between the client and server is encrypted to discourage sniffing.
With these benefits come some notable drawbacks:
- SSL requires a security certificate. Security certificates cost money. Moreover, high-encryption (bits) keys are more expensive, so webmasters opt for the lowest-level (cheapest) encryption that meets their needs.
Update: A free certifying authority is now available. - The SSL handshake process restricts web servers to one domain name per IP address, essentially eliminating the benefit of virtual hosting. Static IP addresses cost more money, and IPv4 address space is running out.
- With https enabled, it is essentially impossible to embed other sites in iframes or any other content that doesn’t use https, so this feature is eliminated as well. Similarly, browser same-origin policy prevents Javascript communication between http and https pages even of the same site.
- The process of requesting, signing, installing, configuring, and renewing SSL certificates adds some overhead to the on-going work of a webmaster.
- Security standards are constantly changing, requiring expertise, and regular updates to stay ahead of obsolescence that can cause outages.
- Given the cost of SSL certificates and IP addresses, it is that much more complex and expensive to change your mind about a domain name, support alias domains, or split a site across multiple sub-domains.
- Also, once a site starts using https, it can be impractical to change your mind about that too. The usual mechanism of informing browsers and search engines of service changes – a redirect – won’t work, so often a switch to https is permanent (STS policies can make this even worse).
- Some online tools still don’t support the https protocol, and refuse to provide service for it.
- There is a minor performance impact of adding an SSL layer, and a somewhat less minor performance impact due to its incompatibility with proxy caching servers.
- Arguably most users and web site owners are not technically savvy or security conscious enough to even notice, let alone value, security certificates.
- Using the https protocol does not even begin to make a site ‘secure’ by any means – much more work is necessary for that.
Nonetheless, SSL is a necessary cost of doing business:
- It is required for PCI compliance for example, and security in general.
- It is a must for any web site containing forms that collect secure / private information, including web sites that secure private information using authentication mechanisms.
- It is now important for SEO, so even sites that don’t need SSL now have incentive to use it unnecessarily.
- Update: In the future, some browser features will require SSL to work.
There are workarounds to some of the issues noted above. For example:
- It is possible to avoid purchasing a new IP address for each host. One way is using more expensive wild-card certificates, that might be more cost effective for a large enough number of sites. Another way is to use different port numbers, though keep in mind that some software considers URLs with port numbers “suspicious”, so there may be issues with this approach too. In the future, this problem should be solved with widespread adoption of SNI.
- Automation may be used to reduce some of the workload when there are enough secure sites involved to justify it.
- Sites can be served in both http and https versions, with https only forced when necessary.
The browser conspiracy
Early on, browsers working with a small number of certifying authorities on ‘root’ trust, established a certifying authority oligopoly. Following this, a significant political decision was made by all the major browsers to support the certifying authority industry: That non-secure sites are accepted better than partially secured sites.
So for example, if you visit a non-secure site through your browser, then the site comes up no problem.
If you visit a secure site through your browser, then the site comes up no problem, and the browser indicates somehow (using a lock icon or a coloured bar) that the site is secure.
However, if you visit a site that is partially secured or secured incorrectly, then all hell breaks loose. The browser displays a prominent and nearly impassable error message warning of the coming apocalypse.
This browser behaviour signals to users and webmasters alike that partially secured sites are much much worse than non-secure sites. This is rarely the case in practice however, as sites with some security ought to be better than sites with no security at all!
Imagine a regular user, who probably knows nothing about security or protocols, visiting a non-secure http site. The browser does not make a big fuss about the site not being secure. In fact, the experience is quite seamless. Then the user navigates to a partially secured https site: A site that say, offers data encryption but not verification, or only partial verification, or full verification with low-grade encryption. The browser then displays a big red ugly message with a pile of technical jargon on it. The user panics, thinking their computer just got infected by a virus, or that the site is down, or maybe their browser crashed. In fact, this partially secured site is more secure than the non-secure site that gave them no trouble at all.
Over time, browser messages have gotten more stern, and more difficult to bypass, while browsers continue to enforce stricter and stricter standards. As a result, a site that was once considered secure by previous security standards, but is no longer compliant based on newer standards, is treated much much worse than a site that is completely non-secure.
Update: Apparently this behaviour may change in the future.
Who benefits from this?
One consequence of this policy is that a webmaster who wants encryption but not verification, must either purchase a verification certificate anyway or give up on encryption, because encryption-only (self-signed) certificates are treated so much worse than the other options. Similarly, a webmaster concerned with verification but not encryption, still must keep up with stronger and stronger encryption standards as failing to do so results in much worse consequences than forgoing verification altogether. Even if the webmaster commits to purchasing a certificate, they will often compromise on verification and encryption relative to a self-signed certificate, due to the cost of high-end certificates.
Some webmasters might think it better not to secure a site, since most users don’t notice it anyway, rather than secure it, and deal with all the troubles involved. Certainly neither webmasters nor users benefit from this consequence.
At the end of the day, this policy primarily benefits the certifying authorities – a small oligopoly of companies that webmasters are forced to work with, who charge for and control ‘trust’ on the Internet, the value of which is based on user perception.
Is there a solution?
Security is very important – given that the Internet is open and anonymous. However, in some ways, the SSL protocol and the certifying authority trust system – a system meant to support security – is responsible for compromising it by discouraging its implementation. This is not for purely technical reasons, and certainly not for lack of incentives, but rather for process-related reasons: It is a complicated, restrictive, and expensive system to use.
This problem cannot be fixed from within the SSL framework, but requires an alternative security system altogether. Compare 2 security protocols available for another web service: FTPS (SSL-based FTP) and SFTP (SSH-based FTP). These 2 protocols arguably provide similar levels of security from a technical standpoint for most applications – providing both verification and encryption. However, from a process standpoint, SFTP is far simpler, more flexible, and cheaper (free in fact) to set up and use. The http protocol has an equivalent to FTPS (https), but does not have an equivalent to SFTP.
A new security protocol cannot address all the drawbacks of adding security as noted above – some compromise is inevitable. However, if Google and others really want to promote security, then it’s time to move on from just incentivising its use to taking the next step: Working to make it more accessible to implement.