What You Might Miss During the ‘HTTPS’ Switch

By: Steven Snider  | 09/20/2017

Google, why are you complicating my life by notifying users that my site is not secure? 

Now that Google is updating their policy and browser behavior, how much time do you need to spend ramping up on HTTPS, SSL, TLS? The simple answer is "not much", distilling the acronyms to basic concepts takes no time at all, and, once a few changes are made, you can secure your site and no longer be deemed insecure!


A little background

When you are requesting information on a web page, whether it is a landing page or e-commerce, Google notices if you are collecting user supplied information and prefers the transfer of data to be secure. Google will proclaim your site to be insecure when this analysis is complete, and the site does not pass their security criteria by using plain HTTP.

At a basic level, a web server that delivers web pages to a client browser listens for page requests; these requests come in at a unique address and port. 


What does this mean, in english, please?

Here's an analogy. Think of a street with two houses. Let’s say a house with mailbox number 80 and the other mailbox number 443. The content that goes into mailbox number 80 is nothing but postcards; anyone could open the box and read what is written. This is called the HTTP protocol. The mailbox at 443 has a combination lock on it, and it must be unlocked to see what is inside. This is referred to as the HTTPS protocol. Just think of the additional “S” as secure.


So, what do we do?

If your website has been in production for any amount of time, you are sure to have backlinks from external sites and an overabundance of search engine links to pages on the site. The goal is to be able to make the switch to a secure user experience, and still maintain reachable site content with these external links pointed to the insecure HTTP protocol. Implementing a 301 redirect strategy will keep the SEO value from the HTTP pages and effectively pass them over to the HTTPS pages.

Now for the fun part! You must partner with your technology team or provider and be actively involved as they assist you in applying the necessary environment changes to adhere to these security requirements!  There are several factors to consider when determining how much it will cost and the time that it will take to implement these changes (e.g., do you have a CMS system or a static website, are you using embedded forms and pulling data from other resources, etc.).

Each of these scenarios has their own approach, depending on the platform’s abilities, but a key concept is that if you host a page that is using HTTPS, then all the resources that page references must also be pulled from secure sources, otherwise you will receive warnings that there is insecure content on your page. 

An example is that if you create a secure page which is to be accessed by HTTPS and are using an embedded lead capture form from Marketo and it is referenced at an HTTP address, the protocol must be changed to HTTPS.


A quick fix

It is an easy decision to secure only the pages that capture information, but this is not always the best approach. It is a general trend that all pages on your website should be secured. If you fail to do this, the user of the site will not see the lock box on all pages, and, if browsing in incognito mode, the address bar will state that the site is not secure. This partial approach relieves some of the costs involved with a full site implementation, all the externalized links will still resolve, and only those that have been switched to HTTPS will need to have HTTP redirection.


The larger (read: better) fix

When modifying a site for a complete HTTPS transformation, the issue of external links can turn into an overwhelming problem. If you are fortunate enough to use a CMS such as Kentico, the conversion to a secure site is relatively painless. Once a certificate is installed on the server, the process is as simple as modifying the server bindings to listen to both HTTP and HTTPS, changing the master page to require SSL and leave all pages inheriting from the master page’s settings. This will allow all external links to access resources on the site such as PDFs that were initially accessed via HTTP, and all pages will automatically be switched to use the secure HTTPS protocol. 

If you are using a platform that does not have these built-in capabilities, a redirector will need to be written routing requests for these resources with a 301 redirect to the HTTPS rendition of the page.


A side note

Security protocols are an evolving standard with each release becoming more secure and the older versions discontinued as they become vulnerable. TLS is the latest rebranding of SSL and is the new term, but everyone still uses the original--old habits die hard!



Share this

Blog post currently doesn't have any comments.
 Security code