When trying to connect a Windows Player (1.8.3 or 1.8.2) to the CMS, we get the error:
Status
The request was aborted: Could not create SSL/TLS secure channel.
The player can connect to the CMS over regular http (but this is not preferable)
https works correctly when accessing the CMS in a browser
The client could in the past connect successfully to the CMS over https
The only obvious change in our systems that might be relevant is that support for older, insecure ciphers was recently removed from our webserver. Is it possible that the client depends on older ciphers?
The Player itself doesn’t select what cyphers to use, Windows does.
It is however possible that whatever change was made has disabled the ability for .net applications to connect.
What change was made to the webserver? If it’s publicly accessible, you might run it through a tool such as SSL Labs from Quallys which will simulate handshakes and show any potential issues.
I work with Ian. Sorry, it’s taken a while to get back to you on this. We ran an SSL labs test against our site. It came back with some on-trivial adjustments that needed to be made. As such, we depreciated many old and insecure ciphers. We’re currently only supporting the following:
In accessing the CMS via web browser (Chrome, FireFox & IIS), the new ciphers work perfectly on both Windows and Macs. However, the Xibo client throws an error. Going back to the old ciphers fixes the problem, but we cannot do this in production due to InfoSec issues. HTTP has worked temporarily.
Since the browsers work, it feels like this is an issue with the Xibo client itself. The Xibo client is running on Windows 10 build 1709 and the all of three of the above browsers are able to connect to the CMS successfully, but the Xibo client on the same machine cannot. These Windows 10 systems are fully updated with the newest versions available of .Net 4.5 We have not done any special .Net customization to the machines that host the Xibo client.
In reviewing the Xibo client requirements, it appears that .Net 4.5 is required. In doing some research, the Stack Overflow post seems to indicate that .Net will only use the OS default if the application is using .Net 4.7+.
The article seems to indicate that the TLS version for a .Net 4.5 application needs to be hard coded:
Before 4.7, you had to specify the TLS version to use explicitly
From the release notes of .Net 4.7:
Default operating system support for TLS protocols*
The TLS stack, which is used by System.Net.Security.SslStream and up-stack components such as HTTP, FTP, and SMTP, allows developers to use the default TLS protocols supported by the operating system. Developers need no longer hard-code a TLS version.
While I’m not a dev, is it possible that the Xibo client, using .Net 4.5, is hard coded to use an old cipher? If the Xibo client doesn’t have a “ServicePointManager.SecurityProtocol” value defined, is it possible that the compiled client is using the .Net 4.5 default (ssl3/tls 1.0)?
An update - we believe we’ve confirmed that .Net 4.5 does not use the OS defined ciphers by default. Instead, it uses SSLv3 and TLS 1.0. When we disabled everything but TLS 1.2, this caused the Xibo client to stop being able to connect to our server when we used a secure channel.
In reviewing other application’s documentation related to this issue, there are registry keys that can be applied client-side to force .Net 4.5 to use newer ciphers (e.g. TLS 1.2).
Enable the SchUseStrongCrypto property in the Windows registry to use as the default protocols: TLS 1.0, TLS 1.1 and TLS 1.2
If you want to make sure strong cryptography is enabled and the SSL protocols for your requests to be TLS 1.0, TLS 1.1 and TLS 1.2, please follow this steps:
Start the registry editor by clicking on Start and Run. Type in “regedit” into the Run field (without quotations).
Highlight Computer at the top of the registry tree. Backup the registry first by clicking on File and then on Export. Select a file location to save the registry file.
Note: You will be editing the registry. This could have detrimental effects on your computer if done incorrectly, so it is strongly advised to make a backup.
Browse to the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NetFramework\v4.0.30319
Right-click on the right pane and create a new DWORD (32-bit) Value with Name SchUseStrongCrypto.
Ensure that the Value data field is set to 1 and the Base is Hexadecimal. Click on OK.
Repeat steps 4 and 5 for the registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft.NetFramework\v4.0.30319