Has anybody managed to successfully deploy Sophos Enterprise 5.5.1 while using the TLS1.2 database connectivity?

Hello Redfern,

I am in the process of updating from 5.4.1 and have outcome all but the stated instance support error. I too am on 2012 SP4 /w CU 10. I've tried many different things after ensuring it was not anything to do with an encrypted connection to the SQL server.

So I decided to log a ticket with Sophos to get their explanation on the issue. I'm wondering if it is simply checking for a version number that is different, below mine is stated as 11.4.7001.0 which might identify express version over other versions.

SQL Server 2012      codename Denali

11.0.2100.60

11.0.3000.0 or 11.1.3000.0

11.0.5058.0 or 11.2.5058.0

11.0.6020.0 or 11.3.6020.0

11.0.7001.0 or 11.4.7001.0

In your case the cert issue is that you will need to configure a certificate for use with the SQL Server. We have an enterprise CA so it's quite straightforward for me (just remember to configure all the alternate names you might be using). Sophos link below if you haven't already seen it.

community.sophos.com/.../127521

Can let you know what they reply.

Cheers,

Grant

Hi Grant. 

Thanks for this. 

Did you get a helpful Reply? 

Would be grateful if you can share it with us. 

Cheers. 

Shahid 

Hi Shahid,


I got a reply that said they are discussing it with their product team and will get back to me. I'm sure the post below is spot on with simple installer issues, but I need an official response from Sophos for our compliance. Will update the thread when they provide such information.

best wishes,

Grant

Thanks Grant.  That is one topic that's of importance to us.

Some reading:

https://www.digicert.com/blog/depreciating-tls-1-0-and-1-1/

https://www.theregister.co.uk/2018/06/19/ietf_calls_for_formal_tls_1_0_1_1_deprecation/

Hi guys,

yep no worries, if I'm a slow getting back to this thread it's only because it's a slow process with the Sophos support team. So far they have just referred me to these two links below, which are the same as those referenced during this installer.

-----------------------------------------
Article ID: 127521
Title: Enterprise Console - Database connection check
URL: https://sophos.com/kb/127521
-----------------------------------------


The KBA also links to a Microsoft page that describes what needs to be done in order to prepare the SQL server for TLS 1.2:
https://support.microsoft.com/en-us/help/3135244/tls-1-2-support-for-microsoft-sql-server

Slightly annoying as the initial ticket a logged included output from the dbcheckconnection.exe tool.

regards,

Grant

Exactely the same here.  They referred us to the link already provided in the installation instructions.  dbconnection.exe, logs, et.c.

Hi Guys, 

Sophos got back to me today. and..yep..you guessed it, they RE-referred me to the article!

And they are avoiding speaking to me over the phone about this. One of the engineers that i spoke to told me straight of the bat that he doesn't no much about SQL etc..like okay, but then why are you picking up a ticket that involves SQL? 

They said they'll look into it further and let me know. 

Hi guys,

I'm going to take a different approach at this point. I found the xls matrix really quick and it appears SQL 2016 SP1 is the latest version supported with 5.4.1. So I'm going to upgrade SQL to this version as it should have the added benefit of exposing the "trace" debug in SQL extended events which will show me the SSL handshake (and what version it is, e.g. TLS 1.2).

So working with the article below I should already see this information using SQL 2012 SP4, but I can confirm on a few different SQL boxes that I never see this option. But I do see it on an SQL 2016 SP1 box.

www.sqlservercentral.com/.../

The SQL instance is on the same box and is just SQL express, so I'll just snapshot the VM before upgrading, and can rollback if any problems are found.

I'll report back in once I've completed and check the above work.

Ta,

Grant

Hi guys,

I'm going to take a different approach at this point. I found the xls matrix really quick and it appears SQL 2016 SP1 is the latest version supported with 5.4.1. So I'm going to upgrade SQL to this version as it should have the added benefit of exposing the "trace" debug in SQL extended events which will show me the SSL handshake (and what version it is, e.g. TLS 1.2).

