Upcoming TLS changes


Wednesday, June 27th, 2018 - General

Post Summary

If you do not want to read through this whole blog post, just understand that there are issues with older versions of TLS. If you have been sent to this post by our support staff, then this probably means you have a program or operating system that is still using these older versions of TLS. You need to make changes to your system to bring it in line with upcoming security standards. If you choose to ignore that, then you should anticipate experiencing issues later on when older versions of TLS are completely shut off.

This post is detailing what you need to do. If you are using Windows 7 there is information in this post that might help you. I know this is a lengthy post, but there is a lot of information included.

If you are using an old, outdated, and end-of-life email client, program, or operating system, then you really can’t expect it to be secure. This is just the way the Internet works.

SSL/TLS is a technology that is used to encrypt data transmission from a source to a destination. For example, from your web browser to a web server. Or from your email client to the mail server. This is what prevents someone from listening in on the connection and being able to understand what is being transmitted (like passwords or personal information).

A small back story regarding the naming convention of SSL and TLS. When public/private key transmission encryption was first developed, it was called SSL. There got to be a copyright issue regarding the name SSL, so the IETF organization (a standards controlling group on the Internet) decided to change the name from SSL to TLS. But SSL was, and still is, a hard name to shake off. So officially the name is actually TLS, but it’s often used interchangeably with SSL.

What is SSL/TLS?
TLS or Transport Layer Security is a protocol that is used to negotiate how two parties will communicate in secret. TLS uses a public/private keypair set of encryption. Basically it’s set up to where the source has a private key that it uses to encrypt data. In order for a destination to understand what is written in that encrypted data, it needs a public key to decrypt the data. The public key cannot be used to encrypt data, and likewise the private key can’t be used to decrypt data. During this negotiation process, the source (i.e. your browser or email client) is going to send the destination server (i.e. our web server or email server) a public key that it can use to decrypt what the source is sending. Likewise, the destination server is going to send it’s public key back to the source server so it can decrypt what the destination server sends back.

What is changing?
Without getting to in-depth on this, just understand that there are different versions of SSL/TLS that are used in this negotiation. There are 5 different versions of SSL/TLS. SSLv2 and SSLv3 were created way back in the 1990s, they were long ago deprecated and deemed insecure (this is also where the naming convention copyrights came into play) so we won’t discuss those.

TLSv1, TLSv1.1, and TLSv1.2 are the remaining TLS versions. As you can guess, vulnerabilities were later discovered in TLSv1 and TLSv1.1. These vulnerabilities essentially nullified and security gains in using these two versions of the TLS protocol. But, unfortunately, adoption of TLSv1.2 was very, very slow so support for TLSv1 and TLSv1.1 had to linger for a very long time.

But the time has now come to officially drop TLSv1 and TLSv1.1 and rely solely on TLSv1.2. This is because the Internet industries want to promote a safe and secure Internet, and that can’t happen if insecure protocols are allowed to be used.

Why is this changing?
You really have to consider the Internet as a living and breathing beast. The Internet is not something you can turn off. You can’t check your email if you don’t have an Internet connection. You can’t check Facebook if you don’t have an Internet connection. Way back when, when computers were not used so much as a communication device and before the Internet, security issues were less of an issue. In order to hack into a computer or device, you really had to have physical access to the computer or machine. If your home PC wasn’t on the Internet, or on an always-on Internet connection, security threats from the Internet weren’t really an issue for you.

But now the Internet exists, and millions and billions of different devices are connected to the Internet all the time. As a result security of these devices becomes a bigger issue. As new security holes and vulnerabilities are discovered, no longer can these just be ignored because physical access is no longer required to exploit these vulnerabilities. These devices are constantly connected to the Internet and are therefore constantly a target of these vulnerabilities.

When the security holes were discovered in the TLSv1 and TLSv1.1 security experts knew that this would affect a lot of users. Unfortunately, developers – such as Microsoft – were slow to roll out security updates and end-user adoption of these new security updates was even slower. This meant that Internet hosting companies and Internet service providers had to continue to allow connections using these insecure versions of TLS due to usability concerns.

