Quic protocol

[rafish]

Hello,

I have cluster active/standby 23800 appliances the version is Gaia R80.40

My problem is that QUIC protocol is not working,

The Checkpoint cluster is perimeter firewall, which means all my Internet traffic goes via the checkpoint.

Google sites work with QUIC ,

The issue is when I'm surfing to Google from my organization I can only see that the connection authentication use TLS 1.3 and not QUIC authentication'

I configured rule with QUIC protocol service but still the connection authentication use TLS 1.3

Any idea ?

Regards

Rafi

[_Val_]

Do you have HTTPS Inspection enabled?

[rafish]

Sorry forgot to mention,

No, I don't have HTTPS Inspection

[_Val_]

Without HTTPSi we do not interfere with Quic, it should normally work. Are you sure this is FW that is causing the issues?

[rafish]

I done some tests that lead me to to checkpoint,

I will check again

[_Val_]

@rafish Just to be sure, if you believe this is a firewall, check for drops of quic traffic on the GW. If you see some, looking at them might help you to understand what to do.

[rafish]

I found the problem,

I have application rule that allow "Google Ads" which include service udp 443,

I added to specific application rule "Quic protocol" and when I surf to google site with chrome I can see that the encrypted and authenticated using QUIC

Thank you very much

[Sorin_Gogean]

hey,

good to know, but if I may ask, why are you looking into allowing quick protocol?

I'm just asking, because there are some recommendations for dropping that traffic ( not only from CheckPoint side) and currently I don't see many reasons why would you do that.

Also another one that we're dropping, is DNS over HTTPS (DoH) , as it would overcome DNS security settings that you would have set in your environment.

Ty,

[PointOfChecking]

Hi _Val_,

Is Checkpoint able to inspect Quic traffic now?  As another commenter mentioned, I've been advised that Quic should be disabled to force the client to failback to TCP traffic.

Quic is not inspected, so traffic that is normally blocked cannot be blocked?

[Chris_Atkinson]

QUIC inspection is on the roadmap planned for a future release.

If a browser cannot talk via QUIC it will generally failback to traditional protocols. Provided Https inspection is enabled then inspection on the subsequent connection is possible. 

[PointOfChecking]

Thanks Chris,  that's the advice I received previously, so I blocked Quic on the FW.  However, I'm recently getting a lot of complaints that various websites are not loading.  When I reenable Quic again, the websites load Ok again.

We have HTTPS enabled and working with no problems.

Something I could be doing wrong?

[Chris_Atkinson]

Which gateway version and JHF?

Regarding your Https inspection config is the trusted CAs list updated and are you bypassing known troublesome sites using the updatable objects provided?

[PointOfChecking]

using 4800s on latest R80.40 JHF

CAs updated automatically.

Not using updateable objects for troublesome sites.  Any guides on this?

Also, if I'm bypassing sites, then it's a lot of sites to bypass.  People were calling constantly when it was blocked.

[Chris_Atkinson]

Please see sk163595 for more information on the bypass list objects. 

Moreover please ensure OCSP traffic is allowed if not already.

If the problem persists please engage with TAC to discuss/diagnose the issue further.

[PointOfChecking]

HI,

The original problem is Quic traffic is not inspected.  Which is why we block Quic to force it to failback to TCP.

If I bypass inspection of the traffic using updateable objects, I may as well allow Quic traffic?

[Chris_Atkinson]

No this isn't the correct logic, not all HTTPS traffic can be inspected for example pinned certificates and various other factors may require some sites/categories to be bypassed e.g. banking & healthcare sites for privacy reasons. From time to time compatibility and cipher issues may also arise...

So the idea is to minimize user impact and inspect what you can to provide an appropriate level of security.

[PointOfChecking]

Sorry, let me check if I understand correctly.

Quic traffic CAN be inspected? Just that not all Quic traffic can be inspected?  It's those that cannot be inspected that are failing?

I should allow Quic traffic and create updateable objects to bypass inspection of Quic traffic that is failing?

[Sorin_Gogean]

Hello @PointOfChecking ,

As @Chris_Atkinson was stating above "QUIC inspection is on the roadmap planned for a future release." so it's not inspected right now by HTTPS Inspection. 

Another confusion you do, is that you got the recommendation to Block Quick protocol, in order to FORCE traffic to go over TCP/443 as that can be inspected, and in order to respect "GOOD Practice" you're recommended to set HTTPS Inspection rules to bypass "HTTPS services - recommended bypass" and "HTTPS services - optional bypass" (from sk163595) and if you can, use Updatable Objects and not be static here. Still I don't remember those objects being available in R80.40 in old days (like 2-3 years ago).

