Google Chrome is going to begin marking non-HTTPS sites as "Not secure", this is just one of many good reasons to secure a website.
After reading this article you will be able to:
What Is Web Application Security?
Google has been a fan of HTTPS for a long time, and has incrementally taken steps to nudge websites towards improving their security - this latest step is the loudest. By implementing proper security, websites are able to cut down on a variety of nefarious activities, which in turn helps Google point people to legitimate websites. This is one of the reasons Google uses HTTPS as a quality factor in how they return search results; the more secure the website, the less likely the visitor will be making a mistake by clicking on the link Google provided.
Starting in July 2018 with the release of Chrome 68, all unsecured HTTP traffic will be flagged in the URL bar as “not secure”. This means that for all websites without a valid SSL certificate this notification will appear.
For those that have been following Google’s HTTPS adoption, this update is probably unsurprising. Google planned three steps in their incremental adoption of HTTPS demarcation, and mentioned the end goal with the first rollout.
Back in 2016 Google announced that they would begin flagging regular HTTP sites that take credit card information or collect passwords. These flags, a modification to the URL bar, were set to begin in January 2017 with the release of Chrome 56. The announcement made clear that Google’s long-term goal was to eventually flag all HTTP sites.
The next step occurred in October 2017 with the release of Chrome 62. In the new version, the moment a user began entering data into an unsecure website, Chrome would again notify the user in the URL bar. With that same update, the scope of security flagging was expanded into incognito mode; since then all non-HTTPS traffic in incognito is marked as not secure.
The upcoming July update is the last step in the sequence, highlighting in no uncertain terms Google’s desire to have all websites properly secured using HTTPS. If you control any web properties that are not using encryption, now is an excellent time to make the changes. If you believe there are some drawbacks to HTTPS that surmount the need to make the change, read on.
The reason that Google rolled out the HTTPS updates over time instead of all at once is probably because many websites have been slow to adopt secure connections. To explore why this is the case we have to look at the history.
When HTTPS initially began rolling out, proper implementation was hard, slow, and expensive; it was hard to implement properly, slowed down Internet requests, and increased costs by requiring expensive certificate services. None of these impediments remain true, but a lingering fear still exists for a lot of website owners, which has impeded some taking the leap into better security. Let’s explore some of the myths about HTTPS.
A common reason websites don’t implement security is because they think it’s overkill for their purposes. After all, if you’re not dealing with sensitive data, who cares if someone is snooping? There are a few reasons that this is an overly simplistic view on web security. For example, some Internet service providers will actually inject advertising into HTTP-served websites. These ads may or may not be in line with the content of the website, and can potentially be offensive, aside from the fact that the website provider has no creative input or share of the revenue. These injected ads are no longer feasible once a site is secured.
Modern web browsers now limit functionality for sites that are not secure. Important features that improve the quality of the website now require HTTPS. Geolocation, push notifications and the service workers needed to run progressive web applications (PWAs) all require heightened security. This makes sense; data such as a user’s location is sensitive and can be used for nefarious purposes.
Performance is an important factor in both user experience and how Google returns results in search. Over time this is become even more true; in July, Google is going to start modifying search rankings of mobile websites based on mobile performance. Understandably, increasing latency is something to take seriously. Luckily, over time improvements have been made to HTTPS to reduce the performance overhead required to set up a encrypted connection.
When an HTTP connection occurs, there are a number of trips the connection needs to make between the client requesting the webpage and the server. Aside from the normal latency associated with a TCP handshake (shown in blue below), an additional TLS/SSL handshake (shown in yellow) must occur to use HTTPS.
Improvements can be implemented to reduce the total latency of creating a SSL connection, including TLS session resumption and TLS false start.
By using session resumption a server can keep a connection alive for longer by resuming the same session for additional requests. Keeping the connection alive saves time spent renegotiating the connection when the client requires an uncached origin fetch, reducing the total RTT by 50%.
Another improvement to the speed at which an encrypted channel can be created is to implement a process called TLS false start, which cuts down on the latency by sending the encrypted data before the client has finished authentication. For more information explore how TLS/SSL works on a CDN.
Last but not least, HTTPS unlocks performance enhancements using HTTP/2 that let you do cool things like server pushing and multiplexing which can greatly optimize performance for HTTP requests. In total there is a significant performance benefit for making the switch.
At one point this may have been true, but now the cost is no longer a concern; Cloudflare offers websites the ability to encrypt transit free of charge. We were the first to provide SSL at no cost, and we continue to do so. By improving Internet security at large, we are able to help make the Internet safer and faster.
There are risks associated with website migration, and done improperly a negative SEO impact is possible. Potential pitfalls include website downtime, uncrawled webpages, and penalization for content duplication when two copies of the site exist at the same time. That said, websites can be migrated safely to HTTPS by following best practices.
Two of the most important migration practices are:
1) using 301 redirects and 2) the proper placement of canonical tags. By using server 301 redirects on the HTTP site to point to the HTTPS version, a website tells Google to move to the new location for all search and indexing purposes. By placing canonical tags on the HTTPS site only, crawlers such as Googlebot will know that the new secure content should be considered canonical going forward.
If you have a large number of pages and are concerned that the recrawl will take too long, reach out to Google and tell them how much traffic you’re willing to put through your website. The network engineers will then crank up the crawl rate to help parse your site quickly and get it indexed.