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

[stephenw10]

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

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

Yes, this. I could imagine it makes Squid more obsolete. That's about all.

[johnpoz]

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

it makes Squid more obsolete

heheh - yeah true, but squid has be obsolete for what 10 years anyway..

[stephenw10]

Largely, yes. And encrypted SNI will only make it more so.

It still has a place in some specialist deployments. And in those you can just block udp 443.

Steve

[lohphat]

@johnpoz I was not expecting much other than to start a dialog as the reality is the f/w world had to adapt (note I didn't say "adopt") to the new reality.

This has been in motion for a decade and just was ratified and an increasing number of content providers are using it.

I didn't know if QUIC was on the roadmap or not and given that Wireshark is STILL evolving to handle it (other than just dump the raw data) to perhaps build a stream/session table to show the "sessions" in progress.

My expectations for pfSense would be to provide a little diagnostic data in terms of percentage of traffic it's using, the destination hosts, and any stream/session tabular data which is in the unencrypted part of the header.

By definition, the majority of the header is encrypted not just the payload so I wasn't expecting much. However, pfSense is also known as an IDP/IPS platform with the addition of several packages.

So if there could at the very minimum get some summary traffic and percentage of traffic, perhaps as another item on the traffic graphs, that would be helpful.

Again, I didn't know if there were any plans, so I simply asked the question to get a baseline of where we are.

[johnpoz]

@lohphat any of that stuff would have to come from packages would be my take.

So again I would tag @bmeeks to throw in his take - he is the ips/ids guy to be sure.

To be honest most everything becoming encrypted, not something new with quic - ips and ids is becoming less and less if you want my take on it.

Not much ips/ids can do from an encryption tunnel - there isn't much to look at to see if something bad is happening inside that tunnel.

Not much the ips/ids can tell from just looking at packets without the payload..

[lohphat]

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

Not much the ips/ids can tell from just looking at packets without the payload..

You'd be surprised. Certain applications have a pattern of behavior which can be deduced by the size and frequency of transmissions. It's a bit of alchemy but there are trends which can be triggers on their own.

[bmeeks]

There is essentially zero chance that Snort 2.9.x (currently what is used on pfSense) will get HTTP/3 or QUIC support. The 2.9.x branch is not getting any new features from upstream. Everything is going into Snort3.

Suricata does have an open Feature Request for incorporating QUIC app-layer support, but nothing has been settled there yet. Here is the link to the latest iteration of the long discussion: https://github.com/OISF/suricata/pull/7095. But this really does not mean much as Suricata could only detect that QUIC was passing, it would not be able to see anything in it. So not really very useful IMHO. I am unaware of anything happening in Suricata with regards to HTTP/3.

As @johnpoz alluded to, IDS/IPS is getting increasingly harder as more and more network traffic gets encrypted. Pretty soon nothing will be visible at the network layer except very basic source/destination info. Any IDS/IPS will have to move to the endpoints (servers, workstations, mobile devices, etc.).

[michmoor]

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

ny IDS/IPS will have to move to the endpoints (servers, workstations, mobile devices, etc.).

spot on and exactly as i stated in the previous post..
The way I see it, its like adding ClamAV. Belts and Suspenders to your overall security footprint. Doesn't hurt to have it enabled but to be clear it has little to no impact on defending you at the perimiter. Most of the work is/should be taking place on the endpoint.

Ah well, so the debate rages on....

[emikaadeo]

Hi,
just a quick question. DNS over QUIC support is coming to Unbound.
There's a chance it will be in the upcoming 1.16.3 release. Does Netgate plans to support this via GUI?

[lohphat]

@netblues Well, I'm trying to be pragmatic.

A f/w's job is to monitor and control traffic. Given that QUIC makes inspection a moot point what the f/w CAN do is help control where those packets come from.

e.g. The DoH settings in pfBLocker-devel to permit DNS over HTTP is a good example of how to control a type of traffic. A list of well known sites from which the f/w admin can select to permit/block traffic.

Since QUIC's strength is with streaming/complex websites, I think a page for QUIC which allows to admin to permit QUIC traffic from well known sources would be a reasonable first step. e.g. Google/YouTube, Facebook, Amazon, (and their CDNs).

Let the 80/20 rule stand and let the protocol do its magic where needed but force fallback to TCP for unknown/all other sites.

Yes, this can be done in the f/w ruleset page, but making a dedicated QUIC UI control page would be much friendlier. Perhaps this is a job for a package, but IMHO it's a low-level protocol issue and should be handled by pfSense.

[johnpoz]

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

but IMHO it's a low-level protocol issue and should be handled by pfSense.

Well the same could be said for any cloud provider using 443 currently over tcp. So you want a feature to put in what CDNs are allowed for rules you create.

So in general if i create a rule - you want a drop down list to only allow to specific CDN ASNs that can be picked from a drop down.

[lohphat]

@johnpoz Perhaps.

I've just started digging into QUIC and logging accesses so I need to be smarter about the scope of the requests. e.g. Is the QUIC request going to the FQDN of the content source (e.g. YouTube) or the CDN? If it's the CDN then was there an initial QUIC request to the FQDN, then a session ID created then subsequent QUIC requests go to the CDN? I don't know yet. I'm acknowledging my ignorance thus the reason I posted my question in the first place.

How would pfSense enumerate the CDN ASNs unless it were running BGP?

[michmoor]

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

IMHO it's a low-level protocol issue and should be handled by pfSense.

why?
does any other big box vendor do this?

[lohphat]

@michmoor QUIC was just ratified, so I don't know.

The world is not static. Things change.

[michmoor]

@lohphat well the point of my question wasn't about ratification - quic has been around for quite some time - it's if other firewalls provide the ability to filter from which sources you want quic enabled or not.
Overall, the requst for pfsense and really for any other vendor is moot because there is no need to do this at all. as been suggested, block udp/443.

[lohphat]

@michmoor All or nothing is not acceptable and a lazy solution.

QUIC may be desirable for known sources and not for others. That's what I'm asking: if there's a middle ground where well known, trusted sources could be MORE EASILY accepted since QUIC is much more efficient, while blocking other sources.

BTW QUIC is not the same as gQUIC (Google QUIC) when it was first developed in 2012 -- the ratified RFC version is its own thing.

[johnpoz]

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

trusted sources could be MORE EASILY accepted since QUIC is much more efficient, while blocking other sources.

There is no built in feature like that - you would either have to create your own lists for your rules, or use something like pfblocker to create the aliases for you.

If you are filtering outbound to only trusted destinations, or more trusted destinations then you should already have these rules in place be it they use normal https over tcp, or over udp - not really sure how the trust changes be it tcp or quic to be honest.

Why would I allow a client to destination X IP via tcp 443 but not udp 443?

[mer]

So "allow from LAN/any to <allowedlist_of_ips+or_fqdns> port 443 proto udp" is the basic ask, because beyond that the data is encrypted?

[michmoor]

@johnpoz thats where i was going with my line of questinong. essentially, why does it matter if connections are made outbound for tcp/443 vs udp/443.
I suppose the thinking is i want google traffic over udp/443 but not microsoft.

overall i see the point being made. pfblockerng has a DoH feed that can be used to block DoH so basically there needs to be a UDP/443 feed and that is what is being requested.
At the end of the day, a list will need to be provided either through some other 3rd party or curated by the OP.
The attempt to make this into a limitation of pfsense is where the conversation falls apart to be quite honest.

[lohphat]

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

Why would I allow a client to destination X IP via tcp 443 but not udp 443?

For "standard" TCP traffic a connection for each web page component is a separate TCP request (e.g. CSS vs JS or image are their own TCP requests) and those TCP headers reveal more information (albeit minimal but more than QUIC).

QUIC allows for multiple streams to be encapsulated in a single request -- the f/w can't tell any longer how many objects are being requested.

So with TCP/443 if there are ads being served, the FQDN of the ad server for that object is revealed in the header and can thus be blocked. With QUIC, no more -- so more ads (or any other object desired to be filtered/blocked) can no longer be intercepted separately.

It's a game changer -- either wholesale block UDP/443 or come up with a compromise to enumerate popular destinations to permit some traffic optimization and improve performance or just leave it up to the admin to enumerate block lists on their own. Doable but it seems like a waste of collective effort. Thus coming up with a base list of popular QUIC/443 destinations for the admin to allow and then add sites as needed. Is that unreasonable? Sure I'm all for it being a package too. However it would be nice in the base pfSence functionality to track and graph QUIC alongside TCP and UDP traffic stats since the "goal" is to move more TCP traffic to QUIC.

All I'm trying to suggest is there might be a sweet-spot for dealing with the new reality of QUIC since it's already more than 25% of traffic at this point.

Ignoring this growing traffic trend without some sort of minimal out of the box controls seems odd. It's only going to grow as a percentage of traffic and the black and white proposed solutions of block it all or not seems overly simplistic.

A base list of popular permit sites/domains so that each admin doesn't have to hunt down the proper FQDN/IPs seems like a reasonable start.

Again, I'm not pontificating, just trying to see what options we need to plan for as this grows in traffic popularity and handling it -- or not -- will affect performance. At some point some popular sites may decide that it's QUIC and no TCP fallback as there is today.

OK, fine, block just them. Communicating that decision to your internal customers is going to be an interesting conversation.