It’s important to note that security and usability and opposite ends of the same string. Any time you add a bit of security you take away a bit of usability. Consider that if you really want to keep your computer secure, the best advice is to turn it off. That will definitely keep it secure, but you can’t use it, there’s zero usability. The struggle that server administrators, security experts, and the Internet industries as a whole have is balancing out this security vs. usability equation. How can we make the Internet more secure while also keeping it usable? Where is that balancing act?

This is what lead to the prolonged service of TLSv1 and TLSv1.1. A lot of users were still relying on these versions, and even though security experts knew they were insecure – they could not recommend removing them because it would affect a lot of users.

Now the time has come that the PCI Security Council (one of those industry leaders in being Internet security experts) has concluded that enough time has passed for developers and users to switch to the secure TLSv1.2 protocol, so TLSv1 and TLSv1.1 can be disabled. And while, the vast majority of our users are using TLSv1.2 compatible email clients, operating systems, and programs, there are still quite a few that have not yet updated and will be affected by this shutdown of TLSv1 and TLSv1.1.

Again, this security vs. usability thing comes into play. At what point is the overall health and security of a server more important than the usability concerns of a few clients? If a server has 1000 users on it and 900 of them are using TLSv1.2 but 100 are still relying on TLSv1 or TLSv1.1, how is it justified for the 1000 users to suffer through an insecurity just to protect those 100 that have not updated? Or where does that justification point lay? What if it’s 920 vs 80? Or 950 vs 50? The later is what we are seeing. We are seeing about a 96% adoption of TLSv1.2, so given this information we feel that it is best to go ahead and disable the insecure TLSv1 and TLSv1.1 protocols so that all of our users can benefit from better security on our servers. But this also means that about 4% of our users are going to experience problems. Is that a justifiable percentage?

I got a message saying that I would be affected by this, what do I need to do?
If you get a message saying you are affected by this shut down of TLSv1 and TLS1.1, then that means we detected someone using your account to check or send out mail using TLSv1 or TLSv1.1. This TYPICALLY means that you are using and out of date and end-of-life email client. Examples known to be affected include Outlook 2007, Outlook 2013, Windows Live Mail. Some operating systems are also affected. Anything before Windows 7 will likely have issues (and everything before Windows 7 is end-of-life anyway). I believe versions of MacOS before High Sierra might have issues. Linux distributions that are still in-life should not have any issues. Older versions of Android or iOS may experience issues. There’s really just too many factors to know for us to give a detailed list of what will experience issues.

You just need to find and identify what email program or operating system you are using and make sure it is up to date, and that it is still in-life and being actively supported.

To search for Microsoft based products to see if they are still in life, you can visit:

https://support.microsoft.com/en-us/lifecycle/search

and search for your specific email client and version.

If you are using Windows 7 and you are using a still supported version of Outlook, you might find the patch information at:

https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-a-default-secure-protocols-in

to be useful for you. As I understand it, Windows 7 did not ship with native TLSv1.2 support was added later on in this patch. Your Microsoft update may have already applied this patch years ago or you may need to manually install it now. I really do not know why some people do not already have this patch.

Additionally, it would appear that simply installing this patch is not enough, you have to edit your registry in Windows 7. You can find instructions for this at:

https://blogs.technet.microsoft.com/exchange/2018/04/02/exchange-server-tls-guidance-part-2-enabling-tls-1-2-and-identifying-clients-not-using-it

and scroll down to the section about creating the TLS12-Enable.reg file:

tls12.reg image

You will need to manually create this file and run this file on your system. (Don’t ask me why Microsoft did not include this in the patch, direct those questions and frustrations to Microsoft)

We have created this TLS12-Enable.reg file for you. You can download this file and run it on your system. Although from a security standpoint, randomly downloading .reg files and running them from sites on the Internet is generally frowned upon. It’s best if you can follow the instructions Microsoft’s TechNet page.