Now, on your problem, you say that you blocked Quick protocol, and some of your users are still facing issues, and complain to you. Can you give more details on that, like what are those sites, what were the issues faced by the end-users?

We have Quick dropped since couple of years, and I don't remember hearing complains.

Thank you,

[PointOfChecking]

Thanks for your reply.

This is the part that I can't understand.  If checkpoint cannot inspect quic and I already dropped quic, why do I need to bypass anything because checkpoint can inspect TCP HTTPS, so no need to bypass?

If I allow quic and checkpoint cannot inspect anyway, again why do I need to bypass?

When I allow quic, then the website loads for the users.

When I block quic, then the website fails to load.

Many websites failed, but I can't remember which one they were (as this was a few weeks ago).

As soon as I allowed quic, then all sites were working again.

[_Val_]

@PointOfChecking HTTPSi enforcement happens before your regular Network Security Policy rulebase filtering. You want to bypass anything you do not wish to enforce, otherwise, your GW will spend (and fail in the case of QUIC) a significant effort to decrypt traffic that will be later dropped anyway.

I hope this makes more sense to you now.

[PointOfChecking]

Thanks Val, that answers the second part of my question

"If I allow quic and checkpoint cannot inspect anyway, again why do I need to bypass?"

how about the first half?

"This is the part that I can't understand.  If checkpoint cannot inspect quic and I already dropped quic, why do I need to bypass anything because checkpoint can inspect TCP HTTPS, so no need to bypass?"

Is it because "HTTPSi enforcement happens before your regular Network Security Policy rulebase filtering."?

[_Val_]

No, I answered both parts. But let's clarify.

TLS inspection effort is defined by HTTPSi rulebase. Traffic filtering is enforced by the network security policy. 

HTTPSi enforcement happens way before Network filtering takes over and drops something.

For all TCP-based unsupported TLS traffic (mostly for that with certificate pinning), it is the best practice to bypass it in HTTPSi rulebase, to save a decryption effort that will fail anyway. Same applies to traffic you know will be dropped by network security rulebase. The best way to do that is to describe explicitly only the traffic you want to decrypt and bypass any other web traffic on Bypass cleanup rule.

In the case of QUIC, it is UDP, not TCP, port 443, and now HTTPSi does not support its decryption. My personal understanding is, there will be no decryption effort on QUIC at this point, so you do not have to create a targeted bypass rule with any of the supported releases. However, the situation is changing rapidly, and it is possible that UDP-based HTTP/2 will enter the picture at some point, with one of HFAs.

For that matter, making sure it is bypassed will not hurt. 

However, if you are looking for the official best practice recommendation, and not yet another personal opinion, please open a TAC case: https://help.checkpoint.com 

[PointOfChecking]

Thanks for the explanation.

So I should not drop quic traffic, I should bypass it's inspection in HTTPSi because it can't be inspected anyway?

This goes against the other generic recommendations (from a few other firewall manufacturers), that we should drop quic so that the connection fails back to TCP so that it can be inspected?

Also, once UDP-based HTTP/2 will enters the picture, I should allow its inspection right?

[_Val_]

I have a feeling we are going in circles here 🙂 

If you drop QUIC in your network security rulebase, it will indeed fall back to TLS and then traffic can be inspected. Same approach with all the vendors, Check Point included. You can see full set of recommendations for handling QUIC here: sk111754
It is also mentioned in the HTTPS Inspection Best Practices SK: sk108202

Please work through both SKs. If you have more questions afterward, please let me know.

[PhoneBoy · Accepted solution]

QUIC traffic is completely opaque to us.
There is no way currently to:

• Decrypt QUIC traffic (i.e. with HTTPS Inspection)
• See the website(s) being browsed over QUIC 

Which means: if you care about the kinds of websites your end users attempt to access (e.g. you block access to porn), you should block QUIC.
This is irrespective of whether or not you use HTTPS Inspection. 

[Oliver_222]

Good afternoon

Can you please tell me if HTTPS inspection will work correctly when the connection is already via TCP 443?

We have QUIC blocked. User has Bypass configured in https inspection. In logs we see reject QUIC and then Bypass log with Alert. And we see the error: ‘The probe detected that this destination cannot be inspected and its identity cannot be verified due to a TLS alert (TLS alert: protocol_version)’.
What can this be related to?

[_Val_]

See if it uses TLS higher than supported on your FW. Which FW version are you running?