My 1 O 1 with TLS 1.2 security protocol and its migration.

We have recently worked on all our e-commerce sites to get them migrated to newer version TLS protocol that is TLS 1.2 (although TLS 1.3 has been released but it will take time to build strong supported eco-system for it).

Why this move was taken?

This move was taken due to below two main reasons.

1. Older version of SSL/TLS protocols are considered as vulnerable and are prone to the attacks.

2. PCI DSS had marked June 30^th, 2018 as the final deadline for the Older TLS protocol support and encouraged all the sites (Mainly falling into the e-com category or sites which does payment related data transactions) to get migrated to newer version of TLS protocol TLS 1.2.

Who were impacted with this deadline?

Site which does payment transactions online, payment gateways, sites which uses payment gateways. Other online sites are also having its impact from the vulnerability & Security perspective.

What? Why TLS?

To understand SSL/TLS protocols roles we first need to understand basic concept of websites request respond concept.

===

A user browses a site https://www.example.com from his browser and the site gets open in to his browser quickly. There actually a lot happens in the background.

In this communication user`s browser acting as a Client and https://www.example.com  `s server acting as a Server.

1. Client sends “Client Hello” message to the server, with list of supported TLS protocol and cipher suits.  – It is like client saying, “hey server, hello I want to talk to you, I guess you are the actual example server? I understand language of these TLS protocol versions and cipher suits”

2. Then server responds with the “Server Hello” message to client, which also contain TLS protocol version and cipher suit chosen by the server from the lint provided by client in previous step. Server also sends his digital certificate in response – It is like, Server responding “hey client hello, yes I am the example server, look at this certificate which proves it. I can talk to you, I have chosen this TLS protocol and this cipher suit from your provided list, which we will use as our language of conversation”

3. Client verifies the certificate, after successful verification client starts trusting the Server.

So now everything is set between Client and Server, trust has been established, both agreed to talk on common secret language (common TLS version and Cipher-suit), and importantly both have a lot to talk, hurray!!! 😊 seems like this couple are on their way to build a strong relationship.

Note: There were few more technical things which happens in background, which I have intentionally excluded from the above steps to make this writeup more towards practical than technical. I have refrained myself from screwing my head 😊 and prepared below flow to screw yours… Enjoy… 😊.

To summarize, client and server wanted to talk and share messages with each other that too secretly, they verified each other, they agreed to talk by using a common secret language (here secret language is a random encryption algorithm formed using TLS protocol, Cipher and Certificate keys)

Quick Fact: The TLS versions and ciphers which Client and server uses to encrypt message to form secure connections gets vulnerable with time and their new & more secure versions hits the market as a replacement. This gives birth to this kind of migrations.

===

Till now all this was a big picture for the TLS 1.2 migrations.

Now it’s time for me to put my little experience on paper regarding the TLS 1.2 migration of .net based sites on windows server platforms.

Although my first TLS 1.2 Migration took place in May 2016, for a Giant E-commerce site which was backed by 3 web nodes, 1 DB node and 2 other integration nodes. Also consider same setup for stage environment of the site. It was a great challenge and experience during those days.

Considering previous experience, I have been assigned for planning and implementation of the TLS migration task, all went good with planning and implementation with the help of nicely crafted support page of Microsoft here this linked blog has everything which will help you to get this task done. It also mentions few of the expected frequent issues and their remedy.

Here it is…

1. You will need supported OS version 2008 to 2016 all are now supported, of-course you will need to install some patches and releases to get it compatible – guess what? The link here will help you during entire migration keep this handy with you. 😊

2. You will also need supported version of MSSQL 2008 to 2016 all are supported, again patches and releases will play the role to get it compatible.

So now your OS and SQL is compatible with TLS 1.2, but you need to make it so that they should only talk on TLS 1.2 or they should preferably talk on TLS 1.2.

In most scenarios by default server and client will be having all the TLS protocol versions and ciphers enabled. Therefore, OS and other applications gets all of these TLS and ciphers list available to them to communicate. It means they may choose to have communication on a TLS protocol and Cipher which is vulnerable and involves security risk.

