Identify and forbid weak TLS usage in IIS

In this article we will see which web encryption protocols are considered as weak and how it's possible to identify web traffic encrypted with these weak protocols in IIS and finally we’ll see how to disable them to keep the web traffic more secure.

Weak encryption protocols

Lately there have been several attacks on encryption protocols used to encrypt communications between web browsers and web servers (https). Most of these attacks use flaws in older protocols that are still active on web servers in a Man In The Middle scenario. For example the POODLE attack forces the server to fall back to the flawed SSL3 protocol even that the latest TLS protocol is available. Some attacks are directly against TLS but for now only some implementations of TLS are concerned. In particularly TLS 1.0 has some weaknesses that facilitate these attacks and could lead soon to successful attacks on the whole protocol and not only on specific implementations. So TLS 1.1 and 1.2 should be used instead and fallback to older unsecure protocols should not be possible.

For this reason TLS 1.0 needs to be disabled as soon as possible as well as any older protocols (SSL). After 30^th June 2018 these encryption protocols will no longer be allowed for organization that need to be compliant with PCI DSS (Payment Card Industry Data Security Standard) and for US government servers and clients only TLS 1.1 and 1.2 are now compliant with the NIST Special Publication 800-52.

However you can’t disable these deprecated protocols before being sure that you will not break anything. You need to identify in which cases those old protocols are still used and upgrade all required systems to remove all dependencies on them and then only you can disable them.

That’s what we will see in this this article in the case of an IIS web server.

Configure cryptographic fields in IIS HTTP logs

On September 17th 2017 Microsoft announced in the article New IIS functionality to help identify weak TLS usage that the ability to log some new fields allowing to know which encryption algorithms are used for every web request has been added.

This feature was added to Windows 2012 R2 and Windows 2016 in the July 2017 Monthly rollup. So before trying to implement this, make sure your web servers are up to date.

This feature is based on the IIS custom logging fields feature introduced with Windows 2012 R2. You can see how to use this feature in my blog post Configure IIS HTTP logging. However we will do it differently in this article by editing directly the IIS configuration.

The custom log fields configuration is stored in the IIS configuration file ApplicationHost.config located in the folder C:\Windows\System32\inetsrv\config\

We will use the notepad to edit this file. If your account needs privilege elevation to have full administrative rights directly start the notepad as administrator so you will be able to save the modifications later without any trouble.

Then load the IIS configuration file in the notepad.

In the XML file locate the following section configuration/system.applicationHost/sites. At this location, you will have one section for each site running on the server. Choose the site you want to audit and locate the section logfile/customFields for this site.

Then in this section after the <clear/> line, just paste the following custom field configuration copied from the Microsoft article.

 <add logFieldName="crypt-protocol" sourceName="CRYPT_PROTOCOL" sourceType="ServerVariable" />
 <add logFieldName="crypt-cipher" sourceName="CRYPT_CIPHER_ALG_ID" sourceType="ServerVariable" />
 <add logFieldName="crypt-hash" sourceName="CRYPT_HASH_ALG_ID" sourceType="ServerVariable" />
 <add logFieldName="crypt-keyexchange" sourceName="CRYPT_KEYEXCHANGE_ALG_ID" sourceType="ServerVariable" />

If the section logfile/customFields doesn't exists you need to create it like in the screenshot below.

Then save the file.

If you open the logging configuration of the web site in the IIS manager you should see the just added custom fields like in the following screenshot.

Then after some activity occurred on the concerned web site you can check the latest log file located for example in the folder C:\inetpub\logs\LogFiles\W3SVC1 for the default web site.

If you open this log file in the notepad you will see at the end of each line 4 numeric fields like in the following screenshot.

The meaning of these numeric values can be found in the MSDN either on the page secure protocol version or on the page cipher suite algorithm but it’s a little cumbersome to get the meaning for every value found in the logs. This is where the FinalAnalytics tool HttpLogBrowser comes into play.

Audit weak TLS usage with the HttpLogBrowser

The HttpLogBrowser is an IIS HTTP log viewer and analyzer. The free edition will be enough to do what is needed in this article except if you need to export or print the data. In the just released version 2 of the application, a new feature named Translate cryptographic fields has been added to display meaningful values for the new log fields that we just enabled in the previous section.

You can download the HttpLogBrowser from this link. For the purpose of this article I will install the tool on the web server but in a real life scenario it’s recommended to install it on a workstation and download the logs to the workstation because log analysis can be CPU and memory consuming. I have two blog articles that explain how to do this: How to retrieve IIS HTTP logs remotely and Synchronize IIS HTTP logs

Once the HttpLogBrowser is installed and launched you first need to enable the required setting in the Default log settings accessible in the tools menu.

Click next in the wizard until you see the following page.

Then select Translate cryptographic fields and click Finish.

Once done you can load the log file from the Files menu

Browse for the log file and click OK

You get then a result like this:

In the cryptographic fields, the numeric values have been replaced by names. You see in the previous screenshot web requests done by IE9 on Windows 7, IE11 on Windows server 8.1, FireFox 57 and Chrome 63. You can see that IE 9 still uses TLS 1.0 when the other browsers are using TLS 1.2.

You can also easily display statistics on the CryptProtocol field thanks to the field statistics panel like in the following screenshot.

