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

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.

johnpoz

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

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

Great and not all IPs even have a PTR.. So this system might work or might not work.. PTRs don't always list the "domain" etc.. could just be a generic name for the IP and what part of the world its in, etc

So now you want your "firewall" to do a PTR query on every single hit of traffic that wants to go through the firewall.. That is going to be a shit ton of dns queries, where most of them as far as PTRs go wont even resolve to anything..

;; QUESTION SECTION:                                                                
;www.amazon.com.                        IN      A                                   
                                                                                    
;; ANSWER SECTION:                                                                  
www.amazon.com.         30      IN      CNAME   tp.47cf2c8c9-frontier.amazon.com.   
tp.47cf2c8c9-frontier.amazon.com. 30 IN CNAME   d3ag4hukkh62yn.cloudfront.net.      
d3ag4hukkh62yn.cloudfront.net. 30 IN    A       99.84.166.43                        

;; QUESTION SECTION:
;43.166.84.99.in-addr.arpa.     IN      PTR

;; ANSWER SECTION:
43.166.84.99.in-addr.arpa. 82726 IN     PTR     server-99-84-166-43.ord52.r.cloudfront.net.

lohphat

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

So now you want your "firewall" to do a PTR query on every single hit of traffic that wants to go through the firewall.. That is going to be a shit ton of dns queries, where most of them as far as PTRs go wont even resolve to anything..

Not at all, the overhead would be incurred not for all traffic but for a specific rule requesting the reverse lookup (e.g. UDP/443 requests only), and caching the results to reduce the need for a reverse lookup for each request.

I know PTRs are not required and may not match but it's what we have available and the larger CDNs I'm trying to target (Google, MSFT, et al) usually (not always) have more consistent DNS records.

johnpoz

@lohphat Can't wait for you to come out with this magic firewall of yours.. Since clearly pfsense is just not doing it right..

Free as well like pfsense I assume.

lohphat

@johnpoz

Aug 4 09:11:16 LAN QUIC HTTP/3 (1659322461)[2603:xxxx::1d04]:49375
[2607:f8b0:4006:823::200a]:443
lga34s39-in-x0a.1e100.net

So in the case of YouTube, the destination address DID resolve into a sane FQDN

johnpoz

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

into a sane FQDN

but is not the domain user was trying top go to - so where is this list pfsense is magic going to have that says oh if user looks up domainX something, and the PTR comes back otherdomainY or somethinG or xyzdomainX then sure let it through..

How does this magic firewall even know that IP 1.2.3.4 should have a ptr done on it and only if in its list of ok domains should it be allowed.

So any destination IP using udp 443, it should do a ptr on and only allow from your list of domains that are permitted. Who is compiling this list of PTR domains that are ok? How is it going to be updated?

What if going to udp 8443, what about udp 10443, or 4430, etc.. Just block all those? Or should it do PTR queries on the IPs

lohphat

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

@lohphat Can't wait for you to come out with this magic firewall of yours.. Since clearly pfsense is just not doing it right..

Free as well like pfsense I assume.

I don't think the snark is necessary.

