GoDaddy Using Google’s Change to Label Non-HTTPS Websites as “Not Secure” in Chrome To Sell Overpriced SSL Certificates

Yesterday we discussed someone’s belief that their website would be useless in its current form due to a company’s blog post about Google making a change to their Chrome web browser to label non-HTTPS websites as “not secure”. Unrelated to that, yesterday we  got sent an email from GoDaddy touting purchasing SSL certificates from them to avoid websites being labeled that way by Chrome. Two things stood out with that. The first being that GoDaddy charges much more than you need to be paying for an SSL certificate, which will in part prevent a website from being labeled as “not secure”, but also that GoDaddy doesn’t seem to really understand what they talking about when it comes to HTTPS. That latter fact isn’t all that surprising considering GoDaddy’s poor security track record.

The subject of the email was “Your customers need SSL on their sites ASAP.”.

On the page linked to from the email, their lowest end SSL certificate, which would be the level you need to avoid the “not secure” label, the introductory price is 60 dollars if you pay for two years upfront and then after that 75 dollars:

With other providers you can pay a fraction of that price. It also looks like that used to be true with GoDaddy as well, as they have apparently significantly increased the prices they charge for SSL certificates over the years despite nothing that would have increased their costs.

Using Let’s Encrypt you can even get a free SSL certificate and there are plenty of web hosting providers that have the capability integrated into their control panels to allow setting those up. It’s worth nothing that GoDaddy’s security company has been a major sponsor or donor to Let’s Encrypt, which seems like a tacit endorsement of Let’s Encrypt .

That GoDaddy is overcharging for SSL certificates instead of being like other hosting providers and offering free SSL certificates seems worse to us when reading one of the three testimonials they chose to show on that page that touts them providing an affordable solution:

I received a call from product support to let me know Google was getting more rigid about “secure sites”. We were able to make the upgrades that I could afford, and make my site more mobile accessible AND secure.

Another testimonial seems more insidious since it gives the impression that GoDaddy is providing cheaper certificates than others instead of more expensive ones:

I’ve set up SSL certificates from various companies but will never use anyone but GoDaddy every again. It’s easy to set up, great support and at a fraction of the price it’s great all around!

That is a great example of why testimonials are not a great source of information because that one allows GoDaddy to make it seem like they providing a more reasonable priced product without having to lie. If they really were providing cheaper certificates they would have been able to present evidence to back that up.

Misleading Marketing

The email made the following claim:

SSL is not only the right thing to do for your customers, it’s also great for boosting their search rankings and getting more traffic to their sites.

No link was provided that backed up that claim. On the page to purchase an SSL certificate, the claim is made repeatedly in regards to Google search results, but again no evidence is provided.

Based on what Google has said it doesn’t sound like using HTTPS has much impact. Here is in part what Google said when the disclosed that usage was a ranking factor:

We’ve seen positive results, so we’re starting to use HTTPS as a ranking signal. For now it’s only a very lightweight signal—affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content—while we give webmasters time to switch to HTTPS. But over time, we may decide to strengthen it, because we’d like to encourage all website owners to switch from HTTP to HTTPS to keep everyone safe on the web.

As far as we are aware they haven’t announced strengthening it and they seem to be using changes to Chrome to increase usage of HTTPS.

In another instance, a Google employee explained the impact as follows:

If you’re in a competitive niche, then it can give you an edge from Google’s point of view. With the HTTPS ranking boost, it acts more like a tiebreaker. For example, if all quality signals are equal for two results, then the one that is on HTTPS would get … or may get … the extra boost that is needed to trump the other result.

Importantly, if both websites were using HTTPS the impact on the ranking boost of either one would be nullified.

Misleading on that seems of less importance than a page they created just to promote buying their SSL certificates due to the change to Chrome.

There they claim that “A Not Secure label on your website can devastate your business.”:

No evidence is presented for that despite it being a serious claim.

What seems like a clear indication that they are not interested in informing people about what is happening, but selling something is another part of that page which states that using HTTPS will “shows visitors they’re safe with the little green lock in their address bar”:

The next HTTPS related change in Chrome, occurring in September, involves it downgrading what is shown for HTTPS pages:

