Secure Socket Layer (SSL) and its successor Transport Layer Security (TLS) are protocols which use cryptographic algorithms to secure the communication between 2 entities. It is just a secure layer running on top of HTTP.

SSL HandshakeProtocol

SSL ChangeCipher SpecProtocol

SSL AlertProtocol

HTTP

SSL Record Protocol

TCP

IP

Overview of SSL Protocol Stack

Several versions of SSL have been released after its advent in 1995 (SSL 2.0 by Netscape communications, SSL 1.0 was never released). Here is the list:

SSL 1.0, 2.0 and 3.0

TLS 1.0 (or SSL 3.1, released in 1999)

TLS 1.1 (or SSL 3.2, released in 2006)

TLS 1.2 (or SSL 3.3, released in 2008)

SSL was changed to TLS when it was handed over to IETF for standardizing the security protocol layer in 1999. After making few changes to SSL 3.0, IETF released TLS 1.0. TLS 1.0 is being used by several web servers and browsers till date. What I have never understood, is there have been newer versions released after this, with the latest being TLS 1.2 released in 2008.

On Windows the support for SSL/TLS protocols is tied to the SCHANNEL component. So, if a specific OS version doesn’t support a SSL/TLS version, this means it remains unsupported.

All the windows components/applications abide by this rule and can support only those protocols which are supported at the OS level. For e.g.: IIS and Internet Explorer.

Below table should give you a good understanding of what protocols are supported on Windows OS.

Windows OS Version

SSL 2.0

SSL 3.0

TLS 1.0

TLS 1.1

TLS 1.2

Windows XP & Windows Server 2003

✓

✓

✓

X

X

Windows Vista & Windows Server 2008

✓

✓

✓

✓

✓

Windows 7 & Windows Server 2008 R2

✓

✓

✓

✓

✓

Windows 8 & Windows Server 2012

✓

✓

✓

✓

✓

Windows 8.1 & Windows Server 2012 R2

✓

✓

✓

✓

✓

Windows 10 & Windows Server 2016

✓

✓

✓

✓

✓

TLS 1.1 & TLS 1.2 are enabled by default on post Windows 8.1 releases. Prior to that they were disabled by default. So the administrators have to enable the settings manually via the registry. Refer this article on how to enable this protocols via registry: https://support.Microsoft.com/en-us/kb/187498

On the client side, you can check this in the browser settings. If you are using IE on any of the supported Windows OS listed above, then in IE, browse to Tools ->Internet Options ->Advanced. Under the Security section, you would see the list of SSL protocols supported by IE. IE supports only those security protocol versions, which is supported by the underlying SCHANNEL component of the OS.

TLS settings in IE on Windows 10

Chrome supports whatever IE supports. If you intend to check the support in Firefox, then enter the text "about:config" in the browser address bar and then enter TLS in the search bar as shown below.

TLS Settings on Firefox v47

The settings security.tls.version.max specifies the maximum supported protocol version and security.tls.version.min specifies the minimum supported protocol version . They can take any of the below 4 values:

0 - SSL 3.0

1 - TLS 1.0 (This is the current default for the minimum required version.)

2- TLS 1.1

3 - TLS 1.2 (This is the current default for the maximum supported version.)

NOTE: The behavior is undefined if security.tls.version.min is larger than the security.tls.version.max value.

To enable the use of the protocols that will not be negotiated by default (such as TLS 1.1 or TLS 1.2), change the DWORD value data of the DisabledByDefault value to 0x0 in each of the following registry keys under the Protocols key:•SCHANNELProtocolsTLS 1.1Client

@Ray – Well the reason is that not many existing client browsers don't support TLS 1.1 and later. Even though they are the latest versions of TLS, the problem has been with the adoption of these versions. If they are enabled, there will be additional time spent in re-negotiating these parameters with the server or client. Hence they are always kept disabled.

I have a case where the Win7 clients' SSL3 and TLS1.0 box is checked on IE8. When they try and connect to a Win2008R2 instance of IIS7.5 it refuses to go secure. If the client additionally checks the SSL2.0 checkbox, then the client goes secure with the server. How can that be? The server is default config, so SSL2.0 is turned off by default.