If you are using an end-of-life email client, then you really need to update to a newer email client. Again, you have to consider the Internet as a living and breathing beast, so you can’t expect old technologies – technologies that are no longer being maintained – to always be secure. And again, we are showing a 96% adoption rate for TLSv1.2. If you are still using clients and operating systems that don’t support TLSv1.2, then you are part of a much smaller percentage of our user base.

Outlook 2007 is end of life

If you really cannot change your email program, then you should consider switching to insecure connections for sending and checking mail. Insecure connections really aren’t recommended, but sadly if you are not going to update your email client to a secure email client, then security is not a top priority for you. Remember, usability vs. security.

I have updated my email client, how can I know if I’m using TLSv1.2 now?
If you’ve updated your email client and you want to be sure that you are using TLSv1.2 now, simply check your email account or send out a message, then contact us and we will check the logs to make sure you are using a TLSv1.2 connection. If you are, that’s great! If you are not, then you will need to make additional changes to your setup.

How do I know the specific accounts that are still using TLSv1 and TLSv1.1?
All we can see is the usernames that are connecting using TLSv1 and TLSv1.1 secure connections. You can contact us, and we can send you a list of those usernames on your account. But we really have no idea what computers or devices are being used to make those connections. This may be extremely problematic if a specific user is checking their email on 20 different devices, it may only be 1 of those 20 devices that is using TLSv1 or TLSv1.1, but we have no way of seeing that.

When will you be shutting off TLSv1 and TLSv1.1?
We would like to be able to shutdown TLSv1 and TLSv1.1 support by the end of July 2018. But I really don’t know how feasible that will be. Again, we are seeing just a small percentage of users that have not yet updated to TLSv1.2 compatible clients – so while we want to give those users the opportunity to update their software, it’s also not fair to most of our other users that have already updated to TLSv1.2 to have to wait a pro-longed period for these users to update.

Is email the only thing that will be affected by this?
Email won’t necessarily be the only thing affected by this TLSv1 and TLS1.1 shut down. Web, FTP, and cPanel/Webmail access may also be affected by this. Unfortunately it’s not as easy to detect TLS versions with these services. If you are affected by this with email, then you should consider what the underlying root cause of why you are affected by this to help determine if web and other services will also be affected. For example, if you are still using Windows XP and are affected by this, then you will probably be affected by this in regards to web and other services. This is because Windows XP does not support TLSv1.2. But it’s also worth noting that Windows XP is severely end-of-life.

Again, the intent behind all of this is to make the Internet more secure. There is a big push to make increase the overall security of the Internet. And this can’t happen if insecure protocols are allowed to continue to run. The past has taught us (the Internet industries) that you sometimes have to disable insecure protocols in order to force movement to better and secure protocols. It would definitely be nice if we never had to change anything. But as long as there are hackers, malicious users, and poorly written code there will always be security updates that have to be followed.


Email client SSL/TLS issues


Tuesday, June 12th, 2018 - General

Update – June 21, 2018

We have decided to revert these changes back to their original setting for the time being. We still believe that disabling TLSv1 and TLSv1.1 on the servers was the right move, but it has become obvious to us that there are still quite a few users still using very old and incompatible software. And there are major players on the Internet that still haven’t moved on to TLSv1.2.

It’s worth pointing out that the PCI security council recommended that everyone move to TLSv1.2 by June 30th, 2018:

https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls

But sadly, due to the constraints that the rest of the Internet is not ready to move forward on this, we will not meet this June 30th deadline. From a security standpoint, this is very unfortunate. We believe the move to TLSv1.2 needs to happen as soon as possible, and we actually agree with the PCI security council on this. But we are seeing no movement from major Internet companies or the adoption of newer and more secure email clients to warrant such a change at this time. This means after June 30th, our servers will no longer be PCI compliant.

The disconcerting part about all of this is that there are some major players – including Facebook, AOL, and even PayPal – that have not yet moved their mail servers over to TLSv1.2. This is shocking to us. These are companies that we – and every other Internet user – trust with our information and they seem to either be unaware or unconcerned about the security of their servers.