Do They Know What an SSL Certificate Even Is?

Going back to the page for selling SSL certificates there is what is supposed to be an explanation of how a HTTPS connection works, but it seems to have been written by someone that isn’t familiar with it all:

An SSL certificate doesn’t “automatically creates a secure, encrypted connection with their browser”, instead the SSL certificate is just used to validate that a secure connection is being made with the intended website instead or with another party.

Among the other issues with that is that the level encryption is determined by the server and the web browser, not the SSL certificate.

GoDaddy might be able to justify a higher price for an SSL certificate if good customer service was provided, but considering how off the marketing material is, it is hard to believe that their customer service would be well informed about them.

Atlantic BT’s Scare Tactics Lead to Belief That Google Is Rendering Non-HTTPS Websites Useless by Labeling Them “Not Secure”

One of the problems we have found in dealing with security over the years is that you have a lot of people managing websites that believe they have a much better understanding of things than they do. Security companies make this situation worse by spreading misleading and outright false information to market their products and services.

One area where we frequently see issues, not just when it comes to security, but more generally as well, is people managing websites believing that upgrading software on a website will resolve some issue they are having. What seems like it should give them some pause, but apparently doesn’t, is that they don’t themselves even have the capability to handle the upgrade, but believe they know what the impact of that would be.

What we have found repeatedly in that situation is that they will contact someone like us about having an upgrade done and not mention that their reason for getting the upgrade is the assumption that it will resolve that issue. In some cases they only bring it up after the upgrade has been fully completed and the issue still exists.

Due to the increasing frequency we run into this type of situation we recently changed how we do things, so now in the contact form for upgrade services we specifically ask why there is interest in having an upgrade done.

A recent example of that showed why that is important and brought across misleading claims from a company named Atlantic BT about the changing handling of non-HTTPs website in Google’s Chrome web browser.

The reason given that this person was interested in having a fairly significant upgrade done was that their website was going to be “useless” in a few weeks due to a new Google security regulation. We really didn’t know what they were talking about and for good reason, it turned out the reality was very different.

What is happening is that in July with the release of Chrome 68, Google will start labeling non-HTTPs web pages as “not secure”. Here are the before and after according to Google:

That wouldn’t make a website useless, though it might make an eCommerce website, like the one we were contacted about, less appealing.

What was more important was that upgrading the software on the website wouldn’t have an impact on that since HTTPS is handled by the server, not the software running on the website. As long the software on the website allows you to configure things so that addresses on the website start “https” instead of “http” there is no need for an upgrade to implement HTTPS.

So where did the idea that the website would be useless come from? It turned that was due to a blog post on Atlantic BT’s website. The intent of the post seems to be scare people in to contacting this company for security services.

The name of the post as listed in the URL for it, https://www.atlanticbt.com/blog/google-chrome-warn-users-non-secure-websites/, seems neutral. The visible title isn’t, “Non-Secure Websites, Beware! Google is After You”.

In the first paragraph they state:

This could create many challenges for web owners and designers. Traffic and revenue losses, as well as drops in organic search rankings, could all be consequences.

In second paragraph they make a claim that there is a requirement to use HTTPS, despite there not being one:

By July, Google will require ALL websites to have their entire domain set up as HTTPS.

In third paragraph they again try to push the negative impact, without quantifying how much, if any, they are claiming there would be:

This means that Google’s policy update will have major implications on your site’s web performance.

In the fourth paragraph they can’t even get to a benefit of HTTPS without playing up fear first:

Before stressing over the potential impact of this update, it’s important to recognize the countless benefits of establishing a secure connection via TLS.

The final section of the post, titled “What are the implications of Google’s update?”, starts with more unquantified claims:

Google is increasingly using security as an algorithmic ranking factor within their Search Engine Results Page (SERP). In 2014, Google publicly announced that websites would receive a boost in rankings if they switch from HTTP to HTTPS. And in-line with that policy, sites that remained HTTP would be at risk of losing rankings. This is a serious threat to the acquisition of organic traffic on HTTP websites.

So people should be doing something now because there was change four years ago, which Atlantic BT can’t actually cite say percentage impact of (as far as we are aware there wasn’t much impact on rankings due to that change).

