Welcome to 1aNoSSL.net

This site exists to help people who have been victimized by the "The Jekyl and Hyde SSL Bug".

[Home] [The Problem] [How it affects YOUR site] [The Fix for NON-SSL Sites] [The Fix for the Site Owner] [Final Thoughts] [Links to other sites reporting the bug]

The Problem

By Chicago : National Prtg. & Engr. Co. [Public domain], via Wikimedia Commons

What is the Jekyl and Hyde SSL Bug?

I coined the name "Jekyl and Hyde Bug" to describe this bug since it fits the situation so well considering how it can present on a docile http-only web site one moment and a completely unpredictable site with the same URL in the next moment with the mere use of "https" on the same site on a shared web server under the right circumstances.

This "bug" describes an issue that occurs with SSL certificates on shared web hosts the world over. At the time of this writing in late 2017, I can only guess at the sheer scale of this problem, but it could very well affect thousands if not many hundreds of thousands of web sites out there.

For purposes of this article, we will call the Jekyl and Hyde bug "JH" for short. We will use the term "Non-SSL" to indicate sites that do not have SSL and are on the same shared server. "First Site" refers to the first site in a alphabetical list of sites on a shared server that has a valid SSL certificate active and in use.

Simply put, if your web site is on a shared host, meaning that your site is hosted on a server with other web site owners, all sharing the same IP address, then you may be exposed to this bug. I use the term "bug" loosely since this seems to be more of a standards design, policy and best-practices issue that is an outcome of how SSL works.

If yours is the first site in an alphabetic list of domain names on that server that has an SSL certificate installed for your root site, then your site receives ALL of the traffic from ALL of the other sites on that server if someone uses "https://" to try to reach traffic on a Non-SSL site. Let's see how this works below:

We have a mythical Apache shared server called "Alpha" with four sites on it:

