Portal access to TMS is prevented when RC4 cipher is disabled

Answer

Contents

Problem

Portal access to TMS is prevented when RC4 cipher is disabled

A problem in TMS access has been traced to exclusion by Windows of RC4 SSL connections in .Net applications. RC4 has been in use as it's a stream cipher which is optimal for the way TMS sends data). This was the most secure stream cipher available when TMS was developed but this cipher is no longer considered as secure and is being replaced by AES.

Diagnostic Signs

• The \Tealeaf\Logs\TLMgmtSrv log look normal as TMS -> TMS access is still working
• Browser access testing still works though you might need to accept the self-signed certificate
  • https://localhost:20000/Status
• The \Tealeaf\Portal\WebApp\temp_chart\TLPortal-Requests log shows this SSL negotiation failure:

2014-05-31T10:30:49?? ?TMS_SERVER - ADMIN - GetAuthHeader ?? ?
ERROR?? ?Command: Version Response Status Code: 0 Elapsed (ms): 1.0001
URL: https://TLSRV01:20000/Version
Error: GetAuthHeader() AttemptCount=0 failed for https://TLSRV01:20000/Version
- The request was aborted: Could not create SSL/TLS secure channel.???

Solution

As Portal access to TMS relies on the RCS cipher this security update breaks access to TMS. The access failure has been seen on a wide variety of Tealeaf builds from 7.2 to 9.0 and is an environmental problem.

While the master Tealeaf Management service log shows normal inbound connections from other servers
Portal access to TMS produces an error and perpetual "processing" pop-up. The error on access to TMS in Portal is:

???? Alert
???? There was an error connecting to the TMS Service

This Portal -> TMS access problem effects many Tealeaf subsystems as TMS is used for file transfers. Therefore cxConnect job management Alert management uploading TLA files to the Evet Tester etc. are also effected.

While access from Portal to TMS is broken TMS -> TMS communication remains unbroken as the security update described below provents RC4 connections in .Net applications only. The main TMS log may look normal but the TMS and Portal access logs will show connection and SSL errors on port 20000.

On a problem machine RC4 connections are not offered to the client (Portal) while on working machines RC4 is the preferred connection method. The client hello lists RC4 third in list but Portal selects it preferentially.

The related KB articles:

???? 2868725 - Microsoft security advisory: Update for disabling RC4
???? http://support.microsoft.com/kb/2868725

???? 2960358 - Microsoft security advisory: Vulnerability in the .NET Framework: May 13 2014
???? Published may Updated July 8 2014 - an update to .net to disable via the registry of RC4
?????http://support.microsoft.com/kb/2960358/en-us

The TMS connection problem has been duplicated when this security update (2960358) is applied. The test machine was on a fully patched Windows 2008 R2 server where TMS was working fine before. The problem persists through a reboot. TMSStore rebuilds to not restore access. The removal instructions are to use the control panel to find and remove this windows update. The removal of this windows update been proven to fix the problem:

???? 2938782

Moving forward the AES cipher has been provided as a replacement connection method. Interim fixes are available for Tealeaf 8.7 and 8.8 and 8.8 Fix Pack 3 (8895) includes it.

- 8.7 interim fix is on Fix Central:
? IBMTealeafCX9.0_9.0A_TMS_Patch

- 8.8 Fix Pack 3 has this change on Fix Central:
? 8.8.0.8895_TL_CXUpgrade_FixPack3

- 9.0 interim fix is on Fix Central:
?? BMTealeafCX9.0_9.0A_TMS_Patch

For 8.8 if you are not planning to apply Fix Pack 3 in the near term you can retrieve and deploy TLMgmtSrv.exe by itself from the \SourceFile folder of that installer. The Support group can also assist with acquiring this program version.

Apply the new TMS version to all TMS instances together to retain TMS -> TMS connectivity
as the older RC4 support has been removed.


Applies to version(s): All (7.x;8.x9.x)