Websites using TLS 1.3 are not categorized correctly using "Categorize HTTPS Sites" feature

[Wolfgang]

Following Websites using TLS 1.3 are not categorized correctly using "Categorize HTTPS Sites" feature ...

Will be there a solution with R81.20 or one of the newer Jumbo Hotfixes ?

HTTPS inspection of TLS 1.3 will inspect TLS1.3 traffic but we don't want to enable HTTPS inspection.

[PhoneBoy · Accepted solution]

A feature of TLS 1.3 is that the SNI information is also encrypted as well.
As such, full HTTPS Inspection is required for TLS 1.3 connections.

[Wolfgang]

@PhoneBoy thanks you‘re right, I forgot this. And checking the sk again, everything was there…

• The "Categorize HTTPS Sites" feature does not validate SNI against the encrypted certificate

[matangi]

Hi @Wolfgang 

Thanks for your valued feedback

The "Categorize HTTPS Sites" feature does support TLS 1.3 starting from R80.30

We improved the SK, refer sk163515 - Websites using TLS 1.3 are not categorized correctly using "Categorize HTTPS Sites" featu... 

Thanks,
Matan

[Tobias_Moritz]

Sorry, but I have to disagree with @PhoneBoy here.

TLS 1.3 encrypts part of the handshake, that is true.

But SNI is NOT encrypted with TLS 1.3 by default.

SNI is only encrypted, when ESNI feature is used. This features is optional in TLS 1.3. When looking what is currently used in the wild, I see TLS 1.3 in use somewhere but almost no ESNI.

Looking at the implementiation at Check Point gateways: The "Categorize HTTPS Sites" feature looks at the SNI (still possible with TLS 1.3 without ESNI), checks the server cert for validity, trust against own trust store and  matching with SNI (not possible anymore with TLS 1.3).

While it is true, that the gateway cannot read the server certificate anymore without full HTTPS inspection, it still can read the SNI.

So Check Point R&D should be able to implement some kind of lite flow for TLS 1.3 to "Categorize HTTPS Sites" by just looking at the SNI, when ESNI is not in use.

Of course, this does not provide the same security like in TLS 1.2, but is better than 'we do not support "Categorize HTTPS Sites" feature with TLS 1.3 at all'

@matangi : What do you think about that?

[_Val_]

Your statement is only partially correct. Although the first packet in TLS 1.3 is not encrypted, and you indeed can look at client side of SNI, to validate that from the server side, you need the server cert, which is part of encrypted traffic already. Reading SNI is not enough to enforce SNI, as our SNI enforcement feature goes way beyond that. We compare SNI with actual server data, to make sure it is not spoofed. 

[Tobias_Moritz]

Thanks for the fast response, Val.

But didn't I say the exact same thing like you do?

Yes, current Check Point implementation does not only look at SNI (in first packet) but also validates it against the server cert (and do some more checks on the server cert, second packet). Yes, this full implementation is not possible anymore with TLS 1.3. But it would still be possible to just look at the SNI. Not perfect, but better than not beeing able to parse it at all.

Full HTTPS inspection is not possible or allowed for every environment, so this "Categorize HTTPS Sites" feature is really usefull (at least since it got SNI support a long while ago).

[Chris_Atkinson]

For mind it's not trustworthy without validation, hence the effectiveness might be considered questionable and possibly prone to bypass.

In such a case this would not be considered adequate from a security perspective. 

[_Val_]

The validation only works if we can compare SNI in the client request with the server's cert. We can "look" on client side SNI, but we cannot act on it, it is not reliable and often spoofed to trick other, less meticulous security solutions. 

Say, if your bot malware spoofs itself as e-banking traffic, you do want to categorize it based on the server response, to make a correct security decision. With TLS 1.3, it is only possible, if you enable HTTPSi. 

With anything less than that, 1.2 and below, sure, not full TLS inspection is required, as the server's cert is not encrypted.

That's exactly what Phoneboy pointed out above. SNI based categorization for TLS 1.3 traffic requires TLS inspection.

[Tobias_Moritz]

Thank you all, for your fast and well-founded responses.

You say that you do not want to implement what I suggested because this is not secure and you do not want to provide a feature which can be quite easily circumvented. That totally makes sense.

I think thats one thing this community is for: to discuss! So thank you for that 🙂