+1
Started

Status screen - elements do not function if TLS1.0 is disabled on host for PCI compliance

CSW Group 3 years ago updated by Jonathan McKnight 2 years ago 15

On premises installation, using 6.3. The Status screen version, external checks etc do not work and give a red error if TLS1.0 is disabled on the host server.

ConnectWise Control Version:
19.0
Server Affected:
Host Client Affected:
Guest Client Affected:

Answer

-1
Answer

Good morning all,


I wanted to let the thread know that a fix for this behavior should be available in version 6.5 of ConnectWise Control, pending QA. Thank you again to everyone who provided information regarding this behavior.


Regards,

Ben

I discussed with support yesterday July 10th, and they suggested a bug report is logged for this feature to be fixed.

Waiting for information

Good morning,


I am attempting to reproduce this behavior in our test environment by explicitly disabling TLS 1.0 and TLS 1.1 on a Windows 2012 and Windows 2012 R2 server by modifying the registry -- in both cases, the external checks initiated by Control are succeeding without issue.


If you don't mind, could you update this thread with the following information:


1) Server OS on which you've installed ConnectWise Control

2) How are you disabling TLS 1.0?


Regards,

Ben

The OS is Windows Server 2008 R2 and i am using IISCrypto 2.0. Once TLS 1.0 is enabled the fields return to green.

If you cannot recreate the issue, then disregard and we can work around it when necessary.

Same issue here, Status: Version Check, External Accessibility Check, Browser URL Check, Web Server Check all show Red, all fields are blank, except the Web Server Check Test URL is populated correctly.


Disabled TLS 1.0 and TLS 1.1, running TLS 1.2 only, using these cipher suites on Windows Server 2016 V1607, running ScreenConnect 6.3.13446.6374


TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA


Listing Cipher Suites one line at a time (no DHE ciphers), as your webpage is truncating the above list:


TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA

Disabled via registry:


Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001


SSL Labs: https://www.ssllabs.com/ssltest/analyze.html?d=usatechnologycenter.com



Under review

Good afternoon,


I was able to force the version check to error out using the following Schannel and Cipher Suite settings in IIS Crypto 2.0; as soon as I re-enabled the SHA hash algorithm (keeping TLS 1.0/1.1 disabled), the version check no longer errored out, which leads me to believe the behavior isn't related to disabling TLS 1.0/1.1:

 





This was tested on a Win2k12r2 vm using the latest internal build of Control.

If I add TLS 1.1 using the registry with TLS 1.2 I get the same red errors (TLS 1.1 and TLS 1.2 only).

If I remove TLS 1.1 and add TLS 1.0 using the registry with TLS 1.2 then it works fine (TLS 1.0 and TLS 1.2 only).

When I try to manually enable SHA on Windows Server 2016 it still doesn't work.  Using registry settings as follows:


[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\SHA]
"Enabled"=dword:00000001


I also tried the following and it did't help:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\SHA]
"Enabled"=dword:ffffffff


(A server reboot was performed after each change above).


I don't know that this setting applies to Windows Server 2016, these are the references that I found for previous OS's:


https://support.microsoft.com/en-us/help/245030/how-to-restrict-the-use-of-certain-cryptographic-algorithms-and-protoc

https://technet.microsoft.com/en-us/library/dn786418(v=ws.11).aspx#BKMK_SchannelTR_Hashes



I just downloaded and installed IIS Crypto 2. I used the following settings, booted, still have same errors:




Another manual: TLS Cipher Suites available in Windows Server 2016 v1607 (and Win10)

https://msdn.microsoft.com/en-us/library/windows/desktop/mt490158(v=vs.85).aspx


I had exported the registry prior to using IIS Crypto 2.0.  I set IIS Crypto back to the "Server Defaults" template, applied it, and booted.  It did not put things back as they were originally (the settings might result in the same outcome), but they left many subkeys and dword values defined in the registry under Ciphers, Hashes, KeyExchangeAlgorithms and Protocols. I put things back manually and via registry import, to the way things were before IIS Crypto, and I am back to TLS 1.2 only using my ciphers as stated in my previous post, still with errors.


Thank you for providing an update. I was able to reproduce the behavior using those settings on a Windows 2016 server. I have added the information to the issue and it is currently under investigation.


Cheers,

Ben

-1
Answer

Good morning all,


I wanted to let the thread know that a fix for this behavior should be available in version 6.5 of ConnectWise Control, pending QA. Thank you again to everyone who provided information regarding this behavior.


Regards,

Ben

+1

Same issue when running 6.5.16479.6613 also.  FYI

I'm currently running 6.5.16479.6613 on Windows Server 2016.  


I disabled TLS 1.0 yesterday for PCI compliance and am now facing this same issue.


Has this been resolved in a more recent release?