To deal with this problem, we need to have filter on TLS protocols and ciphers, so that OS and other applications only have secure TLS protocol versions & cipher as available choices and they should also support these secure TLS and ciphers.

3. This filtering can be done at OS registry or application level/code.

3.1 Filtering from OS registry

On OS level, it can be done by using a tool called IIS crypto or by editing the server registry keys.

3.1.1 IIS Crypto

IIS Crypto – Check here  (Comment if you want me to write details steps on using this tool)

3.1.2 By using server registry -

Here is the registry you need to work upon. To filter unwanted TLS versions and have only TLS 1.2 available to your server, you need to disable other protocols which can be done by editing registries under.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocol

You will find key folders for each of the security protocol, as shown below.

Each protocol will be containing 2 sub folders, 1 for server protocol and another one for client protocol. Then each of that sub-folder will be having 3 settings for which you need to set values to perform TLS protocol filtering. (Comment if you want me to write steps to perform this filtering)

Server protocol: These protocols comes into play when a client requests your server using a security protocol and your server need to communicate with responding to that request, the server chooses available server protocol to establish the communication, if we disable all the server protocols keeping only TLS 1.2 server protocol enable, then server can only respond with TLS 1.2 protocol and if the client doesn’t support TLS 1.2 the communication will be terminated forcefully by server.

Client protocol: These protocols comes into the play when in a communication your server is acting as a client (e.g. You are trying to browse a site from browser of server/ your server is initiating request call to external ERP server), if you disable all of the protocols except TLS 1.2 then your server can only make requests to the sites or 3^rd party integration which supports TLS 1.2, if they do not support it, this request will get terminated forcefully.

3.2 Filtering from application level/code

I do not have a core development background so I will not be that sure on this part but below information may help you to filter unwanted TLS protocols from application.

·  .NET 4.6 and above. It has support for TLS 1.2 and uses TLS 1.2 as default protocol, it also uses fall-back mechanism and negotiates on protocols whenever needed during the handshake.

· .NET 4.5. It supports TLS 1.2, but not use TLS 1.2 as its default protocols. I have observed that it doesn’t negotiate protocol that well as compare to .Net 4.6.1 – I have seen when our application was making an outbound call to ERP server which only supported TLS 1.0 where as our application was supporting only TLS 1.2, but as in this case our server should use client level protocol to make this outbound call, it seems somehow it was using TLS 1.2 only. As soon as we filtered server`s TLS client protocols to have TLS 1.0 client only these calls started working, but with this now our site was not getting accessed from server`s local browser itself. After reverting client TLS registry changes and installing .net 4.6.1 it all started working as expected.

The following code will make TLS 1.2 default for .Net4.5,

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

Also, it seems by using below you can make .Net4.5 to negotiate on TLS protocol as it gets negotiated in .Net4.6.1 and above.

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

·  .NET 4.0. It does not support TLS 1.2, but if you have .NET 4.5 (or above) installed on the server then you still can opt in for TLS 1.2 even if your application framework doesn’t support it.

Note: It is recommended to have .Net4.6.1 and above on each of the system which has any integration or which establishes any connection with server to server the site. E.g. DB server, ERP server. Etc.

Quick facts few from handshake basics and few from experience:

1. Suppose you have a server serving a .net based E-com site, on this server you have only TLS 1.2 server protocol enabled and only TLS 1.0 Client protocol enabled. In such scenario, the said e-com site can be accessed from outside of the world (From clients which supports TLS 1.2) but the server itself won’t be able to browse that site in its local browser as the local browser will attempt the connection request with client protocol TLS 1.0 and the site has only TLS 1.2 server protocol to respond.

2. As per my understanding, each of the server or client component has some default choice among the available TLS protocols and ciphers, and in some cases I have also observed that they do not even try to negotiate on TLS protocols or ciphers and communications gets denied.

3. When you disable TLS 1.0 on server, you won’t be able to RDP into that server from windows 7 machine as on server RDP works on TLS 1.0. you need to have some patches installed on you windows 7 or you will need to make changes to Server`s group policy.

This was from my experience, few things like SSL, symmetric and asymmetric concepts etc. are still needs to be edited in this post which I will surely do soon or will plan another linked post for the same. 

Thanks,

Stay Blessed!!!