Site hosting news, tutorials, tips, How Tos and more
It may be an odd thing for a website host to ask, but “Who needs a website?” is a valid question. Many of us here at Winhost have been in the hosting business since it started, more than 20 years ago. The business – and maybe more importantly, what you expect from it – has changed more than a few times over the past two decades.
In the early days you built your own website. Period. So you needed a website host. There weren’t any other options, and there certainly weren’t any social networking or social media sites where you could establish an online presence without a website.
The first generation of point-and-click website builders sprouted up in the 1990s, but for the most part they were clunky sledgehammer approaches to site building, so they never really caught on with most website owners.
In the early 2000s social networking sites came in to our lives, starting with Friendster, which was quickly eclipsed by MySpace, the dominant platform for a few years. That is until Facebook came along to make all of the other social networking sites obsolete. I’m not sure that world domination was Facebook’s plan, initially, but that’s how things played out.
But regardless of which platform you used, suddenly if you couldn’t build a website, or had no interest in building a website, you could establish an online presence. And when that particular revolution happened, the perceived necessity of a traditional, build-it-yourself website (and someone like us to host it) briefly waned. But only briefly.
Rapid advances in web technology and the increasing spread of broadband Internet connections paved the way for a new generation of website building platforms like SquareSpace and Wix. With the new platforms you could build a site without bothering with any of the behind-the-scenes nuts and bolts. A lot of small businesses flocked to the new site building and hosting platforms, and away from traditional website hosting. But over time the drawbacks of those systems became apparent.
Now we’re seeing an increasing number of people moving away from social networking sites as their primary business presence, as well as making the sometimes tough decision to leave the point-and-click site builders/hosts. They’re moving back to traditional hosting because they are realizing that those point-and-click platforms lack some fundamental and essential ingredients for a successful business site (or any site, really), mainly: flexibility, SEO (visibility), and portability.
A business site needs flexibility. The ability to scale out with different kinds of pages or applications that a platform like SquareSpace or Wix don’t necessarily offer or support, the ability to choose or change how you accept payments, and the ability to change the look and feel of the site. On some of the site building platforms you are stuck with the style or template that you chose when setting up the site. In order to change the appearance of the site you have to re-build it from scratch. Ouch. And while e-commerce is baked in to most of the platforms, you’re limited to the methods and providers that they offer. Social networking sites are even more inflexible and limited.
Every website owner eventually becomes concerned with search engine optimization, or SEO. You may not give it a lot of thought when you are building or launching your site, but when you want to expand your audience or customer base, you will have to dive in to the deep, murky waters of SEO. Much of what’s necessary to maximize a site’s SEO is done on a page level or a configuration level, and if your site lives on one of the walled-in platforms, you simply won’t have the access necessary to make many beneficial changes. So you’re limited in what you can do to make your site grow.
As far as portability is concerned, they’ve made it purposely difficult (and in some cases, impossible) to move a site from a platform like SquareSpace or Wix to another platform or to a traditional host like Winhost. Understandably, I suppose, as it’s in their interest to keep you inside their walls so you will continue to pay them every month. Making it easy to move a site would mean making it easy for their customers to leave, so they have every incentive to make it as painful as possible. And of course you can’t take your Facebook page away from Facebook.
For those and other reasons, we’re seeing a move back to traditional custom-built websites hosted on open platforms where you decide how things are going to work, rather than being at the mercy of a large company’s development and support teams. Building and maintaining your own site comes along with its own costs, of course, both in development and maintenance. But the freedom and ability to steer your own ship that are gained by creating your own site will outweigh those costs for most of us.
And if you don’t want to start from scratch, there are now a lot of platforms and frameworks that you can install in your own hosting space to give you a head start. The most popular of those, WordPress, is running on more than 26% of the world’s active websites (that’s more than 77 million WordPress sites if you’re doing the math). In fact, in 2016 Microsoft moved thousands (yes, thousands) of its sites and blogs off of their own proprietary platform and over to open source platforms like WordPress, and you can be pretty sure that wasn’t a decision that was made lightly.
The bottom line is it’s easier than it’s ever been to build a flexible and portable site that you can easily change and update to suit your needs.
So the answer to the question, “Who needs a website?” is: you do. Whether you build your own site from the ground up or base it on a solid foundation like WordPress, what it all comes down to in the end is control, control, control. Take it! Keep it! It’s your website, you should be the one who decides how it works, what it looks like and where it lives.
Of course, if you want it to live here at Winhost (and really, why wouldn’t you?), I’d be remiss if I didn’t mention that we have a fully managed WordPress service that removes a lot of the maintenance and security concerns from your plate, freeing you up to focus on the most important thing in all of this: making your site the best it can be. You’re still in control, we’re just at your service. It doesn’t get any better than that!
It used to be that unless your site accepted payments for products or services, you didn’t really need to concern yourself with an SSL certificate, which allows you to encrypt and secure your site traffic using the https protocol. Those days are quickly coming to an end as web security becomes a larger issue, and giants like Google are making an aggressive push to encrypt all web traffic.
Maybe you have even already received a warning email from Google: “Beginning in January 2017, Chrome (version 56 and later) will mark pages that collect passwords or credit card details as ‘Not Secure’ unless the pages are served over HTTPS.” But what does that mean?
Right now (December, 2016) Chrome shows an “information” icon on all non-https pages (Firefox also uses a similar icon):
Which seems pretty benign, unless you click that icon and get the insecure site warning:
Starting in January of 2017 Chrome is going to take that a step further and add a text warning:
Then “eventually” – which, knowing Google, could be any time – they are going to throw the red flag at non-https pages:
At the moment those warnings only apply to http pages containing password or credit card input fields, but Google definitely plans to extend the Chrome warnings to all http pages, regardless of whether they accept user credit card or authentication input.
Using https encrypts connections to prevent anyone from tapping in to the communication between your website and your visitor’s browsers. It also prevents the bad guys from exploiting your site by injecting malicious code or unwanted advertising into your user’s browser.
The https connection lets your visitors know that they’re securely connected to your site. That what they’re seeing is legitimate information. It also prevents anyone from accumulating of a lot of user data or behavior related to your site traffic. Aggregate data like that can be used for a number of malicious purposes, so blocking access to it is a good thing.
Right about now you may be thinking, “Okay, I get it, but I’m not really concerned about someone listening in to my site traffic.” That’s understandable. Most sites run a pretty low risk of being targeted in that way. But you probably don’t want to see every page of your site displaying a red “Not secure” warning in Chrome (and eventually in other browsers as well).
That’s reason enough to take steps now to make every page of your site available via https (and redirect http requests to https). You might even consider it a priority, since the Chrome browser currently has a 56% market share, and that percentage is increasing.
But aside from avoiding the warning label, there can be other benefits to using https. In their own words:
“Google uses HTTPS as a positive ranking signal. This signal is one amongst many others, and currently carries less weight than high-quality site content; you should not expect a major SEO advantage for moving to HTTPS in the short term. In the longer term, Google may increase the strength of the HTTPS boost.”
Google is making it pretty clear that in the future they are going to give an edge in search result rankings to sites that use https. And who doesn’t want an edge where that’s concerned?
The good news is it isn’t exactly a “move.” Your site stays on the same server, you just add an SSL certificate to your account and make the necessary changes to redirect http traffic to https. This article is already pretty long, so we won’t do a tutorial here, but other than redirecting to https, there are a few other things you’ll want to watch out for:
If you use Google Webmaster Tools, after you’ve made the switch, add the https version of your URL as a new property, set the “preferred version” of that property to https and (re)submit your sitemap. Here’s a Google-centric FAQ on transitioning to https that you may also want to take a look at.
Finally, you may have heard that you can get a free SSL certificate from Let’s Encrypt. That’s true, and you can use those certs here at Winhost. But the Let’s Encrypt certificates come with some drawbacks. Make sure you’re aware of what’s involved in using such a cert before you commit to one.
We’ll have more information on this subject in the coming months. We expect that there will be a lot of questions when Google makes the changes to Chrome, and we’ll do our best to address those questions here and in our Knowledge Base.
The changes have already begun in the latest version of Chrome (55.x). They aren’t flagging insecure sites yet, but they are spelling out “Secure” now:
There is a lot of talk around using https “everywhere” these days, even on websites that do not do any financial transactions or accept user data input. Google already uses https as a factor in search results (though it’s a small factor, and not universally used in results everywhere in the world). But they have made it clear that their intention is to expand the use of https as a search results ranking factor next year.
All of which has a lot of people who may have never considered using an SSL certificate before looking in to making the move to SSL/https. The main barrier for a lot of people isn’t the technical issues around implementing an SSL certificate, but rather the price. SSL certificates cost money. Some of them (like those with “Extended Validation”) cost a considerable amount of money.
A group of security-minded people thought there should be a free alternative, so they got together and the open source Let’s Encrypt project was started (by the Internet Security Research Group, with support from the Electronic Frontier Foundation, the Mozilla Foundation, Akamai, and Cisco Systems). Let’s Encrypt is now up and running, issuing free SSL certificates to anyone who wants one.
Pretty great, right? Well, yes and no.
For instance, if you want one of those Extended Validation certificates, you can’t get it from Let’s Encrypt. Organization Validation, Extended Validation and wildcard certificates are not available. Let’s Encrypt does not verify sites, so if you want a security “seal” to put on your site or order form, you can’t get it from Let’s Encrypt.
That’s right, Let’s Encrypt does not verify sites, which means hackers are building malicious sites using Let’s Encrypt certificates because they’re free and the bad guys can remain anonymous. Wait a minute, though – isn’t validation the whole reason for a security certificate in the first place? And what will become of the Let’s Encrypt certificates if their system becomes overrun with malware and phishing sites?
Even if you don’t care about any of those things, the Let’s Encrypt certificates have a major convenience drawback, because the certificates are only valid for 90 days. That means that every three months you have to request a new Let’s Encrypt certificate and install it on the server, and that process is no fun. Especially on Windows servers (like those at Winhost), since there is not any server-side automation available.
But increasing security is never a bad thing. And don’t forget, Google is going to look more favorably on https sites very soon, so an SSL certificate should be on your to-do list, no matter what kind of site you run. If you want to use Let’s Encrypt on your Winhost site, you certainly can. We support it. We don’t recommend it – for the reasons we just mentioned – but if you’re up for going through the process every 90 days, you can.
But if you’re more of a set-it-and-forget it type, we offer a full range of SSL certificates, starting at as little as $39 a year. You can register a certificate for two years as well, meaning it’s not something you have to think about every 90 days, or even every year. If you want to secure your site (and don’t want to see your Google ranking drop) you may want to get yourself an SSL certificate soon.
As if everything related to domain name registration and maintenance wasn’t already screwy enough, there is a new change on the horizon that promises to make updating your domain names even screwier.
After December 1, 2016, when you change the first name, last name, contact email or organization field for your domain, it will trigger something called the “trade process.” Without going into too much technical detail, what that means is those previously minor ownership information changes will now be treated the same way a domain transfer is treated.
The problem with that is now the domain owner will have to approve those changes via two separate – but similar – emails. That’s because the “current” and “previous” owner – which are the same person in this case – need to explicitly approve the change, or it will not be made.
So if you update your name or the name of your organization, you’ll have to approve that change in two emails. If you update the email address associated with a domain name, you’ll have to approve that change at the old and the new email address. You can probably already see some potential problems, can’t you.
So why are these changes happening? Well, ICANN started reviewing the transfer process almost 10 years ago, when potential issues with the existing transfer policies were identified. So they began looking at “special provisions” for change of registrant during a transfer in order to prevent domain hijacking.
Which sounds like a good thing, but now, a decade later, what we ended up with is a process that may make it slightly more difficult to hijack a domain, but definitely makes a lot of day-to-day maintenance tasks more difficult and confusing.
Every registrar has some leeway in how they implement the changes, so we’re not sure yet exactly how it’s going to work for domains registered through Winhost. We’ll do everything we can to keep the confusion to a minimum, and we’ll post an update here when we have more information on how things shake out.
Do you know what ransomware is? It’s a computer compromise, typically spread via a macro in a Microsoft Word file. Those spam “invoices” you get, with a .doc attachment? They’re almost always ransomware. If the macro is run, most of the document and image files on your computer are encrypted, and the hacker then extorts money out of you to get the key. The longer you wait, the higher the price.
Right about now you’re probably thinking, “Not a problem for me, I have backups for all my important files!” Which is good. You can reformat your computer, restore your backups and be done with it. Lesson learned. If you’re not backing up your computer files, now’s the time to start, right? Right? Get started. Seriously.
If that wasn’t bad enough, the people who write ransomware have now figured out how to encrypt your website files and hold them for ransom, and compromises are spreading rapidly across the web. The compromise is done through vulnerabilities in third party applications or your own scripting (out-of-date WordPress sites are a common target – update your WordPress site, plugins and themes!).
At the time we’re writing this, that ransom starts at around $175, and goes up from there the longer you wait. The best way to guard against that is the same way you’ve guarded against site compromise forever: keep your third party application updated, and examine your own code for vulnerabilities.
But if the bad guys do get in and your site files are encrypted and held for ransom, what can you do?
Well, we make site and database backups every day, so we may be able to help you restore the unencrypted version of your files. But our backups are meant for disaster recovery, so there’s often a fee involved with pulling and restoring a copy, and it will take a little time. In addition to that, we only keep a few days of backups. If you don’t notice a ransomware compromise for four or five days, all of our backups will probably be copies of the compromised files, and therefore not useful in restoring the site.
The best answer is maintaining a tight ship, as far as your site is concerned. But a really good standby strategy is our SiteBackup service. It allows you not only to back up website and database files, but to keep multiple versions of those backups for long periods of time. That increases the likelihood that you will have a “clean” backup to restore to defeat the ransomware goons. The best part is you control the backups, they’re available to you immediately any time you need them.
Another cool thing that SiteBackup can do is alert you if Google flags your site as compromised, and automatically disable any further backups. That means you can rest easy that you’ll always have a clean backup for restoration.
Any way you slice it, it’s better to be safe than sorry, so we really recommend checking out SiteBackup. It’s inexpensive (starting at $2.95 a month for 10GB of backup space!), extremely easy to use, and – we think – some of the best peace of mind money can buy.
Activate SiteBackup in Control Panel now.
Here’s what a site compromised by CTB-locker looks like:
Note: beginning with Chrome version 46 the yellow caution triangle has been removed from the https URL when Chrome encounters minor errors such as those described in this article.
If you use an SSL certificate (https) on your site, you may have seen a couple of new things happening in Google Chrome.
When you upgrade the Google Chrome browser to version 41 or later, you may see various warning messages such as, “The identity of this website has not been verified,” “Your connection to <domain> is not encrypted,” or other visual indications that the https connection is not secure.
Those indications can appear when your SSL certificate uses a SHA-1 signature (most SSL certificates issued before 2015 use SHA-1).
To fix the problem of browser security warnings you must get your SSL certificate re-keyed for SHA-2. If you don’t see those warnings in Chrome and you purchased your certificate recently, it may already be SHA-2. You can verify using this test site.
1) Contact us and we will re-generate and re-submit the CSR.
2) You’ll then get an email from GeoTrust with a link to complete the process. When completing the re-key on the GeoTrust site, be sure that SHA-2 is selected as the “Hashtag Algorithm.” You can find step-by-step instructions (and a video) here.
3) After you’ve completed the reissuing process, you’ll receive an email with the new certificate. Go to Control Panel and paste the new certificate into the SSL manager and you’re finished.
1) Contact us and we will re-generate the CSR and email it to you. Then you’ll have to contact the issuer of your certificate to get your certificate re-keyed for SHA-2.
2) When you receive the re-keyed certificate, go to Control Panel and paste the new certificate into the SSL manager and you’re finished.
There is another potential problem after you’ve re-keyed your SSL certificate. While the address bar will show the green lock icon, if visitors dig deeper in Chrome, they may see an “Obsolete Cryptography” message.
Basically what’s happening now is they are ignoring the cipher preference we use on the server (which includes their preferred ciphers) and pointing out any “weak ciphers” they find. You might notice that many large corporate sites (such as Apple) are also insecure according to Chrome, for similar reasons.
That “obsolete cryptography” message may be with us for a while because Google is not providing any information (yet) on exactly what they want from the server to stop calling it insecure. It would seem that what Google would like to see is every server everywhere removing support for all older cryptographic methods.
The problem with that is removing some of those methods will shut out visitors using some older browsers and operating systems that don’t support newer methods (i.e. Windows XP). Since our servers are shared by many customers, it isn’t really an option for us to make global changes that prevent some visitors – even a small number – from accessing our customer’s sites.
We do run some special servers that do not support any of the older cryptography methods, they are primarily used by customers who need a “hardened” server to pass a PCI compliance scan. But the added security comes at a cost, as older browsers can’t connect to sites on those servers via https. Additionally, a few other things that you may take for granted now may not work, or may require adjustment or a work-around on your part. But if you’d like to move your site to such a server, just let us know.
And of course we continue to monitor information from Google on recommended server configuration, as well as continuing to test various configurations ourselves to prevent the “obsolete cryptography” message.
If you have any trouble re-keying a certificate, or if you have any questions about these ongoing changes, drop us a line and we’ll do our best to help.
Google announced that they would be closing Google Checkout over a year ago, but now they have announced the date when the service will close permanently; November 11, 2013.
If you use Google Checkout on your site they have a FAQ to help you transition to another system.
One can never underestimate the importance of upkeep and routine maintenance, especially when it comes to web sites and applications. When we do not practice due diligence or neglect our web applications, hackers can find holes, weaknesses, and exploits in our so-called “secure” sites.
That holds even more true when it comes to “canned” applications such as Joomla. We have learned that Joomla version 2.5, and 3.1.x have a security hole that can allow anyone to upload malicious files through your application.
The malicious files can perform cross-site scripting (injecting a string of code to your web pages, which can redirect users to a phishing site), or distribute malware or Trojan files that can affect your visitor’s computers.
The security hole in Joomla is its Media Manager, which offers you a tool to upload files to the website. This is a necessary function in a CMS such as Joomla. Joomla comes with its own filtering mechanism that prevents anyone uploading files with specific extensions that can be malicious in nature. Files with extensions such as .exe or .php should not be uploaded as they can infect your web application.
However, the bug is that a trailing dot on a file name can circumvent the filtering mechanism. Normally Joomla will prevent the upload of files with a .php extension such as document.php. However, include a period at the end, such as document.php., and the file no longer fits the .php criteria.
Nasty bug to say the least. What is more frightening is that you do not have to be a registered user or have administrative privileges to the application to exploit the bug. If the Media Manager was set to be available to the public, anyone can inject your site with a malicious file.
The simplest way to solve this problem is to go to Joomla’s website, download the most recent version, and upgrade. This should have the latest patch to this security threat.
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31626
http://www.joomla.org/announcements/release-news/5505-joomla-3-1-5-stable-released.html
If an upgrade is not an option for you, you can manually add the code that will prevent users from uploading files to your application with a trailing dot.
Navigate to /Libraries/Joomla/Filesystem and open file.php. Scour the code to find where the makeSafe function starts. Add the line:
// Remove any trailing dots, as those aren’t ever valid file names.
$file = rtrim($file, ‘.’);
If this line already exists then your Joomla application is immune to this specific security hole.
That doesn’t mean that you should not routinely follow up on the most recent news concerning your web applications. To really secure your site it is important to stay informed of the most recent patches for your web application.
Here are links you may want to check to stay up-to-date with Joomla’s security fixes. Keep in mind that some security patches may not apply to you depending on the version you are running.
http://docs.joomla.org/Vulnerable_Extensions_List
Let me lastly say that we here at Winhost take this threat seriously. As of today, we have updated our App Installer to the most recent Joomla version (3.1.5) with the security patch installed. If you installed your Joomla application with this newest release, you are protected from this specific threat, however if you have installed an older version from us you may want to check file.php within Joomla and make sure the appropriate line is added.