You think you’ve done all the right things for your website security. Followed all the best practices. Invested in all the right solutions. You’ve got a web application firewall, DDoS protection, bot access control, the list goes on. In spite of all this, your website is suddenly slapped with a big fat Not Secure label in Chrome, right up in the address field for everyone to see.
The saying used to be that you can’t fight city hall, but that idiom needs an update for the 21st century because you know who you can’t fight today? Google. Here’s what you need to know about encrypting your website’s communications to avoid wearing the NS scarlet letters.
Updates on insecurity
January marked the release of Chrome 56, a then-new update of Google’s web browser. With this update, websites that accept or transmit sensitive information including login or payment information using standard HTTP instead of secure HTTPS are being hit with Not Secure warnings, with those words placed right beside the URL in the address field. Rightfully so, many would agree. Without the encrypted communications of HTTPS, any information transmitted between website and browser is vulnerable to man in the middle attacks. Not Secure, indeed.
While there aren’t many website users or website owners who would disagree with that step, Google is taking things even further with the Chrome 62 update. Beginning in October 2017, all websites that can have any data input will be labeled Not Secure if using HTTP instead of HTTPS. This includes websites with search fields. Further, Chrome 62 will label all HTTP sites as Not Secure when a user is in Incognito mode. With more malware and hackings and overall threats on the internet than ever before, Not Secure are not good words to have associated with your site.
Avoiding the warning
As much as it may seem a little overzealous that, say, a Beanie Babies fan page needs HTTPS because a user might type ‘Bananas the Orangutan’ into a search field, the argument is that any data input into a website by a user should not be accessible by anyone else, regardless of what that data is. Boil it down to a single sentence like that and it’s hard to argue. It’s also pointless to argue. If this is what Google wants, it’s a guideline the internet will have to abide by.
Shedding the Not Secure warning requires a website to encrypt communications between the website and browsers. To do this, a website needs to use the SSL or secure sockets layer handshake to establish connections between the website and browsers instead of the TCP or transmission control protocol handshake. This elevates HTTP to HTTPS.
In the standard TCP handshake, the browser sends a connection request to the website, the website server sends back an acknowledgment, and the browser completes the handshake with an acknowledgment of its own, establishing the connection. In order to provide a secure connection that protects exchanged data from eavesdroppers and man in the middle attacks, an SSL handshake uses the standard TCP handshake steps and adds three more steps: browser and server agreeing on the method that will be used for encryption, a verification, and the generation of the keys that will be used to encode and decode the data being transmitted.
Sounds simple
To those unfamiliar with website encryption, it’s understandable to wonder why all websites don’t just use SSL since it’s so much more secure. But as ecommerce stores and other websites that require this extra protection know, there are marked downsides to SSL.
Those extra steps added to the handshake process take time, adding three extra round trips before a browser can establish a connection with a website. This translates to slower page load speeds, which is something website users can’t stand. A survey of online shoppers found that nearly 50% expect a website to load in less than two seconds, with 40% abandoning a site altogether if it takes longer than three. Since that isn’t punishment enough, slower page load times can also contribute to lower search engine rankings.
A solution
There’s no pleading your case with website users, extolling the virtues of a secure connection and reasoning that it’s worth the decrease in website speed. There’s also no going up against Google and refusing to bend to their HTTPS preference unless you want your site wearing that Not Secure warning. However, to keep Google happy while keeping your users happy (not to mention protected) and undoing any negative impact a slower connection could have on your SEO, you simply need to speed up your SSL handshake. Which means you simply need a CDN.
A global network of proxy cache servers, a CDN or content delivery network redirects users to the server closest to them, cutting down on how far data has to travel between browser and website and slicing away at that round trip time causing the slower page load speeds thanks to the extra steps in the SSL handshake.
CDNs offer additional benefits, including load balancing, content optimization, network optimization and DDoS protection, to name a few. For many website owners, however, the biggest benefit is the faster page load time that makes SSL a no-brainer and keeps Google from slapping good sites with a bad warning. Maybe you can fight Google after all. (Just kidding. You can’t.)