I am not sure why it was not added as it would have been really great to add support for latest TLS versions. The only problem I see was the major over-hauling required as the support for SSL is inbuilt into Windows. However you could provide your feedback here: http://wfp.microsoft.com/

Please read carefully the instructions on how to fix this. This will affect certain functionality. You may also consider posting this problem on Windows Security Forums to get a quicker and better response: social.technet.microsoft.com/…/home

hi Kumar, how if i enabling the TLS on Windows Server 2008 R2, is any error in the communication, whereas i enabling both SSL and TLS on IIS Service. can you explain a little bit how SSL and TLS work in encryption before 3-way TCP hanshake key. many thanks and this is a good topic.

A client has had a security assessment conducted of the web servers in their environment. They want the servers to be configured to disable SSL version 2, and to only accept SSL ciphers greater than, or equal to, 128 bits. The web servers in the environment consist of Apache 2.2 on Red Hat Enterprise Linux 6, IIS 6 on Windows Server 2003, and IIS 7.5 on Windows Server 2008 R2. Please answer the following questions:

1. How do you test the servers to determine which SSL versions and ciphers are

currently supported / accepted? Please describe the process.

2. What changes are needed for each of the web servers / operating systems to meet the client's requirements? Please be specific.

what happens if you create tls 1.0, 1.1 and 1.2 keys in gpo for a mix win2k3, win2k8, win2k8r2, win2k12 environment? the keys for 1.1 and 1.2 would not enable features unsupported on win2k3, however would this cause issues if those keys now existed for gpo or is there a better method similar to enabling IE tls via gpo? (for server/apps/programs like iis)

I have a question. With PCI standards dictating now that TLSv1 needs to be disabled on web servers in order to be compliant. Yet many users are still sitting on IE 8-10 which has support for TLSv1.1 and 1.2 disabled by default. Many users simply won't be able to use these PCI compliant sites.

It has nothing to do with IE. IE supports whatever the underlying OS supports.

Until Windows Server 2012 R2/Windows 8.1 TLS 1.1/1.2 was disabled by default. It is debatable to say whether to enable it or not. However a simple solution is that we can have the registry key switched to enable the support for these protocols.

As I said it depends on the underlying Operating System for most of the Microsoft products. IE supports, whatever the underlying OS supports. IE 8 on windows XP supports only TLS 1.0 as XP has no support for the later versions of TLS.

The component is called SCHANNEL. We have either Client & Server specific registry keys.

We need to understand why this decision was made. When IE came out with support for TLS 1.1 and TLS 1.2, it was the only browser which supported these protocols.

As you mentioned most of the web servers run on Apache and they didn't support these protocols until 2010/2011 I believe. When Windows 8.1 was launched IT industry was slowly shifting to newer versions. FINALLY IT HAPPENED.

So the decision was made to be keep it as disabled by default. Chrome and other major browsers started support for it around the same time (2011).

Instead of waiting for a patch its a simple setting that can be enforced. One can write a script or if the machines are part of a domain, then push it via Group Policy.

"Ensure the browser you are using to communicate has TLS 1.2 enabled as well."

My point exactly. When every PCI compliant web server switches over to TLSv1.2 in June of next year the entire web will be filled with people running IE 8-10 saying the same thing. It's ridiculous. Only IE 8-10 has support for that protocol off by default. And it's doubly ridiculous that it is still that way if IE had support for those protocols before the other browsers.

I might add as well that while IE 8-10 only use TLSv1 by default that it is a broken protocol and not secure at all anymore.

So, we just went under a Scan and now it's complaining that we need to disable TLS 1.0. That throws a couple of quick wrenches. 1st, the back end app talks over TLS 1.0 to SQL Server so we need to keep the client side enabled. Second, if I disable the server side, I can't RDP into the server. I can use weaker RDP encryption, but that's not good either. How are we getting past this aging TLS v1.0? On top of that, there are still a lot of browsers that can't use 1.1 or 1.2. I'm more concerned about RDP. Oh, and I do NOT use RDP over the internet, VPN tunnel only, so I'm guessing you'll say it's ok to use the weaker encryption.