Next, they finally mentioned a quantified stat:

There is also an added risk of dropping conversion rates and losing customers. Studies show that  85% of web users would choose not to make purchases from a website if it was labeled as “non-secure”.

If you follow the link though it doesn’t make the specific claim they claim it does and there are a number of other issues. What is claimed on the link page is that a survey found that:

In fact, 85% of web users state they wouldn’t buy through a website where they weren’t certain their data was being transferred securely.

Among the issues that we can think of off the top of our heads:

  • That isn’t a study.
  • The question posed is different.
  • People stating they would do something does not necessarily reflect what they really would do.
  • The survey was done by a company that sells SSL certificates, which makes the result somewhat suspect. Fuller details that could be used to better access the veracity of the survey, like what was the wording of the question, were not provided.

No other quantified statistics were provided in the post.

The final paragraph of the post seems to be what all the rest was leading to:

If you’re concerned about the potential impact of this upcoming Chrome update, or the security of your site, contact the experts at Atlantic BT.

Based on what we saw in that post it would seem like you would be best steering clear of that company.

Sitelinks in Google’s Search Results Missing “This site may be hacked.” Warnings

Last week we discussed a US government contractor that offers several security services, including “Cyber Security” a service, while having hacked website, which we had run across after they were in the news for their involvement with questionable practices at US Housing and Urban Development (HUD) department. That incongruity between offering security services and not being able to secure their own website, makes it seem not all that surprising to us that in follow up reporting on the situation with the HUD department it was reported that the company was possibly engaged in fraudulent billing as well.

There is another thing we noticed in relation to the hack, though, which is that Google is currently incompletely warning that they are aware that websites are hacked.

In our previous post we mentioned that, for example, when you visited the website’s Careers page you would be redirected to a casino website. When showing up in Google’s search results that page is flagged with the message “This site may be hacked.”:

But when that same page is shown as a sitelink there is no warning:

Being a sitelink versus as standalone result should have no impact on whether this type of issue is occurring (and that is the case with this website), so Google should warn there as well.

Google Search Console Claiming That Fixed Security Issues Are Still Being Detected Days Later

Google’s flagging that websites are hacked (“This site may be hacked.”) is a good thing and from what we have seen their claims are highly accurate. A reoccurring problem we found in cleaning up hacked websites, though, is that after the websites have been cleaned is that Google will claim in the Security Issues section of their Search Console that the issue has been detected days after it has been resolved.

As an example of that we had someone whose websites we cleaned up on March 1, but as of March 4th, Google was claiming that the issue was detected the day before:

Using the Fetch as Google tool in the Search Console showed that the URL they claimed the issue had been detected on didn’t exist (since the code that generated it was no longer on the website):

No change had been made to the website on either of those days, so the result would have been the same the day before.

By later on March 4 that claim had disappeared despite a continued lack of change of anything on the website:

Since we deal with hacked websites all the time we are aware of this issue, but for clients or others who might be trying to deal with a situation on their own it is easy to think that this could cause unnecessary distress and wasted time spent trying to deal with an issue that has already been dealt with.

Hopefully Google will work on correcting this.

Google is Again Hosting and Handling Advertising for Website that is Publishing Purported Leaked Credit Card Info

Last week we noted that Google was hosting and handling advertising for the website leakeddata.me, which publishes purported leaked credit card info as well as other types of confidential data. Then on Monday we noted how we had run across another related website, leakeddata.net, but that leakeddata.me appeared to have been taken down by then. Here is what you got when you visited leakeddata.me at that time:

By contrast here is what you get now:

So the website is again being served from Google’s Blogger service with advertising being handled through Google’s AdSense service. The newest entries are of purported username/passwords for several different web services (as shown in the screenshot) and below that are ones for credit card info.

Another Website That Google is Hosting and Handling Advertising for is Publishing Purported Leaked Credit Card Info

Last week we discussed how we found that a website that Google was serving ads for our website was publishing purported leaked credit card info and that the website was also hosted through Google’s blogger service. That seemed to spur action from Google as here is what you get when you visit the address of the website, leakeddata.me, now:

Also since then, our ads were being served on a nearly identical website, leakeddata.net, that looks to be run by the same people as the first website.

