Over the last two days, we have had a number of support tickets submitted which only effected accounts with low SSL score (https://www.ssllabs.com/ssltest/analyze.html) and specifically accounts that have TLS1.2 disabled in their HTTPS connection protocols. It is not affecting any ConnectWise Cloud accounts.
The entire team has been working on this issue, pulling apart flow logs and trying to figure out why this issue presents at certain times and only for specific partners.
Here is what we know:
- Issue is only affecting on-premise accounts (accounts that have a low SSL score and specifically accounts that have TLS1.2 disabled in their HTTPS connection protocols)
- ConnectWise now requires all API's to connect over TLS1.2, as other protocols are vulnerable to attack. Although the connection on our side can repressively negotiate to find a connection, where TLS1.2 is disabled, this is where the issue then affects your server connection.
- On Tuesday there was a change made to our application; and specifically to the Authorize.Net connection frameworks, to force the use of TLS 1.2 (which is a PCI requirement). This change was added to the connection parameters for the .Net framework, which underpins the entire platform (so has been found subsequently to affect all accounts, not just the connection for that one call to Authorize.Net). What was not known at this time of the change is that the setting of the TLS1.2 for that connection; then means that all connections are forced onto this protocol. When testing on our pre-release platform, the issue did not surface as all our development, and QA servers are all configured to support TLS1.2.
- Ordinarily this would not be an issue, but when we were inspecting the accounts that had reported the failure, all showed the same traits.
- At the time the connection to your server fails, the resulting error is relating to the negotiation of a TLS1.2 connection. When we checked your server, TLS1.2 is not available / enabled. The resulting error that we are seeing is a SChannel error relating to the failure to negotiate a connection on TLS1.2.
What you will need to do to address this issue moving forward:
- What is actually causing the issues is that you have older protocols enabled, and specifically TLS1.2 is not enabled. Again, this is already something that ConnectWise has mandated and a security notification was sent some time ago about securing your server.
- You will need to disable SSL3, SSL2 as both are susceptible to SSL attack (Heartbleed, Poodle)
- Partners will need to ensure that TLS 1.2 is enabled before 1st September, 2017 to ensure that they will be able to connect and Sync.
We've been in contact with the ConnectWise Cloud Platform Team, to troubleshoot what we are seeing, and they have advised that this would be a contributing factor. The issue is only presenting to partners that do not have their protocols matching what is now best practice. In cases where TLS 1.2 is not enabled, when the server connections on our side negotiating on TLS1.2, they fail to connect.
If you need direction on how best to secure your ConnectWise server, we recommend you log a support ticket with ConnectWise to ensure that you bring your server up to date in terms of the connection security.
Changes to the Transport Layer require a reboot between each change, so we recommend that this be done out of hours.
There are tools available online including SSL Labs to test your SSL support, as well as IISCrypto (unfortunate name now) that allows you to configure your protocols.
You will need to ensure:
- Protocols are enabled
- Ciphers are enabled / disabled as per the best practices
- Hashes are enabled / disabled according to best practice
- Key Exchanges are enabled.
- Cipher Suites are ordered (as above)
To meet strict PCI requirements, we must ensure that all SSL channels operate over TLS1.2, so although we are rolling back the change which invoked this security increase will provide some respite, as it is a necessary requirement (and recommendation from ConnectWise) that you ensure that TLS1.2 is enabled and that your SSL configuration is not leaving your systems vulnerable to attack.
We've published a detailed article on the issue and provided a time frame and guidance on when these changes need to be made by. Click here to read the article.