So working with the article below I should already see this information using SQL 2012 SP4, but I can confirm on a few different SQL boxes that I never see this option. But I do see it on an SQL 2016 SP1 box.

www.sqlservercentral.com/.../

The SQL instance is on the same box and is just SQL express, so I'll just snapshot the VM before upgrading, and can rollback if any problems are found.

I'll report back in once I've completed and check the above work.

Ta,

Grant

Can’t wait to see the result of this ...

Okay, so I have got to the root of the issue for my environment. I am running SEC 5.4.0 with SQL Express 20012 SP4. I get the following output from the installer:

(/) Operating system is ready to use TLS 1.2

(/) Installed .NET Framework supports TLS 1.2

Connection to the SQL Server established

(x) SQL Server instance does not support TLS 1.2

(/) SQL Server TCP/IP protocol is enabled

(/) There is a certificate installed that can be used with SQL Server

(/) SQL Server Native Client library supports TLS 1.2

Everything looks supported and I should follow the KB’s:

-----------------------------------------
Article ID: 127521
Title: Enterprise Console - Database connection check
URL: https://sophos.com/kb/127521
-----------------------------------------


The KBA also links to a Microsoft page that describes what needs to be done in order to prepare the SQL server for TLS 1.2:
https://support.microsoft.com/en-us/help/3135244/tls-1-2-support-for-microsoft-sql-server

However, no joy for me at this point. I try to follow this article to see what version of TLS is really being used:

http://www.sqlservercentral.com/blogs/sqltact/2018/01/09/sql-server-on-tls-12-xevent-session-to-catch-tls-in-use/

Still no joy as there is no extended event for “trace” even though the article says SQL 2012 SP4 is supported.

At this point I look to upgrade to SQL 2016 SP1 and realise that a minimum SEC version of 5.4.1 needs to be installed.

I first verified a successful upgrade to SEC 5.4.1, and then went ahead and upgraded to SQL 2016 SP1. At this point I can see errors with the SEC connection to the DB and SEC wont open.

So I enabled TLS 1.1 and TLS 1.0 via the registry, rebooted and now SEC is working. I can also trace the DB connections and see that SEC 5.4.1 is using TLS 1.0

I can also verify that the SQL mgt studio is using TLS 1.2

Now when I run the installer DBcheckconnection I can a much better outcome.

(/) Operating system is ready to use TLS 1.2

(/) Installed .NET Framework supports TLS 1.2

Connection to the SQL Server established

(!) SQL Server instance can be configured to use TLS 1.2

(/) SQL Server TCP/IP protocol is enabled

(/) There is a certificate installed that can be used with SQL Server

(/) SQL Server Native Client library supports TLS 1.2

Encrypted connection to the SQL Server is established

Upgraded to version 5.5.1

SEC still connecting to DB using TLS 1.0, even after removing the registry entries.

So to me it looks like SQL 2012 SP4 does not support TLS 1.2 as everything is working fine when I upgraded to SQL 2016 SP1. However, I still need to find out why SEC is still connecting using TLS 1.0. I'm in the process of taking this back to support now.

regards,

Grant

Hi guys,

apologies but I didn't remove the registry entries properly. Once I did, I was back to getting a DB connection error:



Back to the support team.

regards,

Grant

Hi Grant, 

thank you for the detailed post about your procedure. I think ill also upgrade to 2016 to see if it helps. 

Let us know how you get on. 

Cheers

Hi guys,

So the last thing I have done is the usual SDU logs to the support team, who will probably take them to the product team. On the brightside at least it's now running the latest version of SEC.

Ta,

Grant

Hi guys,

not much to add to the Friday afternoon wrap up, other than I've been told that the incident has gone to GES engineers, who, "are the highest technical tier within support and are responsible for interacting with our development teams".

Should have some better information next week.

have a good weekend.