The title of the website is “Leaked Data | Exploited and Leaked Information | (UPDATED Daily)” and the subtitle is “Hack Credit Card | Visa | MasterCard | SSN | Amazon | Email Address | MYSQL Database | IP Address | ( HACKED | LEAKED | EXPLOITED )”.

Here is how the homepage of the website currently looks, with portion of the page with ads served by Google bordered in blue:

Like the first website, this website is hosted through Google’s Blogger service.

It looks like this website has been showing purported leaked credit card info since November of 2014.

Google is Hosting and Handling Advertising for Website that is Publishing Purported Leaked Credit Card Info

A month ago we noted that Google’s AdSense program was handling the advertising for a number of websites serving “nulled” web software, which is paid web software being distributed illegal, with at least one of those serving up malicious code with the “nulled” web software. We reported a number of the websites to Google as they are violating policies of the AdSense program, but they are still running ads served by Google.

Part of how we became aware of that was that advertising we were running through Google’s AdWords program was being shown on some of those websites. Today we noticed that our advertising has recently been running on an even more troubling website, leakeddata.me.

The title of the website is “Leaked Data | Exploited and Leaked Information | (UPDATED Daily)” and the subtitle is “| Hack Credit Card | Visa | MasterCard | SSN | Amazon | Email Address | MYSQL Database | IP Address | ( HACKED | LEAKED | EXPLOITED )”. The homepage of the website currently shows the details of seven purported leaked credit cards, with the data shown including the credit card number, CVV number, name of credit card holder, and their address.

The top of the homepage of the website has multiple blocks of Google served advertising (bordered in blue):

When we went to see where the website was being hosted we were surprised to find it was Google. The IP address the website is hosted from is 216.239.36.21, for which the host name is any-in-2415.1e100.net. As Google explains “1e100.net is a Google-owned domain name used to identify the servers in our network.”. At that point we noticed that the website is being hosted through Google’s Blogger service.

It would seem that neither the Blogger nor AdSense service do any sort of proactive monitoring looking for credit card info being show on pages using the services, which seems to be something they could be doing.

It looks like the website has been showing leaked info since December of 2014.

We wanted to report this to the Blogger service, but they don’t have an option if you want to report someone else’s private information is being posted, only your own.

Google Sending Out False Alerts That Websites Are Running Outdated WordPress Versions

Back in 2009 Google started notifying webmasters through their Webmasters Tools (later renamed Google Search Console) that they were running outdated software in some instances. That is good idea, but it clearly needs some work as of 2017, seeing as last night we got the following email:

Recommended WordPress update available for http://www.whitefirdesign.com/

To: Webmaster of http://www.whitefirdesign.com/,

Google has detected that your site is currently running WordPress 4.7.0 or 4.7.1, an older version of WordPress. Outdated or unpatched software can be vulnerable to hacking and malware exploits that harm potential visitors to your site. Therefore, we suggest you update the software on your site as soon as possible.

Following are one or more example URLs where we found pages that have outdated software. The list is not exhaustive.

https://www.whitefirdesign.com/blog/2011/03/02/hiding-the-wordpress-version-number-will-not-make-your-website-more-secure/

https://www.whitefirdesign.com/blog/category/outdated-server-software/

https://www.whitefirdesign.com/blog/category/sucuri-security/

Recommended Actions:

1 Update to the latest release of WordPress

Visit the WordPress site for instructions on how to download and install the latest release.

2 Check your site for hacked content

Because there was a vulnerability on your site, it’s possible that your site might have been compromised. We recommend you check your site for any suspicious activity. You can see if Google has detected any hacked content on your site in the Security Issues section of Search Console.

3 Stay up to date on new releases

Remember that older or unpatched software might be vulnerable to hacking or malware, so it’s important to install new software releases when they come out.

Need more help?

Read more about outdated software and vulnerabilities in our Help Center.
Check your site for hacked content using the Hacked Sites Troubleshooter.
If your site was compromised, read our guide for hacked sites.
Ask questions in our forum for more help – mention message type [WNC-641200].

Because this blog, like hopefully almost all WordPress installations, hasn’t had the automatic background updates feature disabled, it already was updated. In fact the update to 4.7.2 happened as of midday on January 26, the day the update was released. That was 11 days before the email was sent out. Seeing as we haven’t removed the meta generator tag from the blog, the version is included on every page’s source like this:

