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..
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.
-
@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.
-
@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.
-
@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.
-
@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 -
@jonathanlee There's a great playlist describing QUIC at the protocol level. Even with the AppID details of the protocol details, so much of the payload is encrypted that individual URLs are cloaked so that they can't be detected by filters (pfBlockerNG, snort, suricata) -- you have to block the entire QUIC request or nothing, you can't pick it apart.
HOW QUIC WORKS
https://www.youtube.com/watch?v=HnDsMehSSY4&list=PLW8bTPfXNGdDcSDSmcfYs3ynYOdc1cXSh -
HTTPS 3 uses UDP and TCP over port 443
Current HTTPS uses TCP.
To disable quic you just block UDP traffic to port 443 and port 80.
There is a overview of it with Palo Alto and other firewalls.
Thanks for the reply
You just close off UDP over 443 to stop it. I did and you can see the QUIC error code with Facebook during testing. After it will default back to TCP use and Facebook runs again.
That's the current recommendation. Without 443 UDP access it won't work.
Chrome browser can decrypt it. But yes it is an issue that's why the major firewall companies want it blocked if it's not required.
Make sure to upvote
-
@lohphat
https://youtu.be/QRRHA_5hS2cThis is amazing they decypt QUIC in this with pen testing software.
So why isn't SQUID doing this?
Make sure to upvote
-
@jonathanlee I know what QUIC is and how to block it. That's not the issue. I WANT to allow it but from a list of acceptable domains. That's the problem with pfSense, you can't whitelist QUIC by domain easily. That's my ask, It's going to be complicated to scope out what the QUIC request is asking for and then be able to whitelist "trusted" domains (Google, et al).
-
@jonathanlee This works because the TLS 1.3 keys are being captured at the host where the QUIC request is originating from.
A gateway (pfSense, PANs, Cisco, etc.) don't have access to those client keys UNLESS there's a capture agent on each host -- OR all the host keys have some sort of enterprise PKI management in place to escrow client keys on the fly.
This is a hard problem to tackle.
-
Perhaps using pfblocker to create and alias native for the ASN then include that in the black or white list for the QUIC rule
-
@lohphat PfSense open source community can do it. Just you watch. . . . Soon viruses will be stomped out. They have to have an http get request in there that is easily accessible, something. I can't wait to see the solution to it.
-
@patch maybe some form of adapting attestation that is being used with the TPM chips? TPM key attestation?
-
@patch said in Where is pfSense support for HTTP/3 and QUIC protocol support?:
Perhaps using pfblocker to create and alias native for the ASN then include that in the black or white list for the QUIC rule
Exactly that ^.
-
This post is deleted! -
@stephenw10 I didn't know pfBlocker could be used to create aliases which could then be used by a normal f/w rule. Interesting. I'm found a link to walk me though this. Thanks!
https://dannyda.com/2021/04/22/how-to-block-asn-autonomous-system-number-with-pfsense-firewall-how-to-block-an-organization-using-pfsense/
UPDATE: The linked tutorial demo uses an older pfB UI, I had to change the Action to "Alias Native" so the aliases (I did a v4 and v6 list) are created aren't deduped with the other pfBl lists.
Also note the pfBLocker help text doesn't mention these new list action modes of Alias Deny/Permit/Match/Native either and needs updating, In only mentions "Alias Only"
https://docs.netgate.com/pfsense/en/latest/packages/pfblocker.html
-
ASN aliases are usually better for blocking than allowing because they rely on the organisation in question maintaining them and can often be incomplete.
You only need to block 80% of IPs to make something unusable but you need to allow a lot more than that to make it usable. But it can work.Steve
-
@stephenw10 So I've created pfB IPv4 and IPv6 aliases for Google to pass then log all other requests to see who else is using it.
I don't use FB so I don't mind blocking their use of QUIC ;-)
UPDATE: After permitting AS15169 [ GOOGLE, US ] (for YouTube traffic) the only other ASN logged during YT testing was AS13335 [ CLOUDFLARENET, US ].
Not too surprising since they're a CDN.
UPDATE: Google is also using IP blocks not associated with an ASN for YouTube QUIC traffic. This MAY be their ad servers.
NetRange: 34.64.0.0 - 34.127.255.255
CIDR: 34.64.0.0/10
NetName: GOOGL-2
NetHandle: NET-34-64-0-0-1
Parent: NET34 (NET-34-0-0-0-0)
NetType: Direct Allocation
OriginAS:
Organization: Google LLC (GOOGL-2)
RegDate: 2018-09-28
Updated: 2018-09-28I knew this was going to be like this...hunting down scopes of addressing per whitelisted domain. So I'm not too discouraged and it's become a bit of a learning experience.
-
@patch Done! And it's working as expected. Thanks for the tip as it's NOT obvious that pfBlockerNG can be used this way (ASN lookup and enumeration) to create aliases for regular f/w rules.
UPDATE: There seems to be a bug/feature in the pfBlockerNG-devel where the Alias list isn't including custom CIDR network lists with the ASNs. I have had to duplicate all the rules so that the ASNs are enumerated in one alias and the CIDR blocks in another instead of being generated in the same alias list.
Alias Native not combining ASN enumeration with custom list in same rule
-
I wrote about this around YEAR+ ago Using BBR2, QUIC, RACK Congestion Control (CC) protocols in pfSense, so it’s time to wake up for someone ;)
Take my congrats ;)
Moreover, still thinking that initiatives like ZTNA become more popular (40% grow in 1 year for now) + widely using the QUIC protocol bring us a lot of surprises and a lot of Manual work in firewalling and IDS-ing traffic.
