August 2018 Archives | Wiz's Computer and Website Security Blog

August 22, 2018

For two years now, Google has been warning webmasters and domain owners that non-https websites would be flagged as insecure by the mid-summer of 2018. Well, that time arrived on July 24, 2018 with the release of Google Chrome version 68. Anybody browsing the web with Google Chrome 68 or newer will be warned when they visit a non-https website that the site is "not secure" (Source). These websites are considered insecure because data to and from them is sent in plain text; not encrypted. This means that information a visitor types into forms on HTTP websites, or results displayed in the user's browser could potentially be intercepted or altered by third parties using a "Man In The Middle" program on a networked computer or device. In contrast, pages served via HTTPS are encrypted making them much harder to decypher if intercepted. This has led to a major push for "HTTPS Everywhere."

Some background information about HTTP and HTTPS

For decades, the average personal website was served by an HTTP server. HTTP stands for HyperText Transfer Protocol and is the foundation of what is known as the World Wide Web. Thus, the URL in the address bar usually began with http:// - unless it was an eCommerce website taking online payments. In those cases, security minded domain owners purchased fairly expensive (SSL) certificates and got dedicated IP addresses, allowing their URL to begin with https://. HTTPS adds encryption to all data flowing to and from a web server and web browser, making it HTTPSecure. Note that the SSL protocol has been superceded by the more robust TLS protocol.

Consequences of not upgrading to HTTPS

Since the release of Google Chrome 68 (and also Firefox 58 onward), if a person visiting a non-https website tries to login, or create an account with a username and password, or enter credit/debit card numbers, the browser will discourage or block you from filling in those form fields for your own protection. This will translate into lost inquiries, sales and account sign-ups that would otherwise be sent from those web forms. If that isn't bad enough for the owners of these http websites, Google announced that they will be demoting non-https websites in Google Search results. Preference will be given to fully https websites over the http only sites. If these demoted websites depend upon search traffic and people filling in web forms to conduct their business, this will hurt their web traffic and probably their wallets too. Rather than them, search traffic may be diverted to their competitors who are running https websites (these websites show an unmistakable green lock in the address bar). If a web page isn't secured, it's hard to miss the gray lock icon in the address bar with a red line or yellow triangle to warn visitors about the danger.

If you show affiliate ads on your pages as a referring publisher, you stand to lose if your pages don't show the green lock. Many enterprising publishers have written useful product or services articles and placed ad banners or text links on pages that may have ranked well in the past - on http websites. That was before the push for HTTPS Everywhere. Now, those pages will begin to drop in the search results pages for the same search terms that previously showed them at or near the top.

Now that I've explained the basic reasons for operating a website under the HTTPS protocol, if you have websites running on just HTTP and want to know how to secure them, read the rest of the story. In it I detail what I had to go through to get a green lock on pages containing affiliate advertising links carried over from my HTTP days.

Since the summer of 2018, one web host after another has been rolling out a free security certificate from an open source organization called "Let's Encrypt." Before you can enable HTTPS on your website, you need to get a security certificate from a Certificate Authority, like Let's Encrypt. Best of all, they do not charge for their certificate. Doing this yourself can get very technical and may involve hassles beyond your comprehension. So, the fact that so many hosting companies are installing the Let's Encrypt Certificate on behalf of their customers is simply wonderful news! Best of all, I am talking about shared hosting customers, just like me!

My web host is Bluehost and they began rolling out free Let's Encrypt certificates in late July, just before Chrome 68 was released. Prior to that, one had to pay a monthly fee that varies with the level of security and insurance provided by the issuer and the right to display any security badges they offer. Several of these plans include scheduled malware scans and help with cleanup from attacks. Further, one had to pay a monthly fee for a dedicated IP address. In fact, this is still the best route for any eCommerce website that sells goods or services directly to the public or wholesales to retailers.

Enabling your free HTTPS

But, if your website isn't directly involved in eCommerce, with a shopping cart and credit card forms, and you are hosted with a company that has installed Let's Encrypt server-wide, you can turn on HTTPS in a few simple steps! Just log into your hosting account and navigate to your control panel (e.g., cPanel, Plesk, etc). Search your control panel groups until you find an icon possibly labeled "SSL" and click on it. It should take you to a page that allows you to purchase, setup, enable and disable various SSL and TLS security certificates. If your web host has partnered with Let's Encrypt, you will see a possibly boxed section containing the heading: AutoSSL is ON or AutoSSL is OFF. Look above that box and see if there is the text: "Install SSL on" followed by an input field. If your primary domain name is already showing in that field, move down to the Install SSL section and click on the button labeled: "Enable AutoSSL." The heading should now read: "AutoSSL is ON." You have enabled a security certificate allowing your pages to be served over HTTPS.

In my Bluehost cPanel applet for SSL, there are the following important items within the AutoSSL box:

AutoSSL provides free domain-validated certificates for all your domains and subdomains.
Initial setup can take a few hours to set up all of the certificates.
In order to utilize the new certificates you may need to manually configure your sites to use https.
Premium certificates can be purchased below with or without AutoSSL.

Number 1 indicates that all of your domains and sub-domains will be covered by the same certificate. Enabling AutoSSL for your primary domain enables it for any add-on or parked domains you have hosted under the same account.

Item 2 is warning you that once you enable AutoSSL, your websites may be offline for a while, or may still be served as HTTP during the installation/changeover process. Thus, I recommend doing this late at night, or on a weekend when you get less web traffic.