What now?
We are trying to come up with a plan now, where we will notify you if your account is found to be using non TLSv1.2 email clients. If you get one of these messages, then that means you need to update your email client. Look for these messages to be sent out some time next week. We then would have plans to schedule the removal of early and insecure TLS versions late next month or sometime after that.

It’s really been mostly a shock to us at the lack of TLSv1.2 adoption. We did not anticipate this level of issues with this move. But we hope that by educating our users we can resolve this and increase the overall security of our servers at the same time.

Update – June 14, 2018

So what’s the bottom line?

If you have been sent to this post or if you are otherwise affected by this then this statement rings true:

You are using an email client or operating system that does not support valid security protocols.

Perhaps this can be fixed, perhaps not. We’re really not going to know. There are just too many email clients out there for us to have knowledge about what settings are where and what patches may or may not need to be applied. It’s best to contact the developer or vendor of the product you are using.

But chances are, if you are having problems with this, then the product you are using has reached it’s end-of-life and that may have occurred several years ago. Up until this latest server update, secure connections using TLSv1 were still being allowed. But it’s important to note that TLSv1 connections were never secure to begin with. That is why they have been disabled. To raise awareness that the client and operating system you have been using is not secure.

The Internet is always on, always available – which means it has to be secure. This means things have to change in order for it remain secure. When security vulnerabilities are discovered in Internet protocols, you can’t expect a secure Internet to continue to use those protocols. This is what has happened here. Vulnerabilities in TLSv1 have been known about for some time, but the Internet industries were giving people time to migrate to knew clients, programs, and protocols before completely shutting down TLSv1. The shut down of TLSv1 is beginning now.

Update – June 13, 2018

If you are having issues with this and you are using one of Microsoft’s Outlook products on Windows 7, then you might try applying this patch:

https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-a-default-secure-protocols-in

Some have made progress by utilizing this patch to update their Outlook to allow for modern and updated versions of TLS. But if you are depending on an outdated or discontinued version of Outlook, this patch probably won’t help you.

Original Post

An upcoming change to our servers will affect some older email clients (potentially older browsers as well).

Changes to the way security is run on the servers is going to change the available ciphers and only allow for TLS version 1.2. The aim here is to provide better security throughout the Internet. Known issues with TLS versions 1.0 and 1.1 essentially make them insecure.

Most users won’t notice this change. If you are using a modern email client, browser, and operating system then it’s probably already using TLS 1.2, and if not, it will switch to it when other insecure TLS versions are unavailable.

But if you are using an older email client, such as Outlook 2007 or Windows Live Mail (plus many others – too many to list), you will likely be affected by this. It is important to note that both Outlook 2007 and Windows Live Mail are end of life. That means they are no longer supported by their developer any more. And anything that is end of life, you really shouldn’t be using any more. You can’t expect end of life’d software to continue to be updated and work in modern system. It just doesn’t work that way.

So if you encounter an issue checking or sending out mail – consider the email client that you are using and if it is up to date and being kept up to date. If it’s end of life, then you really need to switch to a modern email client and/or operating system.

This will only affect you if you use one of these email client AND use secure mail settings. You can continue to use your old email client, you just can’t use secure settings – but we don’t recommend doing that. The best solution is to update to a modern email client or operating system.

We recommend Thunderbird, although any modern email client should be sufficient:

https://www.thunderbird.net

Additionally, you can use webmail to log into your email accounts. Simply point your browser to:

http://yourdomain.com/webmail

Enter the email address you want to check as the username and the password is that email account’s corresponding password. (Replace yourdomain.com with your actual domain name you have hosted with us).

All of this is being done with an object of making the Internet more secure. The Internet cannot be secure if insecure protocols and system are allowed to continue to operate. All of those insecurities will eventually be phased out.


WordPress comment spam


Monday, May 14th, 2018 - General

