Unable to connect to Sophos Enterprise Console version 5.0.0 if TLS 1.0 is disabled

I'm trying to get this working as well and I reached out to one of the Sophos engineer's and it seems that in order for this to work, the Sophos Management Service (MgntSvc.exe) must be setup to use a different SQL Provider in order to use TLS 1.1 or 1.2.

This is what I've gathered so far:

Updated registry setting

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Sophos\EE\Management Tools]

"DatabaseConnectionMS"="Provider=SQLNCLI11.1;Integrated Security=SSPI;Initial Catalog=SOPHOS550;Data Source=(local)\\SOPHOS;"

Verified database can be reached using TLS 1.2 and SQL Native Client with UDL file

All services start EXCEPT the Sophos Management Service

Is MgntSvc.exe built on .net 4 or .net 4.5?  From my research, I’ve gathered that .net 4 applications will not use TLS 1.2 unless the following code is at the beginning of the application:
ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

And then the following REG Key set: 
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319: SchUseStrongCrypto to DWORD 1

Any ideas?

Hi,

What version of MS SQL Sever do you have installed? Is it the SQL Express 2012 SP2 version installed by SEC (C:\sec_550\ServerInstaller\pre-reqs\sqlExpress2012SP2\)?

Have you now upgraded that to a version that supports TLS 1.2, e.g. SP3?  https://support.microsoft.com/en-gb/help/3135244/tls-1.2-support-for-microsoft-sql-server so say, 11.0.5352.0?

Checking the ERRORLOG file will give the exact version of SQL as a quick check.

From the connection string shown, it appears to be a local instance "(local)". What protocols are enabled on the SQL instance?

Note: By default when Sophos installs the SQL instance, TCP is disabled, named pipes are enabled and so is shared memory.  You can see that in the SQL Server Configuration Manager - https://msdn.microsoft.com/en-us/library/ms174212.aspx

Does the management service start if you:

1. upgrade SQL to a version that supports TLS 1.2
2. use the default SQLOLEDB provider
3. enable only named pipes on the SQL instance as it's local.

Regards,
Jak

SQL Version is the 2012 version which SEC 5.5 installs.  I then updated it with the latest services packs and updates required for TLS 1.2.  The SQL instance is not the problem because the SQL Native Client has no issues connecting to the database.  Changing the TCP and Named Pipes did not make any difference.  I currently have everything enabled.  I also tried changing the string to the server name instead of local because that's how the UDL sets it but still nothing.

If I enable TLS 1.0 and then change the Provider back to Microsoft OLE DB then the servive starts without any problems.

Works (with TLS 1.0 Enabled)
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Sophos\EE\Management Tools]
Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=SOPHOS550;Data Source=WIN-T796TO1DKG1\SOPHOS

Doesn't Work (With TLS 1.0 Enabled or Disabled)
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Sophos\EE\Management Tools]
Provider=SQLNCLI11.1;Integrated Security=SSPI;Persist Security Info=False;User ID="";Initial Catalog=SOPHOS550;Data Source=WIN-T796TO1DKG1\SOPHOS;Initial File Name="";Server SPN=""

It also doesn't matter if I leave TLS 1.0 enabled and try starting MgntSvc.exe using the SQL Native Client Provider, it still results in the same .net run time error.

My best guess is that MgntSvc.exe has only been officially tested by Sophos using the Microsoft OLE DB Provider and does not work if you attempt to change the provider.  If we can get MgntSvc.exe to load using the SQL Server Native Client Provider, then TLS 1.0 can be disabled.

Hello B.Banner_Hulk,

has only been officially tested
it's not a question of tested. One might expect that databases would be fully abstracted (as far as this is possible) by a framework like .NET. They aren't - won't go into details here but each provider has its own namespace. If the application isn't written to work with different providers just specifying a different provide in the ConnectionString won't make it use this provider, instead - as you've seen - an error will be thrown.

Christian

QC said:

Hello B.Banner_Hulk,

has only been officially tested
it's not a question of tested. One might expect that databases would be fully abstracted (as far as this is possible) by a framework like .NET. They aren't - won't go into details here but each provider has its own namespace. If the application isn't written to work with different providers just specifying a different provide in the ConnectionString won't make it use this provider, instead - as you've seen - an error will be thrown.

Christian

 

Thanks Christian.  Then I think in conclusion, it's safe to say that SEC, or at least the management services, are not not capable of using another provider and therefore, cannot work with TLS 1.0 disabled.

It sounds like we'd need the Sophos developers to actually re-code or update the code of the Sophos Management Service to support a TLS 1.2 compatible provider.  Until then, not possible.

I re-opened my original ticket and got it escalated up.

I have just had a reply and they have just released a new article on the 8th May relating to it, it will be fixed in a future release of the console

-----------------------------------------
Article ID: 126672
Title: Sophos Enterprise Console: does not start if TLS 1.0 is disabled on management server or SQL server
URL: http://sophos.com/kb/126672
-----------------------------------------

I re-opened my original ticket and got it escalated up.

I have just had a reply and they have just released a new article on the 8th May relating to it, it will be fixed in a future release of the console

-----------------------------------------
Article ID: 126672
Title: Sophos Enterprise Console: does not start if TLS 1.0 is disabled on management server or SQL server
URL: http://sophos.com/kb/126672
-----------------------------------------

Hello PaulWebb,

thanks for the information. When first published the article stated SEC 5.6.0 instead of future release. Can't say what this signifies - that'd take some time so it might not come with 5.6.0 (whatever this one will include), that it's not decided whether it'll be numbered 5.6 or 6.0, or that it might even be brought forward to (the already WIP) 5.5.1.

Christian