@Kevin. Every single browser currently supports TLS 1.1 & 1.2. The ones that don't support them are IE running on Windows XP/Windows server 2003. The Reason being both the OS don't have native support for TLS 1.1 & TLS 1.2.

If you are using Windows Vista o higher, you shouldn't have any issues. At some point you need to make the transition, it is better you do it now than at a later stage.

I'm not an RDP expert, but check if the RDP client supports TLS 1.1/1.2.

Hi, i'm tying to make a secure connection from a .net 4.5 context with WebRequest over TLS 1.1 / 1.2 for Windows Server 2008 sp2. All goes fine when i run the application from windows 8/8.1 host, but on Windows Server 2008 is fails with: "The underlying connection was closed: An unexpected error occurred on a send." I believe it is due to "Now let’s come to the point, on Windows the support for SSL/TLS protocols is tied to the SCHANNEL component" and "All the windows components/applications abide by this rule and can support only those protocols which are supported at the OS level." If this is true for .net 4.5, could you point me to a reference document confirming the implementation?

Hello, I am trying to make some changes to pass the PCI Compliance Scan. For starters, I was able to disable TLS 1.0 on the Exchange server but now many users outside of the network are having trouble connecting to the server via Outlook, would you happen to know what would be the best way to get them to connect?

Also, I am running a terminal server on Windows Server 2008 (not R2) and I see on the top of the page that the server does not support TLS 1.1 and 1.2. Is there a way around that? I am failing because of TLS 1.0 being enabled.

i am currently running windows vista and internet explorer 9, and cannot see support for tls 1.1 or tls 1.2 when i go control panel-advanced internet options. what gives? would like to keep current os and browser. you said vist or higher should have no problems.

In your response of the 8th May, you say "If you are using Windows Vista o higher, you shouldn't have any issues." but the table above says that Vista doesn't support TLS1.1/1.2. Can you say which is correct? (Ron's message of the 22nd suggests the table is correct).

This is a good but very old article. Since some people are still commenting on this article it is worth mentioning a few things. Some things are no longer true. For example all major browsers such as Chrome and Firefox have had support for TLS1.1 and TLS 1.2 for quite some time now.

@Kaushal, when you enable TLS1.1 and TLS1.2 in Schannel through the registry, it is not automatically also enabled in IE settings. While it is true that IE is dependent on whatever your version of Schannel.dll supports, these are two separate settings.

For viewing/changing settings on Microsoft servers without editing the registry manually you can use the free tool IISCrypto that makes the necessary registry settings for you. When disabling older protocols on the server side, such as SSL2.0, SSL3.0 please be aware that many older devices may not support TLS, for example Windows XP, older versions of android and windows mobile etc.

