Sophos Authentication Client for Remotedesktopserver / Citrix ( SATC) for Chromiumbased Browser >= Version 84

Stef_An, you are not the only one experiencing this problem.  I am the one who identified the issue, which first appeared in variants of Chrome v72 as early as February 2019.  I'm also the one who opened the support case with the Chromium group referenced in the Sophos KB article, and got the Chromium group to add the ForceInNetworkProcess flag to alleviate the problem.  At the time, I was advised by the Chromium Dev Group that the fix was only temporary and at some point in the future all chromium-based browsers would no longer support the Win32 network stack.  Software, like SATC which hooks the Win32 network stack, would no longer work.  Back in February of 2019, I advised Sophos of this and facilitated direct communication between Sophos and Chromium engineers.  So, Sophos has had over two years to address this issue.  Yes, the fundamental architecture of SATC is flawed.  Hooking the Win32 network stack is not a viable option.  But, this is something Sophos has known for a long time.  They have chosen to ignore the issue and allow the temporary workaround provided by the Chromium Group between v72 and v83 to expire.  Now we're two major releases of the browser behind current, and still nothing is fixed.  Yes, this is a re-write and complete re-thinking of the entire SATC product, but Sophos has had ample time to come up with a solution.

I understand this is something on the roadmap for H1 2021.  My question is what is it?  How will it work?  If you can't hook the Win32 network stack, what will you do to identify users?  Will this be a direct replacement for SATC or some new software with its own set of issues and implementation challenges?  Two years and only waiting.  I'd like to know from a technical standpoint what's planned.  Support for firewall authentication on terminal services is an absolute must for our organization, and our future with Sophos depends on it.

Hi Patrick,

The new solution will be integrated into our Server Protection.

SATC works by intercepting attempts by applications to send network traffic within the Windows operating system at a point where it can also discover which user account is responsible for sending the traffic. When a new connection is detected, SATC sends a message to the firewall containing the name of the user account along with information allowing the firewall to identify that connection when it sees it (i.e. source port, destination IP and destination port) and 

The current SATC makes use of a method called 'Detours' to hook API calls at the user level. It intercepts at the point where the application calls into the Windows networking APIs. This method does not work with the new Chrome networking service. I'm not 100% sure of the reason, but I believe it's that Chrome now takes a different route to communicate with the TCP networking stack and so bypasses the points at which Detours would allow SATC to intercept the function calls.

The new solution leverages the existing lower-level interception done by Sophos Endpoint products to deliver network traffic detection and web filtering in the endpoint. This interception uses a driver-level method called Windows Filtering Platform, which is specifically designed for enabling the kind of network traffic interception and filtering that we need to do here. It sits below the level of Chrome's networking components and so allows us to treat Chrome traffic the same as any other client. In the solution coming out soon, it will still use the same network protocols to pass information to the Firewall so the new solution will be compatible with any currently supported version of SFOS.

One huge benefit of this method is that it also solves a long-standing issue where Server Protection's web filtering and download malware scanning would prevent SATC authentication working correctly.

Longer term, we plan to roll this functionality up into our Heartbeat authentication as part of the Synchronized Security suite. At the moment Heartbeat Authentication is geared around providing one identity at a time per IP address and so it's not suitable for use on multi-user systems like Windows Remote Desktop. But Synchronized App Control already requires a similar kind of message to be sent with information about the process on the Endpoint that created a connection. We plan to extend that to include user information as well, removing the need for a separate SATC component. However, for this to be effective for authentication we also need to complete some work to ensure that those messages arrive in a timely fashion. We don't have a firm date for this yet.

Obviously, this is not ideal for customers who for whatever reason cannot use Sophos Server Protection on their Remote Desktop servers. We are planning an alternative feature for version 19 of SFOS which will provide per-connection proxy authentication. In these, and other situations where SATC can't be used (e.g. Windows Direct Access, or multi-user Linux hosts) per-connection proxy authentication will allow customers to configure direct proxy settings and use proxy authentication to identify each user's traffic.

Thanks for the Message. 

But whats with the Customer which Cant use "Sophos Serverprotection" / Heartbeat and Synchronized Security suite ? maybee the have an other suite or no licenses .  For exaomple : the use Trendmicro on Client / Server Side. How do the solve the Problem without a Complete sophos suite?

Next think: Frome my side this is NOT SOLVED, please didn't mark may Threat as SOLVED!!

Thanks for the Message. 

But whats with the Customer which Cant use "Sophos Serverprotection" / Heartbeat and Synchronized Security suite ? maybee the have an other suite or no licenses .  For exaomple : the use Trendmicro on Client / Server Side. How do the solve the Problem without a Complete sophos suite?

Next think: Frome my side this is NOT SOLVED, please didn't mark may Threat as SOLVED!!

The same goes for me. User authentication (I am referring to terminal servers) if advertised, it must be done without residing on endpoint security products of the same vendor, unless specified in the advertisement. Maybe I'll be wrong but having two thinking heads independently (i.e. two antiviruses - one firewall side of vendor1 and one endpoint side of vendor2) gives me more security. If vendor1 misses intercepting a threat it is highly likely to do so for both cases (both firewall and endpoint level). The top of the top would be to let them communicate with each other (but I doubt you can get to that - and not for technical reasons). At this stage marketing prevails on the technical side.