This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

In order to be PCI compliant we have a requirement to disable TLS 1.0 on the Windows 2012 R2 server running the Enterprise Console version 5.5.0

When i disable TLS 1.0 the Sophos Management Service fails to start with

event ID 8025 There is no database connection. Management Service will be shut down.

and event ID 8004 Initialization failed.

Step: Creating a database connection
Error: std::runtime_error
Data: [DBNETLIB][ConnectionOpen (SECDoClientHandshake()).]SSL Security error.

I initially raised a call with Sophos and it was closed saying the issue was fixed in version 5.4.1 of the console which i was running at the time,

i have now upgraded to version 5.5.0 and the issue still exists



This thread was automatically locked due to age.
Parents
  • 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?

Reply
  • 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?

Children
  • 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
    -----------------------------------------

     

  • 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