Kaspersky Web Control and Antivirus seems to block SSO communication with UTM Proxy when using https

It sounds like Kaspersky implements some form of certificate pinning, so it is detecting the Sophos CA as a hijack attempt.  Check with their support about which of their nany features needs to be turned off.  Possibly they provide a special way to make the Sophos CA teusted.

Sophos changed their cettificate generation to use SAN instead of common name, to male Chrome happy.  This may have something ti do with Kaspersky failing about the same time.

It sounds like Kaspersky implements some form of certificate pinning, so it is detecting the Sophos CA as a hijack attempt.  Check with their support about which of their nany features needs to be turned off.  Possibly they provide a special way to make the Sophos CA teusted.

Sophos changed their cettificate generation to use SAN instead of common name, to male Chrome happy.  This may have something ti do with Kaspersky failing about the same time.

We‘ve upgraded some clients to the latest Kaspersky version and this seems to help, too.

I have not used Kaspersky in several years, but it seemed like they tried to cover many features, so they may have an https inspection module as well.   If so, that is probably the module that needs to be disabled to allows UTM's https inspection to work.

We are not using https inspection. Just the URL filter.

Because Sophos is downgrading TLS encryption, too.

What do you mean about Sophos downgrading encryption?

Like this:

I am familiar with this material, which is a warning that you need to inspect your HTTPS inspection implementation, not a warning to avoid its use.   I have used UTM with and without HTTPS inspection.   Chrome 58 forced me to turn it off and unstable UTM updates have prevented me from using the newer versions.   If you are a member of ISC2, I have an article on the technology (but not the UTM implementation) appearing in this months issue.

Unlike the primary fear in the UT-CERT link, UTM not only enforces certificate chains, it enforces them too strictly.   Many sites have missing intermediate certificates or included root certificates.   Missing intermediate certificates can be obtained using AIA fetching, which is why the problem is not visible in any major browser.   UTM does not have the feature, so it blockes these sites.   Included root certificates can be ignored if the root certificate is already installed on the receiving device, but the OpenSSL version used in 9.4 did not have the logic to do so.  As a result, any chain that ended with a root certificate was blocked because of the self-signed cert.

The secondary fear is that HTTPS inspection will be implemented with a weak ciphersuite, which involves several concerns:

(1) Does the inspection device implement the newer ciphersuites?  

(2) Does the device disable insecure ciphersuites so that it will not be subject to a downgrade attack?

(3) Does the device support internal connections from internal devices using less desirable ciphersuites so that the device can upgrade them to secure ones before the traffic enters the internet?  

(4) Does the device provide ciphersuite visibility and control, so that risks 2 and 3 can be managed?

Regarding UTM, the core capabilities are determined by the OpenSSL layer in use, and for 9.4, the answers are:

(1) The available ciphersuites are extensive and appropriate.

(2) The available ciphersuites can be configured from the shell environment with help from Sophos support.   One article on this topic specifically cited UTM for having RC4 enabled for outbound connections.   I think this default setting has changed but I know it is configurable in the shell.  UTM has already disabled TLS 1.0 by default in one of the 9.4 releases.

(3) UTM accepts connections from IE8 on Windows XP, so that those connections are upgraded to TLS 1.2. 

(4) Visibility to the ciphersuite logic is poor, because it is buried in the configuration scripts.   Posts in this blog indicate that this is changing in 9.5, but perhaps only for implementations on AWS.   It has been awhile since I visited these issues with support, and I am currently unclear whether the inbound cipherset is configured separately from the outbound cipherset.  If they are the same, it will be difficult to both support legacy configurations and prevent downgrade risk exposure.  I know that the WAF ciphersuite was configured in a different place than the Web Proxy ciphersuites.

The important part of https inspection is that it implements centralized policy.   Get it right and it is right for everybody.   Yes, if you get it wrong it is wrong for everybody, but getting it right is why we have jobs.  Need an exception?   Implement it centrally instead of letting each user decide policy.

The related issue is logging and filtering.   Researchers says that over 50% of internet web traffic is https, and my data says that business internet traffic is even higher.   LetsEncrypt allows bad guys to encrypt for free.   If you don't have https inspection, you lose almost everything useful for assessing compliance with Appropriate Use policies, and you lose almost any ability to defend against bad or unwanted content in web sessions.  We use web filtering because experience has proven that antivirus software is inadequate protection against web-based threats.   Any security strategy that depends on having every desktop equally secured is going to suffer from too many gaps in coverage.  

HTTPS inspection is essential t your security.  There is active discussion right now between the banks and IETF because the TLS 1.3 draft would break most every implementation of HTTPS inspection, and they need it for regulatory compliance. 

1.) Two sides of a medal, security and privacy.

2.) Vendors of https inspection proxies are always a little bit late implementing new ciphers and protocols.

3.) IETF has voted against these downgrade of TLS 1.3.

I like that because if I can do MITM in the company, everybody with an official CA (compromised or let‘s say from China) can do this.