Where is pfSense support for HTTP/3 and QUIC protocol support?

[lohphat]

@johnpoz said in [Where is pfSense support for HTTP/3 and QUIC

How is that exactly?

Most of the QUIC payload is encrypted.

The push for QUIC is that the connection setup is done in one handshake instead of the 3 needed for current TCP+TLS+HTTP/2

Currently browsers which support QUIC also send a TCP 443 connection as a fallback in case the QUIC (UDP 443) packet is blocked.

QUIC is intended to replace ANY TCP connection not just HTTP.

It uses UDP simply to raise the possibility of transit through intermediary routers instead of trying to introduce a new IP protocol number.

The video I posted is an interview with one of the RFC authors David Marx and goes into the protocol level of how it works -- it's a pretty easy video to follow.

The new challenge is that QUIC is already past the 25% mark of total traffic since it's used by the big content providers (Google, FB) and supported by the major browsers. Chrome will flip the setting bit soon to enable it by default.

Here's more info: What is QUIC – This new Google Protocol makes Firewalls Blind

[netblues]

@jknott said in Where is pfSense support for HTTP/3 and QUIC protocol support?:

@netblues

If you're worried about it, you can disable QUIC by blocking UDP port 443.

I know, and this is what will most probably happen in many corporate networks.
I'm just replying to the op, about pfsense roadmap regarding QUIC

[johnpoz]

@lohphat said in Where is pfSense support for HTTP/3 and QUIC protocol support?:

Most of the QUIC payload is encrypted.

So how does that make firewalls useless?

Sorry but lots of traffic is encrypted - doesn't make my firewall useless.. All this is udp over 443.. What it caries or doesn't carry or encrypted or no has zero to do with what my firewall does or doesn't do..

Still blocking or allowing based port, protocol, source IP, destination IP, etc. What the traffic carries has nothing to do with the operation of a L3 firewall.

Click bait all that article is - doesn't freaking make your firewall blind... Doing mitm might of gotten harder, and so called nextgen doing application filters after they have decrypted your traffic by doing mitm in the first place..

There is nothing pfsense needs to do here, L3 is still L3 and you can still firewall on it - pfsense isn't advertising themselves a nextgen firewall doing mitm and filtering on application levels on your connection to google, etc.

[netblues]

@johnpoz Indeed. it just that the firewall industry is moving towards ngfw, which of course pfsense isn't.

Ngfw will most probably have a bad time with QUIC, Lets see how this will unfold

[JKnott]

@johnpoz said in Where is pfSense support for HTTP/3 and QUIC protocol support?:

So how does that make firewalls useless?

It's like trying to block TCP protocols without using port numbers. The actual port number is hidden, so you can't block specific protocols.

[johnpoz]

@jknott said in Where is pfSense support for HTTP/3 and QUIC protocol support?:

The actual port number is hidden

No it isn't - the issue with quic is they are not doing mitm on your traffic so they can not say you can not do application X but you can do Y inside your tunnel..

Pfsense was never that firewall in the first place - nor have I ever seen anything hinted at they would go that direction..

If some corp wants to do mitm on their users - they sure were not using pfsense..

quic has been around for quite some time actually.. Its not new by any means.. 2013 or something so like 10 years..

Its easy enough to stop, just don't allow 443 udp.. Not like bs doh sneaking shit through your firewall by hiding in normal tcp 443 https traffic..

[lohphat]

@johnpoz said in Where is pfSense support for HTTP/3 and QUIC protocol support?:

@lohphat said in Where is pfSense support for HTTP/3 and QUIC protocol support?:

Most of the QUIC payload is encrypted.

So how does that make firewalls useless?

Sorry but lots of traffic is encrypted - doesn't make my firewall useless..

The different is that the session and application details are also obfuscated whereas in TCP there's more to work with in the header to determine what the packet is for -- yes, the TCP payload is encrypted but there's a little bit more to work with to determine what's going on.

Just as when apps started tunneling everything over TCP 443 to get around "blocked" apps, firewalls learned to recognize what was happening. Sure, the payload was obfuscated but there are clues and patterns of behavior which can be decyphered to guess what's happening.

All things change and this is another iteration of change for which we'll have a learning curve on how to handle. Sure we can just disable UDP 443 -- until the execs start bleating that their wifi calls drop and don't renegotiate with the cell network in time and mandate QUIC support.

Wireshark still can't decode QUIC packets fully but is expected to soon.

At some point pfSense needs to at least be able to decode the headers which ARE accessible and provide some controls to stay relevant. Doing nothing is a risky option.

How Google’s QUIC Protocol Impacts Network Security and Reporting

[JKnott]

@johnpoz said in Where is pfSense support for HTTP/3 and QUIC protocol support?:

No it isn't - the issue with quic is they are not doing mitm on your traffic so they can not say you can not do application X but you can do Y inside your tunnel..

Here is a QUIC packet. What protocol is being carried?

[JKnott]

@lohphat said in Where is pfSense support for HTTP/3 and QUIC protocol support?:

until the execs start bleating that their wifi calls drop and don't renegotiate with the cell network in time and mandate QUIC support.

Actually, something similar is already happening with WiFi calling and VoLTE. The calls are encrypted with IPSec and then placed in a UDP packet, which has no problem moving between cell and WiFi networks.

[lohphat]

@jknott Weelll kind of. Wifi calling in some form or another has been around for a decade -- the problem is that when you transition between wifi and cell networks the source IP changes and there needs to be re-negotiation. How fast that happens has been a crap shoot depending on the phone and the carrier.

QUIC makes it even easier for those carriers who allow it as the session ID allows them to auth the call faster than over TCP -- the fractions of a second saved helps preserve the call in more cases and may make the trasnition undetectable for the parties on the call.

[johnpoz]

@lohphat said in Where is pfSense support for HTTP/3 and QUIC protocol support?:

At some point pfSense needs to at least be able to decode the headers which ARE accessible

And where is that happening in pfsense now for https over tcp for example?

[JKnott]

@lohphat said in Where is pfSense support for HTTP/3 and QUIC protocol support?:

Wifi calling in some form or another has been around for a decade -- the problem is that when you transition between wifi and cell networks the source IP changes and there needs to be re-negotiation. How fast that happens has been a crap shoot depending on the phone and the carrier.

No, it works just like QUIC. The data is encapsulated in UDP. The end point addresses for the UDP packet are irrelevant, as the connection is made at a higher level within IPSec. I noticed this effect years ago with VPNs which are often encapsulated in UDP.

I have verified this with Wireshark. One point my cell carrier made, as an advantage of VoLTE was seamless transition between WiFi and cell networks.

[JKnott]

@johnpoz said in Where is pfSense support for HTTP/3 and QUIC protocol support?:

And where is that happening in pfsense now for https over tcp for example?

That's another level up. It's more like https vs http vs ssh over TCP. QUIC is a replacement for TCP and the port number for whatever service is not visible, unlike with TCP. You cannot look at a QUIC packet and determine whether it's https or whatever. You can with TCP.

[johnpoz]

@jknott again what in pfsense can you do now, that you can not do with quic..

How does pfsense fall behind, when I don't see it doing anything now different with any other protocol..

Pfsense is a L3 firewall.. There is nothing in quic that prevents me from doing L3 firewalling.. Just like I can stop tcp 443, to IPs from source IPs from source ports..

I can do the same exact thing with UDP 443.. dest ip, source IP, source port, etc..

What are you saying I can do now with say https on 443, that quic will prevent me from doing?

Where in pfsense can I say hey if on port 80 and its https vs http stop it? I can stop port 80, but where in the rules can it call out hey they are running https over 80 and not http - block it?

[mer]

I ran into this "UDP packets over port 443" a few years ago, I think I may have had a few discussions with @johnpoz about it at the time (5 or more years).
A lesson I learned was "It's your network, it's a good idea to periodically do packet captures on your network and analyze what is normal traffic".

You learn what is normal, what is interesting, what is odd and what is "Oh Crap!"

As for the OP, trivial enough to add a rule to block from any/any to UDP/443.
It's also trivial enough to craft outbound packages that wrap a specific payload/protocol in a standard HTTP/HTTPS packet (how do you think some virus/malware work?)
The problem as I see it, is that companies start putting this kind of stuff in their applications (browsers) without ever getting buyin from users/"the public". Yes, I acknowledge that sometimes a company has to prove a benefit before it's adopted but something like port usage is in theory controlled/monitored by Standards Organizations.

If you're still reading, thanks. I have too many words sometimes. My opinion is monitor your network, learn "normal" and "abnormal", investigate the abnormal, decide what to do about it.

[JKnott]

@johnpoz said in Where is pfSense support for HTTP/3 and QUIC protocol support?:

again what in pfsense can you do now, that you can not do with quic

What could you do in pfSense with TCP, but without port numbers? Could you allow https, while blocking http? No you couldn't because you couldn't tell which is which. The only port number that's visible is UDP 443, which is used as the transport. You see nothing beyond that, whether it be https, http, ssh or ftp. You just can't see it.

Fire up Wireshark, as I did, so you can get a good look at what it is. I provided one example above and you cannot tell me what protocol it is. While today it's a good bet it's https, it could be other stuff too.

[JKnott]

@johnpoz said in Where is pfSense support for HTTP/3 and QUIC protocol support?:

Where in pfsense can I say hey if on port 80 and its https vs http stop it? I can stop port 80, but where in the rules can it call out hey they are running https over 80 and not http - block it?

Strictly speaking that's true and some even run OpenVPN over TCP 443. But that doesn't apply to most traffic, which uses standard port numbers. Again, what you're talking about is done at a higher level. You couldn't even use deep packet inspection, as you might with TCP.

[johnpoz]

@jknott Again what are you not getting.

There is nothing that quic brings to the table that puts pfsense behind.. It wasn't doing any of that anyway..

OP is asking for http/3 quic support in pfsense - for what? Serving up the web gui? There is nothing pfsense can do now that gets removed with quic udp over whatever port..

Its like saying hey my microwave can not air fry french fries, but now they are coming out with onion rings you "could" air fry as well... Your microwave is falling behind because it can not air fry onion rings... It couldn't air fry french fries either, so no its not falling behind.

If you want to air fry something - get an air fryer

Sure quic can be problematic for nextgen firewalls doing application filtering - guess what that has been the case since it came out back in 2012/13 - actual ratification of the rfc doesn't change anything, that quic has been around for 10 years already..

What this has to do with pfsense is what I am trying to understand - because it has zero to do with pfsense from what I can tell..

[mer]

@lohphat What is being asked? To me trying to debug QUIC is like trying to debug https or TLS connections. You can see source and dest, but the payload is a black hole unless you have the correct keys and you know how they are being used. Honestly as long as the ethernet and IP headers are understandable and correct (with matching checksums) I think that's the limit on what pfSense can do.
Type a letter in your favorite word processor. Encrypt it using your GPG private key. Print it, put it in an envelope, address the envelope to someone that knows your matching public key.
That's basically what's happening with QUIC. You see the sender, the receiver, but you don't know about the contents.

Can that make debugging and security harder? Yes.

[michmoor]

@netblues said in Where is pfSense support for HTTP/3 and QUIC protocol support?:

Indeed. it just that the firewall industry is moving towards ngfw, which of course pfsense isn't.
Ngfw will most probably have a bad time with QUIC, Lets see how this will unfold

To be clear....what are you defining as NGFW?
As a UTM, pfsense can perform MITM with Squid.
Instead, If you are referring to creating policy around application awareness - yes pfsense does stumble here. The application text rules within snort for example, have not been updated since 2017 but the actually lua's are quite current. An admin will need to create the text rules which of course is a full time job for anyone.

Overall, NGFW firewalls will always have a hard time if the payload is encrypted. Doesnt matter the vendor at all.