Having a method to trigger an additional address verification for a specified rule -- and not all traffic (I don't know where you got that impression I was suggesting that) -- doesn't seem impossible or need to "create a new firewall".

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?:

into a sane FQDN

but is not the domain user was trying top go to - so where is this list pfsense is magic going to have that says oh if user looks up domainX something, and the PTR comes back otherdomainY or somethinG or xyzdomainX then sure let it through..

You're not getting the point -- AT ALL.

I want to PERMIT google UDP/443 requests for YouTube.
I know that Google uses *.1e100.net for most if not all their YT content.
I want a rule to check if the UDP/443 destination address is within *.1e100.net
For THIS RULE, take the time to reverse lookup the destination FQDN and cache it for any subsequent requests, and match the domains in the permit rule.
For ALL OTHER UDP/443, drop.

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

but is not the domain user was trying top go to - so where is this list pfsense is magic going to have that says oh if user looks up domainX something, and the PTR comes back otherdomainY or somethinG or xyzdomainX then sure let it through..

I have no idea where you got this from. I never suggested this was the use case.

johnpoz

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

I know that Google uses *.1e100.net for most if not all their YT content.

How do you know this - where does pfsense learn this from... You going to manually put that in? What if google now starts having ptrs that resolve with new1e200.net etc..

Where is this info going to come from - who is going to put it in to the firewall, how is it going to be updated and maintained as it changes, etc.

And you want this only for quic but not tcp - because why exactly? The same stuff that can happen over quic can happen over tcp 443..

So pfsense should also do all this over tcp 443 as well..

Lets say you query when user hits udp 443 going to 1.2.3.4 - how fast does that ptr resolve? What if takes longer than normal, clients hasn't got an answer and has already sent 3 retrans - oh well guess I can't get there - sorry user.. Try again later in his browser window.

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?:

I know that Google uses *.1e100.net for most if not all their YT content.

How do you know this - where does pfsense learn this from... You going to manually put that in? What if google now starts having ptrs that resolve with new1e200.net etc..

Where is this info going to come from - who is going to put it in to the firewall, how is it going to be updated and maintained as it changes, etc.

And you want this only for quic but not tcp - because why exactly? The same stuff that can happen over quic can happen over tcp 443..

So pfsense should also do all this over tcp 443 as well..

I wasn't suggesting pfSense do this automatically -- ME THE ADMIN determines the domains to permit. If things change over time, I WILL MAKE THE CHANGES.

I just want the functionality of being able to do this.

This is no different than blocking/permitting any other website -- or any other protocol.

What's missing is wildcard domain aliases and I think this is a solvable problem so that admins have the choice to use it -- or not. If they try to do this on too many requests then yes, the f/w will slow.

But I'm not suggesting ANYONE do that, I just want some way to OPTIONALLY add an additional reverse lookup -- and cache the result -- to then use in a rule.

That doesn't seem unreasonable.

JonathanLee

@lohphat QUIC protocol has been in the works for some time now Google and Facebook want to use it. PaloAlto is also a firewall company has even released an update that can detect QUIC traffic. New protocols have to be approved before getting used. For now, I only allow TCP traffic to 443. It was created to help speed up streaming traffic and it was experimental for sometime. Just block it and the traffic defaults back to TCP.

lohphat

@jonathanlee I understand all that. But the protocol has now been ratified by the IETF and thus having some level of control other than all or nothing is desirable. Being able to whitelist QUIC from well-known sources and not others seems a reasonable middle-ground. I want YouTube and Google data streamlined but not from any random site.

JonathanLee

@lohphat Palo Alto recently gained capacity last year for appID to see what the traffic is. Firewalls do have the ability. Give it time PfSense will soon have that ability as well.

I did a discussion post about this in Firewall class while working on my AA. As Facebook turned it on when I was working with Palo Alto images for assignments the Professor said that it is normal to block the UDP 443 traffic unless it is required.

URL blocking and items will be a problem if you let HTTPS3 run. Facebook started tested HTTPS3 today and now is only using this with my IP address. Hypothetically if a triad of major IT companies all start using HTTPS3 at once, example being Google, Facebook, and Cisco. Firewall companies are forced to react. The real question is what is the proper guidelines for security controls and use of HTTPS3 in firewalls. Over many years in the field I have seen this tactic done to force major sales. One can forecast a new product will come out after that protocol is staged for major use. Again, hypothetically, "Cisco's New ____" fill in the blank. ASA with QUIC controls for example. Understanding the movements and planning is important I feel in cybersecurity. Watch out for this protocol. When I worked at NCR we had products that were only allowed to be used with one vendor per contract for a specific amount of years, and no one else. So Google's HTTPS3 proprietary protocol could be licensed to only one firewall vendor for decryption for a specific timeline of for example 5 years maybe Palo Alto could have the decryption rights for it. It is the gray areas we need to watch out for. Investments and the sole investors into the new products get first dibs on such items explicitly. The real question comes back to, what is the Federal Government Guidelines for such a triad of issues Firewalls, Protocols, and Approval of Use.

Again to look at this within security and corporate network issues, Obscurity is of upmost importance when working with exploits. Antivirus software is finetuned daily to detect specific exploits within the signatures of files. Encoders play a key role in obfuscation for the security of the exploit and it's handlers. Use of encoders gives rise to polymorphism within code, code that is ever changing in its location and signature. To put in other words this is so new that it has not been hardened enough to be left wide open with a firewall. Follow the recommendations until they approve of it's use for secure networks. Nation state actors love the grey areas. For now only allow 443 and 80 with tcp, until explicitly advised that it's safe.

Ref:
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClarCAC