Site hosting news, tutorials, tips, How Tos and more

Archive for the ‘Technical’ category


How SSL certificates work

SSL certificates are necessary if you do credit card transactions on your site, or if you simply want to make your site available via an HTTPS URL (such as: https://example.com). If you visit that URL without the HTTPS prefix, you’ll notice that there’s no security “lock” displayed in your browser. That lock icon means your connection to a site is encrypted.

If you’ve never cared about HTTPS, it’s probably time to start. The days when you could avoid using HTTPS are rapidly coming to an end, and Google and the other big web browser makers are more or less forcing the change on everyone. So it’s a change we’re all going to have to make, or one day in the not-too-distant future, security warnings could be greeting every visitor who loads our sites.

With that in mind, here’s a high level overview of what SSL is and how it’s implemented. Think of it as an introduction to the concepts and a peek at the inner workings for anyone who is new to the subject.

Technical note: modern web servers don’t really use the SSL (Secure Socket Layer) protocol anymore, but the name has stuck to the certificates as kind of a generic identifier, so we use “SSL” in this article. The TLS (Transport Layer Security) protocol has replaced SSL for most uses. We’re also using the example of a web browser connecting to a web server, but the concept is the same no matter what kind of client is making a secure connection to a server.

What is an SSL certificate?

An SSL certificate is really just a text file that is installed on the web server. It ensures that the domain name in the certificate matches the domain name of the site, and enables a visitor’s browser to make a secure connection to the site, so that the traffic back and forth is encrypted and no third-party can listen in on the conversation.

The reason for encrypting transferred data may be obvious where financial transactions are concerned, but even if you’re not sending financial data across the web, quite a bit of private data can be passed between your site and a visitor’s browser (like usernames and passwords). That private data is valuable to unscrupulous types, so encrypting the connection protects the data. Without an SSL certificate and the HTTPS connection, that encryption doesn’t happen.

It’s worth noting here that an HTTPS connection doesn’t prevent someone from finding out which domains you’ve visited. It just makes it (theoretically) impossible for them to see any of the data that was exchanged during the visit.

What’s inside the SSL certificate?

An SSL certificate contains information about your business or organization (or simply you as a person), and a cryptographic key unique to your domain or certificate. That key is used to establish the encrypted connection. Your website presents the key to the visitor’s browser, and if the browser determines the key is valid (more on that in a minute), the encrypted connection is established.

Let’s talk about trust for a minute…

The entire SSL system is based on trust. When the HTTPS protocol was established, everyone agreed to trust certain organizations (and later companies) to issue legitimate certificates. Those organizations and companies are called certificate authorities. The certificate authority verifies who you are when they issue the certificate and the browser trusts the that the certificate authority has done that verification.

You might see a bit of a problem there if you’ve ever requested a “domain validated” SSL certificate and noticed that no one actually checked anything other than the fact that you had an email address on the domain. It wasn’t always that way. In the early days of SSL, the certificate authority did verify that you were who you said you were, and the owner of the domain you were requesting a certificate for. But as you might imagine, that time-consuming kind of validation quickly became impossible, so now that level of manual human validation is only done for expensive “extended validation” certificates.

How does the browser know when to trust an SSL certificate?

Every certificate authority issues a “root certificate,” which is like a master certificate for that authority. If the authority operates under different names or resells certificates through other companies, they issue “intermediate certificates” that are related or connected to the root certificate. Then the certificate for your domain is associated with the intermediate or root certificate, and that makes up a certificate chain. So the browser trusts the certificate for your domain because it’s associated with a root certificate.

Your certificate, any intermediate certificates and the root certificate are all installed on the web server. The same root certificates are also pre-installed in web browsers and many computer operating systems, so the browser can validate the root certificate on the web server. There are actually a few checks and validations that take place between the different certificates, but her’s a simplified diagram of the chain:

The connection is trusted if:

How does SSL work?

It’s pretty easy to get lost in the tall weeds here, because the underlying system that handles HTTPS encryption between a client (browser) and a server (your site) is quite complicated (and to add to the complication, the system is always changing, as better and stronger encryption methods are introduced).

But in a nutshell:

– The browser makes a TCP (standard Internet) connection to the site on the web server.

– The browser starts an SSL “handshake,” which is a transfer of data to the server about which version of SSL/TLS the browser is running, and which encryption methods it wants to use.

– The web server determines the highest SSL/TLS version that is supported by both the server and the browser, then sends its certificate(s) to the browser.

– If the certificate(s) meet all the criteria described above (in the “connection is trusted if” section), a cryptographic key is then exchanged and the browser tells the server that all further communication will be encrypted, and sends an encrypted authentication message to the server.

– The server verifies that the message is correct, then returns a similar message that the browser verifies.

– That’s the end of the “handshake,” and until it is broken, the browser and server can communicate securely.

Luckily all of those steps typically take place in a fraction of a second, and the browser and web serer don’t have to do them again (unless the secure connection is broken).

Well, that’s a lot of words for a “simplified” explanation, isn’t it. Sorry about that. But hopefully this has helped you to better understand what an SSL certificate is and what it does.

 

Still curious about SSL/HTTPS? Check out these other articles:

Ready or Not, It’s Time to Consider HTTPS
Let’s (not) Encrypt. But let’s not ignore https either.
How to Secure Your Primary Domain for Free When Ordering an SSL Certificate
Google Chrome, SSL certificates, SHA-1, SHA-2 and the “obsolete cryptography” message



How to Keep WordPress Safe and Secure

This little factoid should freak you out: More than 80,000 websites are hacked every day.

That’s almost one every second, or about 29 million every year. Those numbers translate to a lot of pain and inconvenience for a lot of people. Count yourself lucky if you’ve never been one of them.

There are a quarter of a billion domains with active websites. If 29 million sites are hacked every year, that means we’re living in a world where more than 1 in 10 websites are likely to be compromised. Every year.

How does this happen?

Security starts at home. It’s an old saying, but it applies to a lot of website compromises. We see a lot of hacks that aren’t actually website hacks at all, because the perpetrator is using valid FTP login credentials that were harvested by logging keystrokes or reading log files on a home computer or laptop that has been infected with a virus or malware.

But perhaps the most common way in to a website or server is through old, unpatched third-party software. And a large percentage of that old, unpatched third-party software is WordPress, or WordPress plugins.

Before I give you some tips on locking up your WordPress site, I’d be remiss if I didn’t mention that Winhost has a fully managed WordPress hosting, security and hardening service. The service includes WordPress hardening for maximum security, WordPress-specific support and personalized assistance, and maybe most importantly, monthly updates of WordPress core, Plugins and Themes. The monthly updates consist of one of our in-house WordPress security experts personally examining your WordPress installation for malicious files and signs of compromise. If we discover that your WordPress installation is compromised or hacked, we’ll clean up the mess.

Okay, that’s it for the sales pitch. But if you’ve ever had to clean up a WordPress compromise, I’m pretty sure that you’ll be able to see the value in that service.

Locking down WordPress

The first step in WordPress security doesn’t have anything to do with WordPress itself, but rather site backups. If you always have a current backup, it’s much easier to bounce back from a compromise. Simply identify your most recent “clean” backup, delete everything on your site and upload the clean backup.

We do periodic backups of our entire network for disaster recovery purposes, so if you are compromised you could just request a backup from us. The problem with that approach is we back up every day, and we only retain one copy of those backups. So if you don’t notice that your site has been compromised for a few days, our backup will likely be a copy of the compromised site. That’s not going to be of much help.

So we recommend a cloud backup service. There are a lot of them out there, or you can set one up from your Winhost Control Panel with a few clicks. Our SiteBackup service backs up your website files and databases on a schedule that you choose, retaining as many versions of the backup as you want to keep.

Okay, so that’s a good place to start, with a daily backup of your WordPress site and database. Next are a number of things that you should do to prevent a compromise of your WordPress site.

Update, update, update
How often do you log in to the admin section of your WordPress site? If it’s less than every week – or even every month – you need to start checking in more regularly and updating both the core WordPress files and all of your plugins. If you use a plugin and can’t remember ever updating it, check out the plugin’s page on WordPress.org and make sure it hasn’t been abandoned. If it seems like it has, uninstall it. Chances are there’s a well-maintained plugin out there that will do the same thing.

Kill the admin user
If you installed WordPress some time ago, it may have created a user named “admin” by default. Most brute-force WordPress hacks attempts are on the “admin” username, so you don’t want it to be there. To check, go to your Users page (/wp-admin/users.php) and see if admin is listed there. If it is, create another user or give another existing user the administrator role and delete the default admin user.

Don’t use the default WordPress MySQL table prefix
If the bad guys do manage to find a vulnerability within your site and one of their attempts is to query a table or insert into a table and you used the default table prefix, you could be in trouble. When you’re installing WordPress it’s best to change the table prefix from the default “wp_” to something different. One easy way to do that is to insert random characters after “wp_” – for example wp1od02l_ or wp5434fs_.

Change the WordPress login error
By default, WordPress gives hints about your login when a login fails. One of the steps in our hardening service is to change the login error to “You have entered the wrong Username or Password!” That way someone trying to compromise your site will never know if the username or password is incorrect, making it much more difficult to force or guess a login.

Remove the WordPress version information
It really helps the bad guys to know which WordPress version you’re using. Once they know the version, they can try known vulnerabilities giving them a better chance of getting into your site. They’ll also use Google to find WordPress blogs running a specific version of WordPress that’s easily hackable. You can use a plugin to remove version information.

Disabling Theme and Plugin Editing
The theme editor within WordPress is there to allow you to make quick changes to the code within a theme’s files. Chances are you won’t ever use that feature, but you can be pretty sure that the bad guys will make use of it to enter malicious code. In fact, that is how a lot of WordPress sites get hacked. To prevent that, enter the following rule in your Wp-config.php file, right before the “Stop Editing” tag:

/** Disable File Theme and Plugin Editing */
define('DISALLOW_FILE_EDIT', true);

What else?
The Winhost hosting environment goes the extra mile by disabling executable files from running within the uploads folder, as well as IP restriction of the wp-admin directory. That way the wp-admin directory can only be accessed from IP addresses you specify.

Last but not least, install a Security plugin
If you haven’t already done so, we would highly recommend installing one of the WordPress security plugins. As part of our hardening service we make the security plugin a “Must Use” plugin. That means the plugin can’t be disabled from the admin section of WordPress. The only way to disable it is by deleting the plugin via FTP.

That’s a lot to install, configure and keep track of, but following these recommendations will make your WordPress installation much less susceptible to compromise. If it all sounds good but you don’t really have the time or inclination to do it yourself, let us do it for you.



Deploying an ASP.NET Core 2.0 (Orchard Core) Site on Winhost

The great thing about ASP.NET Core is that it’s portable, allowing you to run your Core application on any OWIN-compatible server. So, even if a particular version of .NET Core is not installed on the server, you can still deploy your Core app in “self-contained” mode.

In this example, we’re going to use the Orchard Core application. Orchard Core is a re-write of the original Orchard application (the thing that runs all the MSDN blogs) in ASP.NET Core. As of the time of this writing, Orchard Core is using ASP.NET Core 2.0. And, at the time of this writing, we have not yet updated our servers with the newest .NET Core to support ASP.NET Core 2.0 natively, but, to repeat: you can still deploy your Core app in “self-contained” mode.

First, some house-keeping. Make sure you have the .NET Core 2.0 SDK installed and Visual Studio is updated.

Orchard Core supports different databases, SQL, SQLite, MySQL and Postgres. I’m going to use SQL, which is included with all Winhost plans. This is a good time to create the SQL database in your Winhost control panel.

Onto the instructions:

  1. Download the Master Branch of Orchard Core from GitHub.
  2. Unzip the file and open the OrchardCore.sln solution file in Visual Studio 2017.
  3. Wait for Visual Studio to restore all the Nuget packages.
  4. Set OrchardCore.Cms.Web as the startup project (right-click OrchardCore.Cms.Web and select “Set as Startup Project”)

  1. Open the OrchardCore.Cms.Web.csproj project file (right-click OrchardCore.Cms.Web and select “Edit OrcOrchardCore.Cms.Web.csproj”)

By default, Orchard Core is Framework-dependent. We have to change that to make it self-contained. We have to specify the target platform (tell the application what kind of server it’s going to be running on). In my case, my Winhost site is running on Windows 2012/IIS 8. You can find this information in your Winhost control panel, under the Site Info section. The Runtime Identifier for Windows 2012/IIS 8 is: win8-x64.  If you’re site is running on a different server, you can check out the full catalog of Runtime Identifiers here.

  1. In the PropertyGroup section, add:
    <RuntimeIdentifier>win8-x64</RuntimeIdentifier>

  1. Save your changes.

Now we’re just about ready to publish.  This would be a good time to remove the parts of Orchard Core that you’re not going to use. (For this example site, I didn’t remove anything.)

Before, pre-2.0, we would have run the dotnet restore and dotnet build commands at this point. But now, those are implicit commands with publish. So you can just run the publish command (right-click OrchardCore.Cms.Web and select “Publish…”). I used FTP to publish the project directly onto the Winhost servers. Instructions for different deployment methods are available here.

Wait for the project to publish, then navigate to your site and you should see the Orchard Core setup page:

I picked the Agency Recipe. Fill out all the fields, click the Finish Setup button and you should see your new site:



iPhone Secure Email Setup

We support secure SSL/TLS connections to our email server. We’re going to show you how to setup a secure connection with your iPhone.

For the “Incoming mail server”, enter:

For the “Outgoing mail server (SMTP)”, enter:

You will get a certificate warning about the server identity. We installed an SSL certificate on our email server for the convenience and security of our customers. But the problem is that we can’t install a certificate for every customer domain on the server. Instead, we installed a certificate for *.internetmailservice.net. The iPhone will display the warning because of the domain name mismatch; you are trying to reach mail.HostingAccountDomain.com, but the SSL certificate was issued to *.internetmailserver.net. The certificate we installed is safe to use.

Your iPhone may set the default SMTP port to 25. Many internet service providers block port 25, so you should change the SMTP port to 587.

You’re all set! Now your iPhone now has secured, encrypted communication with our email server.



Email change related to the postmaster@ address for your domain

We’re rolling out a change to the email system that you should be aware of.

The “postmaster” account is set up by default when we establish email service for a domain, but you have the ability to delete that account. The problem with deleting postmaster@ is that some important messages can be addressed to that address, and that’s because the SMTP RFP says the postmaster account for a domain is required to accept mail.

The change we’ve made is implementing behind-the-scenes forwarding that makes your primary domain admin the “postmaster” account (assuming you have deleted the postmaster@ account – if you have not deleted that account, you won’t see any changes). What that effectively does is ensure that email addressed to the postmaster@ address for your domain is delivered.

The side effect of this change is that you may see an increase in spam on your primary domain admin account, since spammers sometimes send to postmaster@, assuming that it exists on every domain (because they know that it’s supposed to exist).

A possible increase in spam is an unfortunate side effect of this change, but the alternative is the possibility of missing legitimate email addressed to your postmaster@ address. Those legitimate messages can be important, so we had to weigh the value of those important messages against the possibility of an increase in spam.

It’s worth noting though that we made this change on a small group of servers a couple of weeks ago, and we didn’t receive any feedback regarding an increase in spam, so the likelihood is you won’t notice much of a change with this new configuration.

As always, if you have any questions or concerns, open up a support ticket and let us know.



Ready or Not, It’s Time to Consider HTTPS

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.

Why is https important?

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.

How does it benefit me?

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?

How to make the move to https

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.

Update: January 4th, 2017

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:



Filezilla ENETUNREACH FTP Error with Kaspersky Anti-Virus

If you’re using the anti-virus application Kaspersky Endpoint Security 10 for Windows and Filezilla for FTP, you might have encountered an ENETUNREACH “Network unreachable” error when trying to upload your files to the server. Or, perhaps you updated Filezilla to version 3.11.0 (or above) and it stopped working, giving you the same ENETUNREACH error.

This is a known issue between Filezilla and Kaspersky. It happens because of the new way Filezilla binds IP addresses to prevent data connection stealing. You can read about the details in this forum post.

You can fix this issue by either reverting back to an earlier version of Filezilla (version 3.10) or by adding an exclusion to the Kaspersky firewall.

Follow these directions to add an exclusion for Filezilla:

  1. Open the Kaspersky application window (by clicking the Kaspersky icon in the notification area or through the Start menu)
  2. Click on the Settings tab
  3. On the left column, click the Anti-Virus protection category to expand it
  4. Click the Firewall item
  5. Click the Application Network rules… button to open the “Firewall” window
  6. Locate the “FILEZILLA PROJECT” folder (it should be under the “Trusted” folder) and click the plus (+) sign next to it to expand the folder
  7. Click on filezilla.exe
  8. On the lower split window, click the Additional… button to open the “Application control rules” window
  9. Click the Exclusions tab
  10. Check the box for “Do not inherit restrictions of the parent process (application)”
  11. Check the box for “Do not scan network traffic”
  12. Click OK on the “Application control rules” window
  13. Click OK on the “Firewall” window

You should be able to connect to the server with Filezilla now.

Of course, there are lots of other reasons why you may get an FTP error. If you do, we offer free (and excellent) technical support for our customers. You can always reach our Support team 24/7 at support@winhost.com or through our support portal at support.winhost.com.



New Rules for Domain Owner Information Updates Start Today

Starting today, December 1st, new ICANN rules are in effect that change the way some domain contact information changes are done. The change affects all generic top level domains, such as .com, .net, .org, .biz, .info, etc., (including all of the new domain extensions, like .blog, .photo, etc.). Country code domains (.uk, .TV, .co, etc.) are not affected.

When you change the first name, last name, email address or organization for the registrant (i.e., the domain name owner) you have to acknowledge the change in two separate emails. This applies to changes made to the registrant’s contact information. Changes to the admin, billing and technical contacts are not affected.

Changes to the registrant’s name, organization or email information are now treated the same way a “registrant change” was treated in the past. But in the past the registrant change was assumed to be a change of ownership from one person to another, so emailing both parties was necessary.

Now those emails are triggered any time you update your name or email address, and two emails will go to the same person. You need to approve the change by clicking the link in both emails, or the change will fail.

To avoid problems or delays

If you want to learn more about the new policy, check out this Knowledge Base article.