topic Re: Chrome Quic SSL proxy / deep inspection in General Topics

Chrome Quic SSL proxy / deep inspection

Alex_Samad — Fri, 03 Aug 2018 03:09:35 GMT

WOndering when / if PA's will handle QUIC the same way it handles web-browsing / ssl ?

Alex

Re: Chrome Quic SSL proxy / deep inspection

bbilut — Fri, 03 Aug 2018 15:25:20 GMT

As far as I'm aware the PA can not decrypt QUIC. I have a Chrome group policy on my environement disabling QUIC in the browser and I block QUIC high up in my rules which would causes Chrome to fail back to SSL.

Re: Chrome Quic SSL proxy / deep inspection

BPry — Fri, 03 Aug 2018 15:53:55 GMT

@Alex_Samad,

There are technical limitations in decrypting QUIC traffic due to the use of multiplexed connections and proprietery encryption methods. Visibility into this traffic is therefore limited and does not allow the firewall to decrypt this traffic.

My suggestion would be to block QUIC if you need visibility into the traffic. Since QUIC is still technically in development it would additionally be recommend that you create one rule that blocks application 'quic' on service 'application-default'; and then block udp-443 and udp-80 depending on your requirements. If Google updates QUIC it may be that the app-id drops back to unknown-udp, depending on your logging/security requirements this may/maynot be acceptable to you.

Re: Chrome Quic SSL proxy / deep inspection

OtakarKlier — Fri, 03 Aug 2018 19:55:45 GMT

Hello,

We block it without any issues. PAN also says block it:

In Security policy, block Quick UDP Internet Connections (QUIC) protocol unless for business reasons, you want to allow encrypted browser traffic. Chrome and some other browsers establish sessions using QUIC instead of TLS/SSL, but QUIC uses proprietary encryption that the firewall can’t decrypt, so potentially dangerous traffic may enter the network as encrypted traffic. Blocking QUIC forces the browser to fall back to TLS/SSL and enables the firewall to decrypt the traffic.

https://www.paloaltonetworks.com/documentation/80/pan-os/pan-os/decryption/define-traffic-to-decrypt

Re: Chrome Quic SSL proxy / deep inspection

Alex_Samad — Fri, 03 Aug 2018 20:49:20 GMT

Yes I know that, but i would have presumed over this time PA might have spent some time to do inspection. Its an open spec ?

Alex

Re: Chrome Quic SSL proxy / deep inspection

BPry — Sun, 05 Aug 2018 20:21:08 GMT

@Alex_Samad,

Last I looked at the protocol in depth the encryption method Google was using was still proprietary.

Re: Chrome Quic SSL proxy / deep inspection

Remo — Sun, 05 Aug 2018 21:52:32 GMT

@Alex_Samad

For PaloAlto it is probably not worth spending money/time on something that 1% of webservers use

Re: Chrome Quic SSL proxy / deep inspection

Alex_Samad — Sun, 05 Aug 2018 21:56:12 GMT

I would have thought PA and google would have some sort of working relationship.

Guess it would be in googles interest as well. otherwise sys admins like me are just going to block it..

Re: Chrome Quic SSL proxy / deep inspection

Alex_Samad — Sun, 05 Aug 2018 21:58:34 GMT

If/when it becomes more main stream wouldn't it be rather late.

I get the impression PA haven't taken a rather big bit of the pie and some rather basic things have been forgotten. Not this, but have you triee renewing a cert with altname attributes - doesn't work in PA, the PA's drop the alt attributes. Not a main thing but a rather silly thing to forget to do and I am told its not a trival thing to fix for PA ... sigh ....

If it speeds up browsing when will it go from 1% to ...

Re: Chrome Quic SSL proxy / deep inspection

Remo — Sun, 05 Aug 2018 23:12:02 GMT

I agree with the point about some (basic) things. Some of them are silly bugs and some of them features that would be nice.

PA and Gpogle have some sort relationship with the deployment of paloalto firewalls in the google cloud, but with Quic I think Google simply does not really care. Their goal is to make browsing fast and secure. A Man-in-the-middle per definition isn't that 😛

But about Quic itself, I personally don't think this will rapidly grow (it made 0.2% in the last 8 months). Yes, quic does speed up browsing and adds also some other features, but almost the same you will get with http/2 (official benchmarks show that browsing with http/2 AND TLS encryption is faster than http 1.1 without encryption). And http/2 is already at 28.9%.

One really big thing(/problem) for Paloalto will be TLS1.3 ...

Re: Chrome Quic SSL proxy / deep inspection

TyronF — Thu, 21 May 2020 15:21:18 GMT

Ok so what now that HTTP3 is based on QUIC?

Re: Chrome Quic SSL proxy / deep inspection

JoeKwok — Wed, 29 Jun 2022 10:30:10 GMT

Hi All,

Nowadays, HTTP/3 is announced which runs over QUIC and according to W3Techs HTTP/3 is used by 25.1% of all the websites. (on 29-Jun-22, https://w3techs.com/technologies/details/ce-http3)

I would like to know that is HTTP/3 supported such as SSL Forward Proxy Mode from Palo Alto firewall?

I cannot find any document mention HTTP/3 on Palo Alto Networks.

Since I found that some load balancer such as F5 already support HTTP/3 for load balancing. I think it is similar principle for SSL Forward Proxy?

https://support.f5.com/csp/article/K05822509

QUIC has a "connection ID" instead of traditional IP address used for load balancing

Furthermore, cloudflare also claim that it support HTTP/3 inspection

https://blog.cloudflare.com/cloudflare-gateway-http3-inspection/

Re: Chrome Quic SSL proxy / deep inspection

Ahmed_K — Sat, 28 Oct 2023 19:54:39 GMT

I see how quic has it's used case in the finical, social media, or anywhere privacy is a concern. People would only want to use TLS1.3 for this reason alone.

Gov agency may stick to TLS1.2 until it's deprecated , but that's not something around the corner.

Although there is the question of the free world vs the big brother, and that's why I see how quic can become the norm and will take over quickly than anticipated not just for mobility, fast browsing and communication but mainly for protecting users privacy.