Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Wolfgang
Authority
Authority
Jump to solution

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

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.

0 Kudos
1 Solution

Accepted Solutions
PhoneBoy
Admin
Admin

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.

View solution in original post

9 Replies
PhoneBoy
Admin
Admin

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
Authority
Authority

@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
0 Kudos
matangi
Employee
Employee

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
Advisor

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_
Admin
Admin

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. 

0 Kudos
Tobias_Moritz
Advisor

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
Employee Employee
Employee

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. 

CCSM R77/R80/ELITE
_Val_
Admin
Admin

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.

0 Kudos
Tobias_Moritz
Advisor

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 🙂

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events