<meta name="generator" content="WordPress 4.7.2" />

Our guess would be that they are still processing pages crawled from before the update happened, which include the previous version number, and they are basing the claim of outdated software on that, which is obviously problematic.

It also worth noting that they are failing to capitalize the “p” in WordPress, instead referring to it as “WordPress”.

Google Moving in The Wrong Direction When It Comes to Information Provided on Hacked Websites

We clean up a lot of hacked websites, which means we often are dealing with website that flagged as serving malware by Google. In Google’s Search Console you can get whatever details they are providing on the issue they detected and request a review to have their warning removed after the website has been cleaned up. We often find that all they provide with is sample URLs where they have found the issue, but no details of the issue due to them being unable to isolate the malicious code being served. For us that usually isn’t a problem, but for those less experienced providing more information on what they are detecting in more cases would likely to improve cleanups. But now it seems things are going further in the wrong direction, as this week we dealt with a website where Google provided no details whatsoever on Security Issues page of the Search Console:

google-search-console-security-issues-no-sample-urls

They also left a message where they did list a URL, so it seems the various pieces of their system are not working well together:

google-search-console-malware-detected-message

Hopefully Google will improve this, as in this case (and probably in plenty of others), the website only got properly cleaned up after Google started flagging it, so what they are doing is important, but could be better.

Google Needs to Improve the Review Process for Websites Labeled “This site may be hacked”

Early last year Google changed some of the underlying technology used in their process of of handling websites they suspect of being hacked (which leads to a “This site may be hacked” message being added to listings for the websites on Google’s search results). More than a year later we are still finding that the review process for getting the”This site may be hacked” message removed after cleaning up such a website is in poor shape and likely lead leading to a lot of confusion for people trying to navigate it if they don’t deal with it’s problems on regular basis (like we do). While we think that what Google is doing by warning about these situations is a good thing, the current state of the review process is not acceptable.

To give you an idea of what are people are dealing with lets take a look at what we just dealt with while getting Google to clear a website we had cleaned up.

Once you have cleaned a website with the “This site may be hacked” message, you need to add the website to Google’s Search Console and then you can request a review in the Security Issues section of that. That section will also give you information on what Google detected:

security-issues-page-1

 

In this case Google detected that spam pages were being added to the website, which they refer to as an URL injection.

Before requesting a review last Monday, we doubled checked that the spam pages no longer existed using the Fetch as Google tool in the Search Console, which allows you to see that what is served when a page is requested by Google. The URL they listed on the Security Issues page was “Not found” when we used the tool, indicating that the spam page was no longer being served to Google.

On Tuesday a message was left in Google’s Search Console for the non-www version of the website’s domain indicating that hacked content had been detected:

seach-console-message-non-www

Considering that Google was already listing the website as having a security issue for several days you might think this was a new detection, but it wasn’t. In the security issues section it still listed the old last detected date:

security-issues-page-2

Using the Fetch as Google tool in the Search Console we requested the URL again and it was still “Not found”:

fetch-as-google-4-19-2016

Then on Wednesday the same message was left for the www version of the domain:

seach-console-message-www

Again the last detected date in the Security Issues section hadn’t been changed and the using the Fetch as Google too the URL was still “Not found”:

fetch-as-google-4-20-2016

Then on Saturday the Security Issues page indicated that URL injection had been detected as of that day:

security-issues-page-3

We again used the Fetch as Google tool and it was still “Not found”:

fetch-as-google-4-23-2016

At this point we also checked the website over to make sure the malicious code hadn’t returned and it hadn’t.

Then this morning the warning was gone from the search results and the Security Issues page was clear:

security-issues-page-4

Considering that nothing changed between Saturday and today, that detection on Saturday would seem to be some kind of a mistake. Seeing at the page wasn’t even being found this doesn’t seem like an understandable false positive, but something seriously wrong with their system. If you weren’t aware of that how problematic the process is, you might have been very concerned upon seeing the new false detection.

The fact that it took them a week to finally clear the website also doesn’t seem to be an acceptable in this case.