Where is pfSense support for HTTP/3 and QUIC protocol support?
-
@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.
-
@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..
-
@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.
-
@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 unfoldTo 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.
-
@mer It's not the data payload only, it's the headers so that you can garner at least some minimal info about what's going on, e.g. the FQDN may be exposed if SNI extension is used in TCP where in QUIC it is not.
-
@lohphat that is all part of the payload when you start from the original packet. Look at a UDP packet, say on ethernet. So you have 1560 bytes to start with, you have ethernet header, you have IP header that says "this is UDP", then you have UDP header then you have UDP payload. Everthing in the QUIC packet is in the UDP payload so the "Headers in the QUIC protocol" are part of the UDP payload and if that is all encrypted, then yes, you can't see anything past the UDP headers, which give you at most "destination".
-
@michmoor said in Where is pfSense support for HTTP/3 and QUIC protocol support?:
Overall, NGFW firewalls will always have a hard time if the payload is encrypted. Doesnt matter the vendor at all.
Agreed. It seems as the primary requirement of a "NGFW" is "packet payload inspection" which can be done if payload is not encrypted. If encrypted, the NGFW would need to know the keys, decrypt the payload, make a decision. Lots of CPU there, not to mention capturing the keys is a nontrivial task.
-
@mer said in Where is pfSense support for HTTP/3 and QUIC protocol support?:
@lohphat that is all part of the payload when you start from the original packet.
Before UDP is used for "traditional" encrypted payloads there's a session setup, THAT is what a session-based f/w can log and track. Once the crypto is established then all bets are off.
It's the INITIAL headers and handshakes which have been used for traditional session logging, but since QUIC does all the crypto in the initial handshake, there's even less information to latch onto.
This is the point, with QUIC there's less information to garner clues as to what's going on. It's CURRENTLY used for web traffic mostly -- but there's nothing stopping it from completely replacing TCP for ANY protocol as it gains traction.
-
@lohphat still at a loss to how pfsense is behind?
Or what support you think pfsense should add, you want the web gui via quic? Cuz I doubt overnight pfsense is going to become a ngfw with support for quic ;)
Since has never been a ngfw in the first place.
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.03 | Lab VMs 2.7.2, 24.03 -
@mer Yep which is why i think most would agree focusing on the endpoint through some type of software installed is the best way to go. I know my company uses Sophos endpoint agent along with FireEye's on the laptops. The sophos client is what is doing the URL control and application filtering. Even though Palos are used all over the environment and its a NGFW, its not at all feasible to do this type of control on the firewall. Defense in depth.
But to stress, to a certain degree, if we are going to expand the definition of a NGFW than you can argue to some degree, that pfsense is that - it is, after all, a UTM. But everyone has there own definition of NGFW.
-
@michmoor said in Where is pfSense support for HTTP/3 and QUIC protocol support?:
has there own definition of NGFW.
True - but without any packages is just a traditional stateful firewall providing inbound and outbound inspection of the state, etc.
While it can do say ips/ids with the addition of a package.. What those packages might do with quic would be up to those packages, and not really pfsense.
UTM is another term.. again if I throw IPS package on it I can now call it my NGFW UTM ;) which all just words without meaning without understanding context..
Still what exactly does OP feel should happen here.. If your curious what the IPS packages are going to do with quic, that they haven't already done in the last 10 years. Should prob ask @bmeeks
But to me this thread doesn't make much sense - unless your just asking for the web gui to be served up via quic? There is nothing for the pfsense the traditional stateful firewall it is to do to "keep up" or not "fall behind"..
-
@johnpoz said in Where is pfSense support for HTTP/3 and QUIC protocol support?:
But to me this thread doesn't make much sense
yep and this is not to belittle the OP but first and foremost as the original question was confusing.
At the end of the day, the majority of communications on a network are going to rely on ports. Allow or Block ports as required. The payload is irrelevant if it's encrypted and if it's not encrypted then you have IDPS systems that will scan the payload and work on defending your network.I think we can all see how UTM or NGFW or whatever term comes next, its really the marketing teams who have won this and confused us all :)
-
@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.
-
@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..
-
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
-
@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.
-
@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..
-
@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.
-
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.).
-
@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....