You can then easily determine how much traffic goes through the web site with the TLS 1.0 protocol. You can click on SP_PROT_TLS1_SERVER in the statistics to automatically only display web requests encrypted with TLS 1.0 and then you can go over all client IP addresses or client web browsers to find out who or what is generating this traffic. You can also use the reverse DNS feature of the HttpLogBrowser to get the involved client hostnames if needed.

Now you can start finding problematic web clients and start upgrading what needs to be upgraded. This doesn’t mean just upgrading all web browsers accessing the web server. Custom client applications may consume a web service running on the server. Those applications may be based for example on an old version of the .NET framework. So such applications may need to be rebuilt against a more recent version of the .NET framework by the developer to be able to use a recent version of TLS.

Once you no longer get traffic for weak cryptographic protocols (TLS 1.0, SSL 3.0, …) after a period of time long enough you can consider disabling them but before some additional verifications are needed.

Verify if other applications use weak protocols

At this step we are sure that the IIS web server no longer relies on weak protocols. However other applications may rely on them.

For example you may have an FTP server configured in IIS. Unfortunately there is no way to audit which encryption protocols are used in FTP sessions. It’s even not possible to identify which FTP clients are used because there is no such as a user agent string like for the HTTP protocol in the FTP logs. The only way, is to inform all users of the FTP server to use an up to date FTP client supporting TLS 1.2.

The RDP protocol for remote desktop sessions may also use TLS encryption depending on how the encryption is configured in RDP settings and negotiated with the client. So you should also make sure that all RDP clients accessing the web server are up to date.

This article only concerns Windows Server 2012 R2 and Windows 2016 but as an illustration if you enable TLS 1.2 on Windows Server 2008 R2 (disabled by default) the uploads will stop working in encrypted FTP sessions due to a bug in the TLS 1.2 implementation and if you disable TLS 1.0 the Remote Desktop may fail if RDP is configured to only use TLS and the proper patch is not installed.
On Windows Server 2012 R2 and Windows 2016 you should not have these problems but this illustrates the implications when you move from old encryption protocols and also illustrates the need of full regressions tests.

Disable weak protocols with IIS Crypto

Now that you are sure that all weak cryptographic protocols are no longer used you can disable them. The official Microsoft documentation explains how to do this through the registry but this may be cumbersome and prone to mistakes. Instead you can use the free tool IIS Crypto from Nartac Software. You can download it from this page. Select the version with the GUI. Once downloaded execute the file directly. No installation is required.

This is how this tool looks like when started for the first time on the web server. All check boxes are grayed meaning default Windows settings are effective.

You could unselect manually all weak protocols and algorithms but instead you can switch to the Templates view and select for example the predefined template PCI 3.1 that will unselect for you all the weak protocols.

You can then see the result in the following screenshot. Only TLS 1.1 and 1.2 are allowed.

Now you just need to click on Apply and restart the server. If you did all your preparation work all should work perfectly after the reboot.

Conclusion

You have learned in this article how to enable cryptographic fields in the IIS HTTP logging of Windows server 2012 R2/2016 and then how to use the free edition of the HttpLogBrowser to identify weak TLS usage in order to later disable these deprecated protocols with another free tool IIS Crypto without breaking anything on your web server. If you need more information on the subject you will find hereafter a few links that may be of interest to you.

• Known SSL/TLS Attacks: POODLE, DROWN, FREAK, Logjam, BEAST
• NIST: NIST Revises Guide to Use of Transport Layer Security (TLS) in Networks
• PCI DSS: Are You Ready for 30 June 2018? Saying Goodbye to SSL/early TLS, Migrating from SSL and Early TLS 
• Microsoft: Solving the TLS 1.0 Problem

2 Comments

• JD168 said 5 years ago

  Hello,
  
  I tried to insert the code above, but afterwards all Outlook are losing connection. My applicationHost.config looks like the following code. I am sure where to put the needed lines.
  
  <?xml version="1.0" encoding="UTF-8"?>
  <!--
  IIS configuration sections.
  For schema documentation, see
  %windir%\system32\inetsrv\config\schema\IIS_schema.xml.
  Please make a backup of this file before making any changes to it.
  -->
  
  <configuration>
  ...
  <system.applicationHost>
  ...
  <sites>
  <site name="Default Web Site" id="1" serverAutoStart="true">
  ...
  <bindings>
  ...
  </bindings>
  ADD HERE
  </site>
  ...
  </sites>
  ...
  </system.applicationHost>
  ...
  </configuration>
  

• jnh said 5 years ago

  Hello JD168
  
  I shortened your configuration file and left only the important sections.
  In your case the <logfile> section doesn't yet exist in the site configuration so you need to put the following code after the <binding> section (Where I put the mention ADD HERE in your configuration file):
  
  <logFile>
  <customFields>
  <clear />
  <add logFieldName="crypt-protocol" sourceName="CRYPT_PROTOCOL" sourceType="ServerVariable" />
  <add logFieldName="crypt-cipher" sourceName="CRYPT_CIPHER_ALG_ID" sourceType="ServerVariable" />
  <add logFieldName="crypt-hash" sourceName="CRYPT_HASH_ALG_ID" sourceType="ServerVariable" />
  <add logFieldName="crypt-keyexchange" sourceName="CRYPT_KEYEXCHANGE_ALG_ID" sourceType="ServerVariable" />
  </customFields>
  </logFile>
  
  In any case if you don't feel comfortable by changing the XML file you can use the IIS manager as shown in the screenshot. Just make sure you enter every field with the exact same name.

You must log on to comment.