Grant

So ?

Paul Jr 

Hi guys,

sorry for the delay but this has turned into a bit of an annoyance. Anyway, long story short I upgraded to 2017 without any change in behaviour, I identified the client connections to the SQL box and realised Sophos was using 2 different client libraries (of which one is not TLS 1.2 compliant). So now I am trying to figure out if there is TLS 1.2 support for this driver, or that Sophos needs to update the parts of the application that is using SQL OLE DB connection strings as per this article from Microsoft tech team.

https://blogs.msdn.microsoft.com/sqlreleaseservices/released-microsoft-ole-db-driver-for-sql-server/

At this point I’m not sure as I do not know the exact provider they are using.

It's worth noting that this was done in a DEV environment and I ran up a fresh Windows 2016 with SEC 5.5.1 and got exactly the same behaviour.

Below are some notes I made to get to this point.

--------------------------------------------------------------------------

R&D team’s answer to support is to follow the articles and to speak to Microsoft and SQL experts:

-----------------------------------------
Article ID: 127521
Title: Enterprise Console - Database connection check
URL: https://sophos.com/kb/127521 
-----------------------------------------

-----------------------------------------
Article ID: 131698
Title: Sophos Enterprise Console - How to create the required certificate package to allow TLS 1.2 connection to the database
URL: https://sophos.com/kb/131698 
-----------------------------------------

Sound familiar?

Okay, so from here I decided to upgrade to SQL 2017.

Next time to find out exactly what are the connections to the database by application and driver.

Sp_who2

This shows applications accessing the Sophos DB and if we follow SPID 57 & 60 we see 1 is SQLNCLI and the other is “Sophos EndPoint Management”. So lets follow those 2 into the activity monitor.

Activity monitor reveals the same information ass sp_who2 and now we follow the session ID to find out what drivers are being used by the applications.

Using this article we find the driver versions:
https://www.mssqltips.com/sqlservertip/2198/determine-which-version-of-sql-server-data-access-driver-is-used-by-an-application/

Now we can see that session ID 57 and 60 are using different client libraries as per this article

https://msdn.microsoft.com/en-us/library/dd339982.aspx

So now using SQL profiler, the trace reveals that both these session ID’s come from the same ClientProcessID 2112

Now task manager will show us what process 2112 actually is:

So it appears that MgntSvc.exe or “Sophos Management Service” is making SQL connections using 2 different client libraries. Of which the “SQL 2000” driver connection made by the application name of “Sophos EndPoint  Management “ does not support TLS 1.2.

It would appear that this connection is a SQL OLE DB TLS 1.0 connection as illustrated when using a test connection and generating the same error.

Do Sophos need to update the connection string as per this article?
https://blogs.msdn.microsoft.com/sqlreleaseservices/released-microsoft-ole-db-driver-for-sql-server/

At this point I’m not sure as I do not know the exact provider they are using, will pose question to tech support.

Have you run the CheckDBconnection.exe -a to setup the SQLNLI connection string

The tool has two working mode. The default is checking the system for TLS 1.2 compatibility (system check mode). The second performs the database settings modification (apply mode: -a).

Hi Dominic,

Where have you been all this time! No I did not see that a tool called CheckDBconnection.exe is used to change the SQL provider. I've just gone back to check that article and can now see that they have it in the guts of the tool info.

Looks like a real silly place to put it to me as I missed it entirely. Not sure why it is in a list of a parameters for an article called DB connection check. Not sure why there is nothing in the setup to tell you that you need to convert the connection string, or even clear steps in that article outlining;

1. upgrade

2. db check

3. convert connection string

Thank you, you've saved me a lot of grief as I knew it had to be that, now that I realise this tool is not to check, but to change the SQL connection string I will go back and do exactly that.

And just like that, I've disabled TLS 1.0 & 1.1 after changing the connection string and everything works as expected.

Really not a fan of that documentation. 

Many thanks again!!!

Grant