Improper handling of HTTPS inspection and bypass

[Vladimir]

I believe this subject being periodically brought-up with no resolution to date:

Exception rules in the HTTPS inspection are not working properly (R80.40 JHFA91).

When Kaspersky Total Security product behind CP gateway attempting to download updates, the process is failing with "Invalid certificate" logged.

Exception for bypass is in place and we are seeing only first packet subjected to it.

Unless there is a resolution to this issue, it is difficult to recommend HTTPS inspection to be turned on and, as a result, the overall effectiveness of the product is greatly diminished.

Does r81.X handle HTTPS inspection differently, or similar behaviour to be expected?

Thank you,

Vladimir

[PhoneBoy]

We do typically validate the certificates being used as part of SNI verification.
Perhaps they are using a private certificate and doing certificate pinning.
In that case, bypass is your only option. 
Is that working correctly or are you still having issues even with a bypass rule there?

The main thing R81 adds is TLS 1.3 support (if USFW is being used).

[Vladimir]

In my case, there is a rule to bypass the *.kaspersky.com in place.

The issue is twofold: the bypass does not work, (the AV is trying multiple update servers sequentially, but only first packet of the overall attempt is inspected, as per logs), and the log indicates that the certificate is invalid. This is all in R80.40 though, did not get to try it in R81.X.

Even if the issue is the certificate pining by the vendor and IF R81 does handle it differently, R80.40 is still the recommended version.

[Martin_Raska]

Maybe they are not doing SNI, try bypass with src IP - dst IP.

[Vladimir]

Kaspersky publishing list of names for the update servers and discurages use of IP addreses:

https://support.kaspersky.com/us/common/start/6105

[Norbert_Bohusch]

How is the bypass configured?

With a custom URL or by domain objects?

If it is custom URL, try adding "kaspersky.com" to the object as well, not only "*.kaspersky.com".

edit:

btw. this is documented here: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[Vladimir]

@Norbert_Bohusch , I've tried all possible combinations including the ones you are mentioning as well as regex \/kaspersky.com and \.kaspersky\.com.

[doraskayo]

Hi Vladimir,

All of the replies so far were on point, but I'd like to clarify a few points:

1. In order to do SNI-based matching (Custom Application/Site object), the server certificate must be valid. We must use a reliable source for the identity of the server. If we trusted any SNI presented by the client, our solution would be vulnerable to domain fronting.
   
   • If you see the logged certificate logged as invalid by the Gateway, it means that the server certificate is not considered valid for some reason. There are a few potential reasons for a server certificate not to be considered valid, including being untrusted, malformed, not signed by its issuer, expired, revoked, missing critical fields, etc. Unfortunately the log does not currently provide detailed information on this regard. It actually provides more information if the specific case is set not be dropped in HTTPS Inspection's configuration in SmartDashboard.
     • The most common reason for a certificate not being trusted is the HTTPS Inspection Trusted CAs being outdated. Have you updated it recently? (the option is also in SmartDashboard)
2. The alternative of SNI-based matching is IP-based matching, which includes IP-based objects such as Host and Domain objects. Specifically, Domain objects are DNS-based and should correctly infer the IP addresses of a provided domain.
3. The issue of the first connection not being matched could be related to background handling of categorization in URL Filtering. Is this something which negatively affects user experience?
   • Most TLS clients attempt to establish a connection with the server at least a few times before alerting the user and giving up, so this is usually not an issue.
   • You can try changing the relevant setting to Hold rather than Background. Make sure the similarly-named setting in HTTPS Inspection's configuration in SmartDashboard is also set to Hold.
     • Note that this will negatively affect latency of every first connection to each unique destination, as the connection is held until all the input required for an accurate rule match is gathered.

As always, opening a support ticket may provide a more specific solution to your issue, but the above is a general idea of the most common options.

Thanks,
Dor