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:
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:
and scroll down to the section about creating the TLS12-Enable.reg file:
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.
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.
