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

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

[johnpoz]

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

the FQDN of the ad server for that object is revealed in the header and can thus be blocked

Still in that the dns has to be queried for the fqdn..

It is the same thing with tcp, if I serve up content at www.domain.tld and the ad is served via www.domain.tld/ad

Then the header doesn't change - you also have esni or the new name for it ech. where even in tcp the header wouldn't be seen for the fqdn.

[lohphat]

@johnpoz Not really.

Now with QUIC, the browser makes a request to google.com for a page, within that request multiple streams of data are returned in that single request. The server, not the client is potentially determining where the stream data is coming from -- as I understand it currently, I may very well be incorrect.

So instead of e.g. 3 TCP requests by the browser to 3 different FQDNs, a single request is made to one FQDN and the multiple data streams are returned in the response. The source of the ad may not be revealed to the client. Again, it's as I currently understand it via the examples demonstrated in the video I originally posted. I may be interpreting the QUIC response incorrectly, but it seemed pretty clear. One request, multiple stream responses from the single request.

Note: This was written pre-coffee.

[johnpoz]

@lohphat again to lookup www.domain.tld vs www.otherdomain.tld where the ad is served would require a dns lookup. You can still filter on the dns be it tcp for the website or udp.

You are correct if the ad is served off www.domain.tld/ad there would be no dns needed since www.domain.tld is already known.

I do not need to create a new session ie handshake to pull www.domain.tld/ad, but if going to another fqdn www.otherdomain.tld/ad a new session would need to be created.

Even if with quic it would be a different session.

With esni or ech, there is no header seen, so you don't know if its www.domain.tld or www.domain.tld/ad

All of this is behind what pfsense is meant to do.. Pfsense is a stateful firewall, it has no method outside of a ips/ids package to see the headers. When esni/ech becomes mainstream then they won't be able to see the headers. Be it they are there or not.

All of this is great discussion - but its not really a pfsense thing. All the stuff you talking about looking at, or not able to look at with quic, etc. Is not a pfsense thing, its a ips/ids thing. Until such time that ips/ids is integrated into pfsense this is thing to talk to the ips/ids makers about. If they do X, then if pfsense is running them they could do X.

Even if integrated into pfsense - you could really only fault pfsense in being behind the times if the ips/ids did Y, but pfsense did not allow it to do Y. And only allowed it to do A or B, etc.

What your talking about is beyond the scope of a traditional stateful firewall.. Where it can filter on IP, port (source or destination). Protocol upd or tcp, etc. What is in the "headers" of some data transfer be it tcp or udp (encrypted or not encrypted) is beyond what pfsense is meant to do as a stateful firewall. The IPS/IDS being used may or may not be able to do what your ask.

[lohphat]

@johnpoz I'm not so sure.

In a single QUIC request multiple streams can be returned, the CSS file, the JS for the page, the HTML, and ad content. The browser doesn't see the FQDN for all the page components (if they come from different sources), only the FQDN of the initial page it's after.

This would be a choice of the content management of the server to use its bandwidth to serve ads via a QUIC stream vs making the browser load the ad via another request. In Google's case, their ads are coming from inside their house anyway so the client browser only sees the FQDN for the web page access, not the potential components.

That's why Google, MSFT, and FB pushed for QUIC -- to serve web pages faster by delivering multiple components in a single request and since they want their ads too, can push them via an embedded QUIC stream and not a separate TCP request exposing the FQDN of the ad server.

[JKnott]

@lohphat

Currently, UDP 443 is used for HTML 3. I understand that QUIC can also be used with other protocols. What will happen with something like SSH? Will it use UDP 22? Or UDP 443, with the appropriate SSH port 22 inside? If the former, then filtering on protocol will be largely the same as now.

[lohphat]

@jknott Even though "technically" QUIC can replace any TCP transaction, it's raison d'être was to optimize HTTP+TLS+HTTP/2-multistream requests to load a webpage. It can do it all in one transaction instead of the 3-way TCP+TLS handshake taking a lot more time.

I think it will seek it's own level and only be used for multistream applications like parallel file transfers where one TCP connection, even with windowing, isn't good enough.

I don't think it will be used to replace single stream TCP connections as there's little benefit. But that's just a wild-assed-guess.

There's a huge gap between "in theory" and "in practice".

QUIC does a good job in optimizing an ugly situation of TCP+TLS+HTTP/2 into a streamlined solution for now. We shall see how it spreads by natural selection.

[JKnott]

@lohphat

Quite so. I was only using SSH as an example, not because it had a need, though other protocols, such as email, also use TLS.

[lohphat]

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

I suppose the thinking is i want google traffic over udp/443 but not microsoft.

This is what I've been trying to play with. i.e. setup an alias of permitted QUIC destinations then block the rest.

The problem is that QUIC is usually used with large content providers with CDNs and pfSense doesn't support wildcard domain aliases -- they must be individual FQDNs only. I'm looking for a solution to say, permit "*.1e100.net" (Google's CDN) then toss all other QUIC (UDP/443)

From the pfSense docs relating to aliases:

Warning
This process only supports forward name resolution of FQDNs using A and AAAA records such as host.domain.com. Aliases do not support pattern matches, wildcard matches (e.g. *.domain.com), or any other style of record comparison.

If the DNS query for a hostname returns multiple IP addresses, all of the IP addresses returned in the result are added to the alias.

Note
This feature is not useful for allowing or disallowing users to large public web sites such as those served by content delivery network (CDN) providers. Such sites tend to have constantly rotating or random responses to DNS queries so the contents of the alias on the firewall do not necessarily match up with the response a user will receive when they resolve the same site name. It can work for smaller sites that have only a few servers and do not include incomplete sets of addresses in their DNS responses.

So

[johnpoz]

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

pfSense doesn't support wildcard domain aliases

Nothing supports a wildcard domain alias - because its pretty much an infinite possible amount of IPs.

If you want to filter on user trying to go to wildcard.domain.tld you would need to do a proxy..

But a firewall that blocks on a wildcard aliases isn't a thing.. What you could have is some firewall that did a query on whatever fqdn a user is trying to resolve and let that resolve or not, You can do that now with pfsense and unbound.. If you don't want user to go to wildcard.domain.tld then don't let him resolve domain.tld.

Firewall rules are based on IPs - it is impossible to resolve every IP in an infinite alias.. So you would need to control if that can even be attempted to be resolved which is dns, not the actual firewall that allows or blocks on an IP, etc.

[lohphat]

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

But a firewall that blocks on a wildcard aliases isn't a thing.. What you could have is some firewall that did a query on whatever fqdn a user is trying to resolve and let that resolve or not, You can do that now with pfsense and unbound.. If you don't want user to go to wildcard.domain.tld then don't let him resolve domain.tld.

I understand that.

A proxy may be the answer, but I can also envision is a rule which can be specified to do a reverse lookup and if the returned FQDN is within the permitted wildcard, then permit it. And instead of doing this for every request have a tunable cache of IP to reverese lookup names to speed up subsequent requests.

Essentially it's a reverse concept to pfBlocker but for a specific permit rule.