There’s very little most people can do to have any assurance whatsoever in the security of websites they visit. They can’t trust that the brands they know and love will build secure software (brands such as Adobe, Target and Home Depot), they can’t trust security seals on web pages (Ashley Madison still has one plus there’s the excellent Clubbing Seals paper) and they certainly can’t trust the “we take security seriously” statements… which are usually issued after a breach demonstrates that they didn’t.
But there’s one assurance we’ve had for the last couple of decades which has actually made a difference and that’s the presence of a secure connection. SSL or TLS or HTTPS – which are all discrete things but the terms tend to be used interchangeably – and the presence of a padlock in the browser have meant that at least there can be confidence that your communications remain private (confidentiality), are not modified (integrity) and are actually going to who you think they are (authenticity). Mind you, none of that means the site won’t have other serious security vulnerabilities, but as a means of independent security assurance, the padlock in the browser has become the canonical representation of “this site is secure” and the bar for having that padlock is being continually raised.
We’ve seen a lot of progress in recent years that’s forcing “secure” connections to become more secure, particularly since the Snowden era and revelations of just how much snooping goes on when communications aren’t sufficiently protected. For example, last year Chrome began taking away the green padlock if the SSL implementation used the RC4 cipher which is considered weak by today’s standards. During this year, all the major browser vendors plan to drop support for it completely. It’s a similar story for certificates signed with the SHA1 hashing algorithm which is now well and truly on the way out. Certificates using it and expiring this year cause Chrome to remove the green padlock whilst certificates expiring next year show overt red warnings. The security bar is being raised.
Another way we’re seeing transport layer encryption pushed forward is via warnings on HTTP pages, that is pages that were never intended to be encrypted in the first place. For example, the beta of Firefox 46 (we’re currently on version 44) places an overt warning on insecure pages with login forms. This is long overdue and it means that scenarios like I wrote about yesterday with the Waitrose supermarket site should become a thing of the past as consumers start seeing security warning before they even login. Going even further than that, Chromium has proposed flagging all sites loaded over HTTP as being insecure which means that as you’re reading this article (not loaded over an HTTPS connection at the time of writing), you’d see a visual warning next to the address bar. In other words, it’s a push towards “secure by default”.
Now is the time to start moving everything towards HTTPS. There are great constructs to help us do this more effectively than ever too; strict transport security and key pinning headers, DNSSEC and even free services to help make it happen courtesy of the likes of CloudFlare to name just a few. There’s never been a better time to go secure on the transport layer and eventually, you probably won’t even have a choice.