We are starting to see a lot of WordPress comment spam being sent out through a lot of the accounts hosted on our servers. A lot of users have comment moderation enabled for their WordPress site, perhaps unknowingly. When a comment is posted by someone and the moderation bit is set, then that comment is emailed to the WordPress site administrator for them to take action.

Recently Google and Gmail have started flagging these comment moderation messages as spam. Unfortunately this can have the affect of Gmail blacklisting or weighing all messages sent from our servers as spam. Since we cannot allow this to happen, we are going to be forced to take action regarding this.

We will have to start putting websites into a read-only state if this continues. A read-only state means that nobody will be able to post any comments to your site and you will not be able to log into the WordPress dashboard on your account. Your website will still appear to any visitors, but you just won’t be able to take any actions on your website.

What can you do to prevent this?

If you are not using comments, I would recommend that you disable them. You can do that by logging into your WordPress admin dashboard and clicking Settings -> Discussion then make sure the option for Allow people to post comments on new articles is unchecked. However, if you have specifically enabled comments on any specific posts, comments will still be enabled for that post.

If you are using comments, I would highly recommend that you install some type of captcha system to prevent bots from posting comments on your site. The Google Captcha might be a good plugin to use.

We are doing all of this in an effort to stay proactive and insure that the hosting system your website is hosted on remains clean. We cannot allow comment abuse to affect the reputation of our servers.


My account was caught sending out spam


Monday, March 5th, 2018 - General

Have you received an email from us stating that your account has been used for spamming? That message may have looked like:

A routine security check on the server found that your account – youraccount.com – was being used to send out spam through the server.

Someone is using SMTP authentication with the account – email@youraccount.com – to relay out questionable mail through the server.

What does this message mean?

This means that someone (probably not you, right?) has logged into the server using the email@youraccount.com account information to send out spam. We are assuming that this person wasn’t really you (otherwise, you’d be the spammer and we’re going to err on the side that it wasn’t really you) so this means that spammers somehow got their hands on the password for email@youraccount.com.

This means you likely have an information leak some where. Information, such as the password to this email account (and potentially other information that may not be affecting your web hosting account with us) is being leaked out. If you don’t stop the source of that leak, then information will continue to leak out.

How did they get their hands on the password for email@youraccount.com? We don’t know. And by that we mean that we really don’t know – we haven’t been looking over your shoulder every where you have used this account or what type of password you are using.

One question we often get asked regarding these incidents is: Why didn’t you just block the IP address of the individual sending out the spam? Well, the issue isn’t necessarily WHO is sending out the spam. The issue is that your information was compromised. The IP address isn’t the common point of entry. Often times the spammers are connecting from 100s of different IP addresses, and even if we did block those IPs, they’d just connect from others. The common point of entry is the compromised email account. That is why the password to the email account has to be changed and why IP addresses are not directly blocked.

Typically hackers and spammers get your password information by one of three different ways:

• Malware, viruses, or keyloggers. Your computer or device may be infected with something that is leaking out your password information. If you have malware or a keylogger on your computer (or mobile phone, tablet, or other device) then that malware can be transmitting your password information for all of the accounts you access back to hackers and spammers. This is also how identity theft usually starts. To resolve this, you need to identify which computer or device is checking this account and which computer or device has the malware and keylogger on it, and remove the malware or keylogger. Then you need to change the password for your email account and any other account for any other business you may have logged into on this device.

• Insecure network or network probing. If you check your mail or use your computer, phone, or tablet on any public wifi or insecure network, then you are potentially leaving your data vulnerable to hacking from others on that network. Someone else sharing that public wifi hotspot may be listening in on your connection and stealing password information as you transmit it. To resolve this, you need to identify what sources of insecure networks or wifi that you are using and either secure them or stop using them and then change your email account password and any other account for any other account for any other business you may have logged into on these networks.

• Using weak and insecure passwords. We covered this a bit in detail in a previous post. Bottom line, you are responsible for choosing strong and secure passwords for your accounts. If you are using simple and easy to guess passwords for your account – then you should expect to be compromised – and you need to accept some responsibility for having your account hacked, compromised, and used to send out spam. To resolve this, you need to choose strong and secure passwords for all of your accounts.