Number 3 is partially what this blog article is about. It forewarns you that you may need to do manual configuration before you obtain full HTTPS and the green lock. A simple website that has no old advertising codes or external embedded images may be ready to go HTTPS within an hour or less; possibly even a few minutes.

Item 4 is letting you know that you can keep the free SSL certificate after adding paid certificates that better protect your websites. In other words, start with the free cert and if circumstances demand more protection, add a paid certificate and badge to it.

Oops, something went wrong! No green lock!

This is what the title of the article and item number 3 in the above list is referring to. Sometimes you need to manually edit links and embedded objects and scripts to get rid of HTTP codes that deny you a green secure site lock icon. The rest of the story details what I went through on Wizcrafts.net to get green secure site locks in the address/location bar on all major browsers (e.g., Chrome, Firefox, Edge and Internet "Exploder").

After enabling HTTPS on my Bluehost websites, I found that I had one minor and several major problems. The minor problem was that while HTTPS was working, so was HTTP! That's not good. Having two identical versions of your website can cause one to be favored over the other by search engines. In my case, as may also be yours, all of my pages and blog articles are already indexed under HTTP. When the search bots discover my duplicates in HTTPS, there may be a duplicate content penalty imposed, dropping all the pages down in the search results. Not good!

In order to stop my pages from being searchable as HTTP, I added a couple lines of code to my website's master .htaccess file (only applies to Apache web servers, not Windows servers). I placed the codes at the bottom of the file, using the following exact syntax:


RewriteCond %{HTTP_HOST} !http://www\.(my-other-domain1|my-other-domain2|my-other-domain3)\.com

RewriteCond %{SERVER_PORT} 80

RewriteRule ^(.*)$ https://www.my-domain.net/$1 [R=301,L]

In the rewrite conditions, I listed three pipe symbol (|) separated add-on domains attached to my one hosting account. This turns out to be an important condition. The exclamation mark means NOT in regular expressions. So, line one says: NOT (one of the listed domains). Since there is nothing else on that line, but other conditions follow on other lines, the phrase is deemed to mean AND whatever follows on the next line. The next line has a rewrite condition stating that the server port is 80. That is the standard port used to serve HTTP pages to the web, meaning that the condition is checking to see if the request is for the HTTP version of that page. The last line calculates the conditions and chooses the stated results, which is to redirect those HTTP requests to the HTTPS version of my primary website. Mine happens to be a .net. Yours may be a .com, or some other extension.

Those 3 lines of code ensure that any requests for my old HTTP web pages will silently be redirected to my new HTTPS site (exact same pages, just served with encryption) This will remove any duplicate content penalties that the search engines may or may not have imposed. It also takes you visitors and customers to a secured page that begins with https://. This is more better!

Now, about the first line of code with multiple domains separated by pipe symbols. The pipes means OR in regular expressions within parenthesis. Thus, I've listed add-on/parked domain1 OR domain2 OR domain3, all of which are .com. If you don't have any add-on or parked domains, skip this and move along to the next section. The reason I added this line of code as a RewriteCond is because I discovered that without it, all requests for pages on those domains were ending up being redirected to my primary website's home page! I Groked the solution, tested it and it works perfectly. With that line of code, only requests for my primary domain are redirected to the HTTPS server. The add-on domains are dealt with on their own and had no issues with bad redirections.

Having tackled the forced redirection of HTTP to HTTPS pages, the next fight turned out to be the lack of a green lock on many of my pages. The https was there, but they were marked as not fully secure. Bad! This is no better than leaving everything as HTTP. Using information found in the location/address bar, by clicking on the not locked icon, I soon discovered that the culprit was imported and embedded banners and tracking images for advertising networks, as well as Google Adsense links that didn't begin with https:. Fixing the Adsense links was a lot easier than tracking down both visible and invisible (1x1 pixel) ad images. It involved a lot of searching all of the pages I have published for HTTP links to affiliate ads and changing them to HTTPS. One long time advertiser still has not converted their affiliate links to HTTPS. So, I downloaded their ad banners and made them local links (e.g., /images/ads/imagexx.jpg). Doing all of this finally got me green locks on those pages.

If you have a blog with hundreds of articles, like mine, and it goes way back and has old HTTP affiliate image links, they need to be searched for and replaced with HTTPS. If those ad networks don't support HTTPS link codes, download the files, save them to your server (preferably to an images folder) and link to them locally. If they are invisible tracking gifs, this won't work. You will lose click tracking. Contact the advertiser or the affiliate network and ask when they will be converting their links to HTTPS. If they say never, drop that advertiser or network!

All told, it took me the best part of three days to find and replace all of the offending HTTP links from ads on pages I published in the mid-2000s. I may still find that I missed a page or two, but the bulk of the work is done and the green HTTPS locks are glowing. I set up a client's websites to use HTTPS and it was as simple as pie. He has no outside ad links and all embedded videos he linked to are on YouTube, which is all HTTPS.

The main tools I used to search for and replace HTTP links with HTTPS were NoteTab Pro (my preferred HTML editor for almost two decades) and my blog's built in text search and replace engine (you must be logged into the blog dashboard to edit text). If you have Notepad++ it will do the same search and replace actions. Finally, I use a licensed copy of WS_FTP to upload and download files to/from my server. Been using it for decades too! As I mentioned much earlier, my web host is Bluehost. They gave me and all their other shared hosting customers free HTTPS certificates and made it easy to enable them. However, if you are hosted by Hostgator, they too are now providing the same free SSL certificates to all hosting customers. Check out Hostgator shared web hosting packages at discounted introductory pricing. I strongly recommend both of these top rated hosting companies (I get a commission if you use my links and sign up).