Server Alpha - An Apache server that is a shared IP server with an IP address of 1.2.3.4 (we're using this as example) and has the following sites on it:

So - ALL of the Non-SSL sites, like a-example.com, c-example.com and d-example.com have their sites https traffic redirect to Site Two - b-example.com when their URLs are accessed with https rather than http. Site e-example.com never has an issue since it's SSL certificate is active and it's https traffic goes where it needs to. Let's say b-example.com gets wise and leaves the shared server to get a dedicated I.P. address. Then e-example.com now has the problem! It becomes the new First-Site!

So - The upshot of this is that ALL of the Non-SSL sites end up as a two-faced site - Literally a Jekyl and Hyde situation - One face - the mild-mannered Jekyl has the "http" site with the intended content and then the "Hyde" face displays the unpredictable content of the https site.

This is a HUGE security blunder. In fact, monumental! This should NEVER happen! Ever! And yet providers are letting it happen!

When https requests are issued on the Shared Server for Non-SSL sites on that server, the Apache server isn't able to sort out which certificate to use on it's own without help. So the first available alphabetically sorted domain with a valid SSL is selected. And this is where the oversight occurred. For the life of me, I cannot figure out how this massive bug wasn't spotted by the people who crafted the SSL standard in the first place and steps taken to prevent these issues in the first place! At a minimum, this should be a situation handled by the Server owners who mitigate it BEFORE it gets out in the public domain.

This has a series of effects for both the First Site who is now the primary victim in all of this and who receives massive amounts of traffic on their web site and the Non-SSL site whose search engine stats are now polluted with traffic for content that isn't theirs. So this poor site owner ends up bearing the brunt of the JH bug and is likely wondering why they are getting so much strange traffic on their site and inexpicable site listings of their content on search engines which we will cover next.

[Top]

How this affects YOUR site

The next effect of the JH bug is the one that causes real issues. When search engines come calling to the shared server and use "https" for a non-ssl site on the same server, this causes the search engine to index the content as if it is on the non-ssl site! And yet the content being indexed is from the First Site!!!!! This is a blatent oversight in the implementation of SSL on shared servers and is causing massive confusion.

The net effect of this is that now the First Site has it's content appearing on Google, Bing and other search engines as if it is hosted on the non-ssl sites (which it is not), but because the service providers refuse to address this giant hole in how they handle SSL on shared servers, it not only victimizes the First Site, but all of the Non-SSL sites whose sites are mistakenly getting indexed because of an https:// link is being misdirected in the first place!

The image below shows this in action. In this case, my site was the First Site on a shared server and a number of other sites were getting indexed with MY content! I am calling this "Ghost Content" since the content really doesn't exist on the URL in question, but is showing up in the search engine as if it is. And if you click the link, the Apache server sends the user to the First Site and serves up the content which it should NEVER have been able to do in the first place!

All of these sites were showing up with my content! And it is because of a design issue with Apache and SSL that makes the first alphabetical listed site with a proper SSL certificate on a shared server into the victim! Not only are my Google results affected but so too are the people whose sites are getting traffic misdirected because of an inane design and a lack of willingness on the part of providers to fix this issue for reasons as yet undetermined.

[Top]

The Fix for the Non-SSL sites

First - See if you have a problem in the first place. add https:// to your site URL and see where it goes. If it gets sent to the wrong site then you have the JH bug affecting you. If you get a error code 410, then it may be that a First Site owner is directing your content to fail for the shared server and you STILL have the issue. If you get a site not found type of message then that is good news.

For the Non-SSL sites on the shared server, you are left with a few choices:

  1. Get an SSL certificate and install it so YOU control the SSL traffic on your site. Google is going to press sites to use SSL by the end of 2017 or have their content marked as unsafe in the search results anyway, so it is a good idea to get it done and bite the bullet.
  2. Install your site provided "self-signed" certificate for YOUR site or sites on the server to control your site content and stop your site from being one of the many hit by this! If you don't know how to do it then have your provider do it for you. The cost should be $0 or a minimal fee by your provider.
  3. If you can ascertain who the First Site owner is, you can contact that person to let them know of the problems you are seeing and cite this article with the suggested fixes we propose using.

Note that I have noticed that sites I created on my provider site all are, by default, having unsigned certificates, but this MAY mean they are beginning to address the issue by forcing SSL certs, even unsigned ones on new sites. Perhaps the providers are trying to work out the solution, but have yet to correct all the sites being served out there. It is hard to tell since they refuse to talk openly about it.

[Top]

The Fix For the First Site Owner

For those unlucky First Site owners, like myself who was put in this position against my will, there are two actions you can take:

# -----------------------------------------------------------------------------------------------------------------
# Add this set of lines to your .htaccess file. Change as needed for your domain
# Note that the F,G option in the rewriterule says to fail the request and then to
# mark the respose with an error code 410. This tells the visitor and the search
# engines that the page or content being requested is permanently removed.
RewriteEngine On
RewriteCond %{HTTP_HOST} !^(www\.)?YOURDOMAINNAMEHERE.COM [NC]

RewriteRule .* - [F,G]
# -----------------------------------------------------------------------------------------------------------------

In plain English, what this does is to check that the visitor is coming to YOUR domain. If not, they get a failed request for that URL. It's that simple. Make sure to test your access to your site after you add these lines and also try the URL of one of the "ghost-content" sites with "https://" to test that this works A-Ok. You should see an error code 410 if you used the rule set above. The "410" rule tells all search engines that the content here is gone and isn't expected to return. It's a way to regain control of your content and also get the search engines to get rid of your ghost-content on other site URLs..

For those who are technically astute, I could have written the RewriteRule in such a way as to force the traffic to the non-ssl address of the host name, BUT that is a) masking the probem and b) chewing up MORE of my bandwidth in the long-run because I've put a band-aid on the problem with such a solution. It is better to fail any web request not coming to your domain anyway and shut the problem off at the source. And... It's just the right thing to do, despite the fact that this should never be your problem to deal with in the first place.

Finally - This solution of mine only treats the worst of the problem, which is the search engine issue. You still will get vists to your site if you are the first https site on the shared server, BUT, the bandwidth consumed will be much smaller. Your logs will be much cleaner and your search results will be cleaner. It will take some time for the fix to be reflected on the search engines as well.

