Public WiFi connections are often unsecured, leaving their connections open to being hijacked or “sniffed” by malicious people. To protect users from data and privacy loss due to insecure and untrusted connections, web sites and applications are increasingly being run entirely over secure connections (HTTPS).

My prediction is that by 2015, it will be bad practice to access web sites via HTTP, and users will increasingly demand HTTPS. This has interesting implications for hardware manufacturers and software development teams alike.

Introduction

Public WiFi connections – such as hotspots in coffee shops, trains, airports and libraries – are often unsecured out of necessity, leaving their connections open to being hijacked or “sniffed” by malicious people using freely-available tools such as SniffWifi, Kismet and NetStumbler.

To protect users from data and privacy loss due to insecure and untrusted connections, web sites and applications are increasingly being run entirely over secure connections (HTTPS – the so-called “green address bar”). Google, Facebook, Twitter and Github are examples of popular websites offering (or forcing) the use of HTTPS to users on the site.

The popular source code collaboration site Github serves all content via secure HTTPS

My prediction is that by 2015, internet users will expect a secure connection when accessing every website and by extension every type of content. Using HTTP is analogous to writing postcards: everyone can see the message as it’s sent across the communication network. Only the most trivial of messages are written on postcards; for all other correspondence, sealed envelopes are used for privacy.

Implications of Ubiquitous Secure Connections

The implications of “HTTPS Everywhere” seem to be:

1. Hardware acceleration of HTTPS encryption/decryption will provide a speed advantage
2. Use of response headers and other settings will need to be improved
3. The deployment and revocation of SSL/TLS certificates will need to be increasingly automated
4. Wildcard certificates and turn-key single sign-on systems will become more popular

Dedicated Encryption Hardware and SSL Offload

Dedicated hardware is generally faster than an equivalent software implementation (for any algorithm). Innovations such as Intel’s AES-NI (Advanced Encryption Standard New Instructions) can provide a speed advantage for client computers because the encryption/decryption needed when communicating over HTTPS can be greatly accelerated.

Likewise, at the server side, hardware with dedicated SSL/TLS-handling hardware will outperform software-based or virtualised SSL/TLS routines (such as when IIS or Apache handles HTTPS termination, or when a virtual appliance is used as a content switch).

.

Improving Use of Response Headers and Other Settings

Given that, in general, HTTPS connections are slower than those over HTTP, due to the extra time needed to encrypt/decrypt the data, any web sites which take advantage of HTTP Cache Control Headers and other HTTP response headers in an intelligent and relevant way will improve the experience for the user (although there can be some security implications for some older browsers, which can cache HTTPS content to disk (!)). In particular, text content which has Gzip compression applied on the server before being encrypted for HTTPS will often arrive at the browser more quickly than if it were not compressed.

Automated Certificate Deployment and Revocation

It will become increasing important to be able to both deploy certificates and revoke certificates using automation. Automatic provisioning of new certificates for HTTPS is relatively common already, but the importance of timely certificate revocation in the event of a break in the chain of trust will be vital for a company’s reputation (such as when a root CA has been compromised).

Wildcard Certificates

So-called “wildcard” certificates are digital certificates which can apply to more than one server address, so instead of a certificate being valid for (say) secure.domain.com, it is issued for *.domain.com (hence the name “wildcard”).

As more and more users expect all communication to be secure, wildcard certificates will be increasingly useful to website owners, because a wildcard certificate will cover all parts of the website, such as images.domain.com, login.domain.com and http://www.domain.com, all of which will need to be delivered by HTTPS to avoid “mixed content vulnerabilities“.

Even Google doesn’t always avoid “mixed content”

The feared (and confusing) “mixed content” warning in IE8

Without a wildcard certificate, a website owner would typically need to buy individual certificates for each subdomain separately, a significant cost.

Summary

I cannot see how the spread of secure (HTTPS) connections will do anything other than increase in the next few years. This has some interesting implications for those owning, building and hosting websites, as they will need to raise their game in terms of encryption/decryption speed, content caching and certificate management.