I find it quite shocking that if I set up the browsers on my windows 8.1 client to insist on secure connections (ie no support – not even fall-back – for RC4, and no support for anything earlier than TLS1.2, I can no longer access the MSDN website. That doesn't much matter for pages like this one, but it's a bit of an issue for, for example, downloads.

Its really a good article and gave me a lot of information about SSL and TLS. I have a problem regarding TLS 1.2. One of the webservice hosted on a customer server is having TLS 1.2, to consume that webservice I was told to use TLS 1.2 in my application hosted in different server. How this can be done. I am using Windows 2008 R2 server. I have enabled tls 1.2 in my server and tried to initiate the requests to consume the customer server's web service. But it is erroring out "could not establish secure channel for SSL/TLS with authority"

Tracked down a browser not able to access a web page to the SSL cert used on the web server using TLS 1.0. Similar web server apps, when SSL uses TLS 1.2 can be accessed by browser with no problem. Question: who/how decides what TLS version to use with SSL cert? Is it baked into the SSL cert at the time the SSL cert is created? It's not in the app/web server, because the app/web server code is the same in both cases — only the SSL certs are different.

I have a server 2003 machine and I'm researching what I need to do to get it to pass an SSL test (e.g. ssllabs.com). I see a lot of information about how server 2003 does not support TLS 1.1 and 1.2, but I'm also seeing a ton of information online regarding workarounds by editing the registry or various other things. e.g.:

That article appears to show only registry changes which appear to result in a grade of B from ssllabs.com, and if schannel doesn't support TLS 1.1 to begin with I don't see how any registry tweaks are going to change that.

I'm not clear – is there any way to get server 2003 to disable the older insecure protocols and ciphers and only allow the current ones like TLS 1.1 and 1.2? Is the only option to upgrade the OS to a newer version?

QQ is TLS1.0 Client & Server side enabled by default on Windows 2003 and 2008? I notice that the key Client with the Dword "Enabled" (with value ffffffff) is not present by default. On Windows 2008R2 and 2012 I was able to find documentation that explicitly say is enabled by default, but for 2003 I found a bunch of kbs and notes on How to disable protocols.

sorry for the delayed response folks. Been away from blogging for quite some time.

@Steve

Windows Server 2003 and Windows Server 2008 do not have native support for TLS 1.1 and TLS 1.2. Even if you add a registry key it is of no use as the protocol itself is not recognized by the OS. There is also a reason for this. Both the protocols were proposed around 2006 and the industry started adopting this around 2010.

The only solution for you would be to upgrade latest version which is Windows Server 2012 R2.

@Valérie

as I mentioned above TLS 1.1 and TLS 1.2 are not supported on Windows Vista and I don't see any investments being made for them to be made available on Vista. However, I am not on the product team which makes such decisions. I think it would be better if you could post a query for this on UserVoice: windows.uservoice.com/…/265757-windows-feature-suggestions

@Fercha

Yes, TLS 1.0 is enabled by default for client and server side on Windows Server 2003 and Windows Server 2008. You may not see any keyword in the registry for this as they are built-in.

I am using IISCrypto at the last few years and until now all works fine with my sites

Today I was asked by the PCI company to Disable TLS 1.1 AND TLS 1.0 and to enable TLS 1.2

From the moment that I enable only TLS 1.2 nobody from any browser and any pc can login to my site and the error msg is :

Runtime Error

Description: An exception occurred while processing your request. Additionally, another exception occurred while executing the custom error page for the first exception. The request has been terminated.

Few months ago I did the same at my other sites and all works fine.

I will really appreciate your help to help me understand what I am doing wrong and what should be done to solve this issue ASAP

Our application wants to support TLS 1.2. I have configured in registry and also updated my configuration files but I have the IIS version as 7. Our OS is Windows 2008 R2 Enterprise edition.

When I tried to execute my application, it is still taking TLSv1.0 as default. Do I need to upgrade my IIS manager to 7.5? Also am getting error if I tried to upgrade as Microsoft .net framework version 4.0 or greater is required to install 7.5 IIS express.

IIS version is tied to Windows version. You are actually running IIS 7.5 as it is Windows Server 2008 R2. There are 2 things to note, there is a client stack and server stack. IIS consume the server stack configuration.

In this blog when we modify the IE settings it is changing the settings only for IE and not IIS. You will have to modify the

Even if you enable TLS1.2 it depends on the client connecting to the server. Basically you have to do this:

To enable the use of the protocols that will not be negotiated by default (such as TLS 1.1 or TLS 1.2), change the DWORD value data of the DisabledByDefault value to 0x0 in each of the following registry keys under the Protocols key:•SCHANNELProtocolsTLS 1.1Client

I have TLS 1.0 , 1.1 , TLS 1.2 enabled on both Client and Server and both have the same cipher order.
So which protocol is agreed by both before exchange of actual messages ?
I have read somewhere they use the highest possible protocol. Is this right ?

I have a Windows Server 2003. IIS 6 is running on that and TLS 1.0 is available. I have a classic ASP based web application hosted on that server. It has a payment module that connects to PayPoint payment API via https query string from the server side. I checked the paypoint url in the ssllabs and it supports all transport protocols.

The application stopped working since March 2016. I am not able to figure out the error. I initially thought it could be because of the TLS 1.2 version because most of the industry is heading towards that direction and thought that the issue is because the server is Windows 2003. However, the test payment link from PayPoint worked in FireFox browser and it showed that it used TLS 1.2 for the transaction. For a moment I lost my mind.. Does FireFox has the complete implementation of TLS 1.2 build within? So, if the browser or the client application is going to support TLS 1.2 does it really matter whether the server supports TLS 1.2 or not, windows server 2003 in this case?
On the receiving end of the transport connectivity, PayPoint in this case, is it possible for the PayPoint software to put restrictions on the inbound connections to use only TLS 1.2. The ssllabs says the server supports all protocols.
I am sorry for so many questions, but I no very little about this level of connectivity.

Can a browser or a client application fully support or implement a Transport Layer Protocol (either directly or with the help of .NET framework, in the case of applications) even if the underlying Operating System does not support that version of protocol?

Firefox now supports TLS 1.3 with version 49 it will be default on after version 49
0 – SSL 3.0
1 – TLS 1.0 (This is the current default for the minimum required version.)
2 – TLS 1.1
3 – TLS 1.2 (This is the current default setting in version 49)
4 – TLS 1.3 (This is the capable setting for version 49+)

We need to provide https support to Windows XP clients with IE 6.0.
We are using wininet API for internet communication. On XP SP3 after enabling TLS 1.0 https connection is established.
But this doesn’t work on XP SP2 and lower. Is https connection possible on XP SP2 and lower?
How can we find weather the IE and OS support Https connection or not?
Please suggest solution.

Due to PCI Compliance we had to upgrade the security certificate from SSL to TLS1.2 on the server. My web service resides on server(Windows 2008 R2) and am trying to connect it from the test client console app.

I can access the web service and get the results through my client app which is in my local machine, which was already built successfully when the security certificate on server was Tls1.0.
In my client console app, when I try to ADD the same ‘service’ or ‘web’ reference, am not able to add the service url to the client test application.

I get the following error.

There was an error downloading ‘https://www.xxxxxxx.com/xxxxxx.asmx/_vti_bin/ListData.svc/$metadata’.
The underlying connection was closed: An unexpected error occurred on a send.
Unable to read data from the transport connection: An existing connection was forcibly closed

Note: Both Test Console Application and Web Service are built on .Net 4.5

Can anyone give me some insight on how to update Openssl on a Windows Server 2012 R2? We are being impacted by the PCI industry changes and have not been able to get much support from our host provider.

It seems we are running 0.9.8c and need to upgrade to 1.1.0c. Any thoughts or insight that you can share will be greatly appreciated.

I tried to look on the consulting boards for a Openssl or TLS expert, but couldn’t find anyone in my query. Been struggling to fix this for 4 weeks now…please hlep. Thanks!

Do you have any experience or are you aware of any issues for UWP apps?
We have an UWP app running in Windows 10 that stopped working after the service we were connecting to disabled TLS1.0.
We tried several things and we are not sure if the issue is on the app or on the network.
But it seems there are no options for enforcing TLS1.2 on the WEB APIs for UWP,

Google Chrome uses NSS libraries for SSL/TLS which are independent from Windows and Internet explorer TLS settings (https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS). Therefore, regardless of TLS support on OS or IE level, Chrome will still work as long as we don’t change TLS settings in Chrome.

Its difficult to provide recommendations without much insights into the issue. I would suggest to perform checks on the client and server and ensure that TLS 1.2 is enabled for both Client and Server stacks.
Take a network trace from both client and server to ensure that the SSL handshake is completing.

Note that you can’t just use GetVersionEx to discover if you’re on Windows 8.1 or Server 2012 R2 or newer to know TLS 1.2 will be there. GetVersionEx will lie and return an incorrect value if your application hasn’t been manifested for 8.1/2012 R2 🙁 Ticked off right now…