/ HTTPS

Google Chrome to deprecate TLS 1.0/1.1

About a year back, Chrome announced that they plan to drop all support for TLS 1.0 and 1.1 in their web browser starting with chrome build 81 which is due in 2020, the current production build of chrome is build 77 with build 78 due in a couple of weeks and build 79 due in December of this year. This announcement has recently gained some attention as there are still quite a few sites out there that for some reason do not use TLS 1.2 even though it has been available for quite some time.

With the sort of release rate that Goolge Chrome has I expect build 81 to drop sometime around February of 2020 which gives website owners about 5 months to move sites to TLS 1.2

Now, the actual process of moving a website to TLS 1.2 should not be that difficult, in most web servers it is a single line that you put into the config to enable it and then restart the web server. I plan on doing a few blogs on how to enable TLS 1.2 and better yet, 1.3 over the next few months, if there is a particular webserver you would like me to provide instructions on please post a comment below.

In the meantime, how can you tell what version of TLS you are using? Fortunatley, it is quite easy to do. All you need is access to openssl on a linux box or you can install the linux subsystem for windows and use that. For this demonstration I will be using the linux subsystem for Windows.

The version of openssl bundled with unbuntu included with the linux subsystem for windows is 1.1.0g which does not support testing for TLS 1.3 which is a huge shame but not a serious issue for this test as at this point I am only interested in TLS 1.0, 1.1 and 1.2

To test a site, all you need to do is run this command:

echo "q" | openssl s_client -connect [site]:443 -servername [site] [tls version]

So, if you want to test this site for TLS 1.0 the command is

echo "q" | openssl s_client -connect blog.gdwnet.com:443 -servername blog.gdwnet.com -tls1

First of all, what does the command do?

Well, the first part just sends a "q" into the second command, the reason is that if I do not do that, the openssl command will not return to the command prompt until it times out with no input so I always echo "q" into the openssl command. If I did not, I would forget when writing scripts and spend ages puzzling it out!

The next part is the interesting bit, here I use openssl to open a connection to a site on a server - the reason the site is listed twice is because of SNI - the Server Name Indication. It is quite possible to have several thouand websites hosted on a single server, personally I always use the domain name I am interestd in for both sections - there is no reason that this should not work, if it did not then the website would not have a valid cert anyway and the whole thing would be rather moot.

For TLS 1.0 against my site, the result is

1-1

This is a failure, openssl has been unable to connect to the server using TLSv1. In any scripts I use to automate this, I always look for the line "Secure Rengotiation is not supported" to determine if a site does support that TLS protocol or not.

Lets try again with TLS 1.2 - In this case the command is:

echo "q" | openssl s_client -connect blog.gdwnet.com:443 -servername blog.gdwnet.com -tls1_2

2-1

I have truncated the output as it does go on a bit but this time it has been successful, I can see that TLS 1.2 is enabled because openssl pulls back details of the server and the public part of the cert itself.

From this, I can tell that my site will be fine because TLS v1.2 is supported and working.

Sadly, there are a lot of sites out there that do not have TLS 1.2 enabled, currently I am tracking 93,059 domains that currently have either TLS 1.0 or 1.1 enabled but not TLS 1.2 - I do expect this go down quite rapidly and I will publish a list of sites soon.

Gary Williams

Gary Williams

IT Person | Veeam Vanguard | VMware vExpert | Windows admin | Docker fan | Spiceworks moderator | keeper of 3 cats | Avid Tea fan

Read More