These are just some of the scenarios that can explain how your password was compromised. It is not a conclusive list.

The bottom line is – we detected spam being sent out from your account. We are assuming that it is not you sending out the spam, so we draw the conclusion that your password has been compromised. We do not know how the password was compromised, nor can we know how the password was compromised. But you need to figure out how the password was compromised and then resolve whatever the situation was that allowed the password to be compromised. Doing nothing means that your account will probably just get compromised again and we may have to suspend your account if that happens.


PHP 7.1 broke my website


Wednesday, February 21st, 2018 - General

We are continuing to slowly push out PHP 7.1 by default on all of our servers (see this post). Some users are experiencing issues with this upgrade.

First of all, I want to point out that PHP 7.1 was released on December 1, 2016 (see the table directly from php.net). That was nearly 15 months ago. So to claim that PHP 7.1 is brand new, is false. It has been around for quite some time and anyone that develops or writes applications in PHP should be aware of this.

Second, we are seeing some rather significant performance gains with PHP 7.1. So it would be to your benefit to insure that your website and scripts can take advantage of PHP 7.1 so that your website can experience the performance gains.

If you are having problems after the server has been upgraded to PHP 7.1, then you fall into one of two categories:

1. You are using an outdated script (or addons/component/extension/plugin/theme/etc) on your website. Keeping your scripts (or addons/component/extension/plugin/theme/etc) up to date is important to insure that your website is patched up from any known security holes. When developers of these scripts or addons find a security hole in their code they will typically fix this and patch it up and release an updated version of the script. But if you are not using that updated version then you are not protected against that security hole. That means that if you have Example CMS version 1.0 installed on your website and a privilege escalation bug is found in Example CMS version 1.0, the developer of Example CMS fixes the security hole and releases Example CMS version 1.1 to fix it, then if you continue to use Example CMS version 1.0 you are still vulnerable to this privilege escalation bug.

Additionally developers release updated versions of their scripts to take advantage of newer technologies. Software goes end of life - we explained some of the end-of-life reasons back in this post from 2013 - and developers have to stay in step with what is current. PHP 5.6 included a lot of functions and methods that were slow, those functions and methods have been completely replaced in PHP 7.1. Developers of scripts and web applications have to be aware of this and change their code accordingly.


2. You are using an abandoned script (or addons/component/extension/plugin/theme/etc) on your website. Keeping your scripts (or addons/component/extension/plugin/theme/etc) up to date is important. But just as important is making sure that you are using reputable scripts (or addons/component/extension/plugin/theme/etc). This is probably a bit more common with script addons rather than core scripts themselves. If the developer of a script or script addon is not going to properly maintain the code in that scripts then it is of no use to you. Sure, you may be using the latest version of Example Script Addon, but if the last version of Example Script Addon was released 5 years ago, then it is not being properly maintained and the developer likely abandoned the project. We see this happening a lot.

Think of all of the security holes that may have been found in Example Script Addon in those 5 years. Those security holes are not being patched. Think of all of the poor coding that exists in that addon. That coding is not being fixed.

So if you are experiencing problems with the PHP 7.1 upgrade and all of your scripts (and addons/component/extension/plugin/theme/etc) are up to date, then you are very likely using an abandoned script or script addon and the developer is no longer concerning themselves with it. You should stop using that script or script addon.

If you continue to have issues with PHP 7.1 we can switch you back to PHP 5.6, but please understand that this is only a temporary fix. PHP 5.6 support is not going to be around forever. If your the script or script addon you are using on your website is not working with PHP 7.1 then the issue is with the script - it fits into one of the two categories from above. You need to be making arrangements to have the script or script addon updated or switched to support PHP 7.1 so that you will not be caught off guard when PHP 5.6 support is completely removed.

One of the reasons why we are doing this upgrade now is so users can identify if they fall into one of the above categories and can make arrangements to resolve those issues before PHP 5.6 support is completely lost.