It's the best solution I could come up with after a confusing journey which finally led me from a demand for $$$ from my provider who happily was stretching out their hand to help the hapless (NOT!) vitcim of this scheme. I solved the problem with a few lines of code and then made it my mission to create this site and get the word out.

[Top]

Final thoughts

Now for the shocker. Web providers seem to know about the problem and the EXACT scenario I discovered and have been victimized by is covered on the Cpanel.net web site. In fact, it is well known! There is even a recommended procedure to fix this! And yet, my provider made the choice to NOT fix this for reasons as yet known. Everything I validated in MY testing procedure is mirrored here on Cpanel's site!

Click the Cpanel.net link and look for "

"My certificate installed, but visitors who try to securely access other sites on the shared IP address can only see the site with an installed SSL certificate, not my default domain."

This text will then show you the exact scenario I am encountering. And they recommend a fix that the provider can follow to repair the issue. Why this wasn't done in my case remains unknown, but it is surprising to say the least! To see the recommended fix in the same site page - look for the text:

"To allow visitors to visit an unsecured domain regardless of which type of protocol they enter, perform the following steps:"

Why would a vendor who KNOWS the solution refuse to perform it, unless there are serious technical, fiscal or a combination thereof obstacles to not allow them to repair the issue and stick the "First Site" users like myself with tons of traffic we don't want?

So... There is a cure for the dual personality Dr. Jekyll. It's just that the professionals will not admister the medicine for reasons as yet unknown...

The ethical concerns I have in all of this is that the Share Server Providers are putting First Site owners in a real bind. These people end up having huge amounts of traffic visit their domain and skew their logs. Secondly, they are exposing themselves to legal action since they are giving First Site Owners authority to handle traffic belonging to other sites.

In my estimation, legislation at the Congressional level will be needed to address this. It will take this to force a fix that is literally affecting countless numbers of web site owners world-wide. I'd bet that a settlement with a simple change to shared servers to host a self-signed SSL cert as a fake "First Site" controlled by the provider on each and every shared server will stop the problem in it's tracks and would be the right outcome. Or... to fix the standards that created this in the first place and fix it at the source.. But since when has there ever been common sense with legal and ethical concerns in big business or government in general? My bet is that the "pass-the-buck" attitude when I encountered this issue and tried to work with my provider is the norm and not the exception. Mine is a lone voice in the millions of web site owners out there, but I have twenty-five years of web admin experience and that does count for something.

In the meantime, web providers have literally ceded power to the First Site owners to control the destiny of all of the other Non-SSL web sites on the same server they reside on. In my 40+ years of IT experience, this is the single greatest security issue I have EVER encountered and trust me, I've seen some really bad stuff. This issue, by it's sheer magnitude, is something I never expected to see a web provider do, much less an entire industry that is turning a blind-eye to it.

I will also point out that a First Site owner who is a nefarious sort could do all sorts of things with the content requests of the Non-SSL sites on a shared server. At this point, if the victims become aware of the problem, then this becomes a law-enforcement issue along with the provider having to take action. I'm a town-cryer at this point and am hoping someone does something about this and fast, because it is a massive security breach, the likes of which I have never seen in all my years of IT work.

So... For now... The power is in your hands First Site Owners - Use it wisely and ethically until the law and/or the Internet providers come to their senses.

P.S. - Why did I write this? Well - I was a victim of this bug and found that my provider was completely unwilling to repair their server and tried to charge me money to fix a problem that was theirs to fix in the first place. It got me angry. Angry enough to spend a few bucks and create a new site and put my 25+ years of web experience to work, even though I'm retired. This may well be the most important technical paper I've ever written and I just hope it helps people. Finally - Visit the links below to learn more about how other people have encountered this dangerous and insideous bug and how few people have appreciated the magnitude of it.

Sincerely - Jon.

If you wish to contact me, visit my Contact page.

[Top]

Links to sites reporting the Jekyl and Hyde SSL Bug

Copyright 2017 - Afterburner1.com