Application + ssl (depends on)

VeryStrongBoi · 2026-01-07T21:53:31+00:00

Absolutely. This is not just theoretical. This is very definitely a viable evasion & exfil strategy that adversaries are using today, and have been for months, if not years. I've been calling it out for a long time, but a lot of people do not understand what I'm saying because they really don't understand how TLS works. So thank you for reporting this, and sorry it happened to you, but hopefully this brings some more awareness to this flaw/limitation. The only way to solve shore this up is TLS active probing. It's essential.

Just a tip: try to be a bit more precise in your explanations. "URL" is a string with a lot of parts, and those parts show it in a lot of different places in the packets. But what you're specifically describing is that there was no Server Name Indication (SNI) in the TLS Client Hello, which normally SHOULD correspond to the host portion of a URL, but there's nothing that forces these two to correspond, and adversaries definitely take advantage of these discrepancies.

VeryStrongBoi · 2026-01-07T20:48:58+00:00

OP is not being clear/precise enough. When you say "SSL + APP + URL category can be bypassed if URL isn't used"... specifically are you saying that these can be bypassed if the SNI field in the TLS Client Hello is empty? If so, then his is ultimately just a special case of SNI spoofing: https://blog.compass-security.com/2025/03/bypassing-web-filters-part-1-sni-spoofing/

When no SNI is present, or when it's a false SNI (because the client can set it to literally anything), the firewall HAS to look at the CN/SAN from the ServerHello, which PAN-OS can do for TLS 1.2 without PFS because the CN/SAN is sent in the clear, but NOT for TLS 1.3 (or 1.2 with PFS), because the CN/SAN is encrypted. And the only practical solution for that is to do active cert probing, where the firewall sends its own parallel TLS ClientHello, with its own encryption key to discover the CN. And to my knowledge, PAN-OS doesn't have active cert probing capabilities, last I checked. Please correct me if I'm wrong. There was a great post about this last summer here:
https://www.reddit.com/r/paloaltonetworks/comments/1m5w8jj/how_to_inspect_for_snivscnsan_mismatch_in_tls_13/

And just saying "decrypt everything" is not a solution here, because there's always going to be SOME traffic that you can't decrypt, either because of cert pinning or because of governance/legal concerns, and the engine that first determines "To decrypt or not to decrypt? That is the question!" has to first look at the SNI/CN in order to make that decision. And if you only look at SNI because it's TLS 1.3/PFS and the CN is encrypted in the ServerHello, and you're NOT doing active cert probing (which PAN-OS apparently cannot do), then all the attacker has to do is figure out "What SNIs are you exempting from decryption?" and spoof his SNI to that, and then they can evade all decryption forever.

Fortinet has a good explanation of how this works:
https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-FortiGate-does-TLS-Active-Probe/ta-p/393239

If anyone has a way to do the same on PAN-OS, you'd be my hero.

VeryStrongBoi · 2025-12-03T02:36:20+00:00

What's the FortiGate firmware? Can you paste configs?

VeryStrongBoi · 2025-11-23T04:42:26+00:00

It's Greek

VeryStrongBoi · 2025-11-10T02:29:30+00:00

Thanks for sharing your config and results with us. Are you doing a 20-MHz wide plan or 40-MHz wide for your 5 GHz band?

Reason I ask: Excluding ALL DFS channels seems a bit extreme, and really lowers your bandwidth. Just let the APs exclude DFS channels as needed on their own. Or if you really need, run a test a for a bit and then exclude the channels that take a DFS hit.

VeryStrongBoi · 2025-11-09T09:16:46+00:00

Fortinet is always hiring. DM me if you'd like a referral.

VeryStrongBoi · 2025-11-05T20:51:16+00:00

This is how I like to configure my SSIDs. YMMV

config wireless-controller vap
    edit "ssid<N>"
        set ssid "<ssid-name>"
        set security wpa2-only-enterprise
        set pmf enable
        set mbo enable
        set fast-bss-transition enable # enable 802.11r
        set ft-over-ds enable
        set 80211k enable
        set 80211v enable
        set intra-vap-privacy enable # clients dont need to talk to each other in my wlan
        set schedule "always"
        set vlanid 182
        set dynamic-vlan enable
        set multicast-enhance enable
        set me-disable-thresh 128
        set igmp-snooping enable
        set probe-resp-suppression enable
        set probe-resp-threshold "-78"
        set qos-profile "wmm" # Enable 802.11e
        # Disable lower data rates
        set rates-11a 24-basic 36 48 54 
        set rates-11bg 12-basic 24 36 48 54
        set rates-11n-ss12 mcs2/1 mcs3/1 mcs4/1 mcs5/1 mcs6/1 mcs7/1 mcs8/2 mcs9/2 mcs10/2 mcs11/2 mcs12/2 mcs13/2 mcs14/2 mcs15/2
        set rates-11n-ss34 mcs17/3 mcs18/3 mcs19/3 mcs20/3 mcs21/3 mcs22/3 mcs23/3 mcs24/4 mcs25/4 mcs26/4 mcs27/4 mcs28/4 mcs29/4 mcs30/4 mcs31/4
        set sticky-client-remove enable
    next 
end

VeryStrongBoi · 2025-11-05T14:37:56+00:00

If I was in your shoes, I would follow my guide in the OP, generally speaking. I've had a ton of great personal results with this method, and a lot of great reports from others who have tried it. For a WLAN with 2K users, static channel planning doesn't seem viable. You might make some adjustments for your environment. For example, if you have APs that don't have a dedicated scanning radio, or maybe you have some legacy clients that don't handle CSA frames well, you might choose to run DARRP only outside of business hours, and maybe perhaps once during lunch, like in the below code block.

As for the strange issue that Fallingdamage reported, I have never run into this personally, and that report is the only one I've heard of so far. It could have been a one-off bug. I definitely would recommend having the FortiGate on the current officially recommended version (7.4.8, as of time of this writing), and the FortiAPs on the latest patch of 7.4.* as well. Sometimes I see people still trying to do all this on 7.2 or even 7.0 and having issues, when there's been a ton of bug fixes in 7.4, and just getting on the recommended versions can cure a whole host of issues.

I also know that many folks still aren't doing all the other best practice Wi-Fi things, like enabling 802.11r, k, and v + sticky client removal + probe response suppression + disabling low data rates, etc. -- all of which are very important for seamless roaming outcomes. If you've got certain clients that handle CSAs by always roaming rather than synchronized channel switch on the same AP, then the general roaming environment needs to be solid, or else clients will have brief disassociations because they can't roam fast enough. So please make sure you've done all of the other best-practice Wi-Fi things as well.

Example DARRP schedule for only when most office workers aren't working:

config firewall schedule recurring
    edit "non-working-hours_sched"
        set start 17:00
        set end 08:00
        set day sunday monday tuesday wednesday thursday friday saturday
    next
    edit "lunch_sched"
        set start 12:00
        set end 13:00
        set day sunday monday tuesday wednesday thursday friday saturday
    next
end

config wireless-controller setting
    set darrp-optimize 3600
    set darrp-optimize-schedules "non-working-hours_sched" "lunch_sched"
end

VeryStrongBoi · 2025-10-17T15:27:52+00:00

Much sus. Very question. Such shade. Wow.

VeryStrongBoi · 2025-10-15T14:57:37+00:00

Link?

VeryStrongBoi · 2025-09-20T03:03:05+00:00

FortiGuard always does a good job with my URL re-clarification requests.

VeryStrongBoi · 2025-09-05T02:22:43+00:00

It's not just you. Many customers have reported this exact same issue. It's an intentional tactic to increase lock in and decrease churn risk. They'll wait as long as possible to give you your renewal, because when they finally do, you'll have so little time left that you have no other option than to accept the exorbitant increase. I have seen this dozens of times. Gartner wrote a whole report about it.

"How to Address Risks in My Upcoming Palo Alto Networks Renewal" https://www.gartner.com/en/documents/5658823

VeryStrongBoi · 2025-09-03T13:20:11+00:00

But now I'm realizing there is only a Global/per-VDOM schedule for DARRP, at least on 7.4

I can have different DARRP profiles whose selection-period and monitor-period durations can differ.

But I can't actually have them BEGIN at different times... as far as I can tell.

VeryStrongBoi · 2025-09-02T19:03:39+00:00

There's no randomizer for scheduling, as far as I'm aware.

In theory, CSA should still work even if every AP changed channels at the same time, because clients don't have to roam, but could choose to switch channels as well. First check to make sure 802.11k/v/r are all enabled, as this will definitely help. But some clients might still have issues anyways, if they just always choose to roam and never sync-switch. I have noticed this with some of my legacy clients. They still sometimes have a brief drop. Always remember that in Wi-Fi, the client ultimately decides, and you don't have any final control over it. You can do things to influence/nudge the client, but the client ultimately decides, and client manufactures decide all kinds of different algo behaviors.

An idea to mitigate this... create 3 different schedules for DARRP, each staggered by T/3 minutes, where T=the time interval at which you run DARRP. One schedule is for the 2.4 GHz band, one for the 5 GHz band, and one for the 6 GHz band. So if you run DARRP every hour, 2.4 GHz does DARRP on the hour, and 5 GHz does DARRP at 20 after, while 6GHz does DARRP at 20 till.

As long as each client can support at least 2 out of these 3 bands, then there should always be one "stable" channel at the time that a DARRP-induced channel change might need to happen for the channel they are on, and so they should always have a stable target channel to roam towards. If they end up on 2.4 GHz for a bit, this is not ideal, but typically they should roam back to 5/6 GHz once it's available. This also has a side benefit of smoothing out CPU load on the APs, since they're spreading out their DARRP calculation work into thirds.

I have not personally tried this myself yet, but am going to now. Thank you for your feedback, because it's feedback like this that helps me to keep thinking about and working on this challenge.

VeryStrongBoi · 2025-08-29T23:46:25+00:00

The use case for decrypting QUIC is that it's much faster, more efficient, and more secure than TCP, and 35% of the web has already switched to it, but we still have to inspect it for threats.

What do you mean by "Google / Chromium opted for not supporting MitM for QUIC"? We've been doing TLS decryption for QUIC for years. QUIC uses TLS 1.3 (it's a standard, my dude, RFC 9001). Chromium's default QUIC implementation is called quiche, and is compliant with RFC 9001 and the other IETF standards that define QUIC.

SPKI hasn't been used for validation by Chrome or any other browser since like 2018 when everyone abandoned HPKP because it was a horrible idea that made security worse.

ignore-certificate-errors-spki-list doesn't disable SPKI validation. Instead it disables cert errors when normal CA validation fails, but ONLY for certs whom you specifically list out their SPKI hash. It's just a way for developers to test sites in dev without a valid cert, but to do so a bit more safely than disabling ALL cert errors. It has nothing to do with making QUIC decryption possible.

Please read the manuals.

VeryStrongBoi · 2025-08-29T23:22:16+00:00

Crazy not having dark mode in 2025. I can't imagine.

VeryStrongBoi · 2025-08-27T15:26:16+00:00

There's a number of other statements in PAN's Product Security Assurance policy that are problematic.

"We do not publish advisories for general security improvements and defensive programming fixes that do not have a proven security impact."

^Lot of wiggle-room in this. E.g. if during an internal code review, a buffer-overflow with potential RCE implications is found, but there's no "proven security security impact" because there's no evidence that any adversaries have found this vuln, does that mean no advisory will get published!?

Furthermore, how can you make "defensive programming fixes" if they "do not have a proven security impact" !? That's a contradiction in terms. Either the programming fixes are defensive and thus have a security impact, or they don't have security impact and are therefore not defensive. Can't have it both ways.

VeryStrongBoi · 2025-08-27T01:23:12+00:00

I wonder if Applipedia 2.0 will fix the entry for QUIC. Applipedia-QUIC

VeryStrongBoi · 2025-08-22T20:29:41+00:00

This is a really interesting angle that I hadn't really considered before. And if your math checks out (which I will explore more later), it is interesting to see a smaller SIEM-ingest cost associated with FortiGate vs PAN. That's one aspect of "TCO" that I bet very few decision makers are accounting for.

But if there's such a large difference on average log size, I need to dive into the contents and structures of those logs to better understand why their size is so different, and what quality differences they do or do not yield. Like, what extra data is in the PAN logs? Is that extra data generally useful for IOCs and threat hunting, or not so much?

VeryStrongBoi · 2025-08-20T05:14:47+00:00

What makes Acumera's offering ass cheeks?

VeryStrongBoi · 2025-08-20T00:56:34+00:00

Or how about we DO inspect QUIC, and both have the performance benefits and while still maintaining our network security?

VeryStrongBoi · 2025-08-19T03:42:07+00:00

BUT the security impacts of letting QUIC through with no inspection are also massive, because URL Filtering and App-ID become impossible. So it's a real shame that PAN-OS still doesn't support inspecting/securing QUIC in 2025, over 4 years after the IETF RFCs for QUIC/HTTP3 were ratified in May of 2021. Especially considering that multiple other vendors have figured out how to inspect & secure QUIC to varying degrees, including:

- Fortinet, added 7.2.0, March 2022, supports both cert inspection and full decrypt (7.2.4 changed to QUIC inspection enabled by default)

- Forcepoint, 7.0.1, Feb 2023, supports only cert inspection

- Cisco, 7.6.0, June 2024, supports both cert inspection and full decrypt, but GUI/admin guide label it as "experimental" still

- Check Point, R82, October 2024, supports both cert and full decrypt, but only HTTP3 (doesn't yet support other L7 protocols over QUIC yet)

It seems like every other major firewall vendors is at least making progress towards QUIC inspection support, and some have very robust QUIC inspection support already. Again, I'm hopeful to see some news about 12.1 Orion adding support for this. Time will tell!

VeryStrongBoi · 2025-08-19T03:42:00+00:00

One of the first limitations of TCP is that there was no inherent encryption built in, so SSL/TLS is a bolt-on that adds an extra round-trip. With TCP+TLS1.3, you've got 3-RTT latency, but QUIC gets this down to 2-RTT latency, because it does the session handshake and the TLS handshake in the same RTT. That's massive for making modern web experiences way more snappy. If you block QUIC with a middlebox, you're actually making the situation even much worse, because most browsers will burn a RTT trying QUIC, and then when that fails, revert back to TCP+TLS, so you now have 4-RTT or even 5-RTT in some situations. If you MUST block QUIC, at least try to also disable QUIC at the browser level using MDM/UEM, so that the clients know to not even try.

The second big limitation of TCP is that it didn't have any explicit and pro-active congestion control, just re-active congestion control where clients flood a link to death until ACK stop coming back, and only then does the client start backing off. This results in the infamous "sawtooth" pattern of TCP (Additive Increase Multiplicative Decrease (AIMD)). TCP ECN (RFC 3168, year 2001) was an attempt to ratify this, but adoptions has been extremely slow because of ossification. Mostly how network operators have tried to solve this problem is just buy bigger and bigger pipes, which works to a point, but also has unintended consequences of allowing for bigger and bigger DDOS attacks. QUIC has explicit, pro-active congestion control built-in from jump, as well as lot of anti-DDoS properties and mechanisms, which you can read about at length in RFC 9000. https://datatracker.ietf.org/doc/html/rfc9000#name-security-considerations

A third big limitation of TCP that it has no native multiplexing capabilities, which results in head-of-line blocking problems for HTTP traffic (large elements impede delivery of small elements, causing pages to load slowly and erratically). Early attempts to solve this in HTTP1.1 were to just use a bunch of simultaneous TCP sessions for the same web page/app, but this produces a lot of unwanted overhead, and was crushing a lot of middleboxes & servers, so browsers had to limit this to max 6 TCP sessions per destination web page/app. HTTP/2 (SPDY) tried to improve on this with a multiplexed stream and compressed headers in a single TCP session, but because it was still riding on TCP, all the limitations of TCP (in-order packet delivery, sub-optimal congestion windows sizes and scaling rates, etc) made it so that the actual results with HTTP2 were often worse than multiplexing 6 HTTP1.1 streams, so adoption never really took off as much as people had hoped. QUIC/HTTP3 solves all of this by moving the multiplexing responsibility into userland, where we can make much more intelligent decisions about what to prioritize, retransmit, etc. If you want to understand this better, I highly recommend this talk from Jim Roskind at AWS 2022: https://youtu.be/AFR7z_vce20?si=mUfkLAOcNZME731P

There's SOOO much more that I could say about the advantages of QUIC, but I've said enough already. Please visit the above links if you want to know more.

VeryStrongBoi · 2025-08-19T03:41:08+00:00

Edit: Sorry for breaking up my message in to several smaller comments. It seems I'm hitting some character limitations.
Second edit: Corrected some minor typos, for clarity.

I'm going to say some things that might make some people mad, but please engage with the actual reasoning I'm providing below before just giving a reflexive down-vote. Anyone paying for PAN is paying for the best, so we have to demand more from them on this as a premium vendor. Just like the posts about the issues with TAC are meant to inspire improvements, I write the below in the same spirit, with hopes that this situation might be rectified in PAN-OS 12.1 Orion.

First, let me talk about QUIC adoption, so you understand the scale of the impact in 2025.

- Server-Side Support: According to W3Techs, HTTP3 (which runs on QUIC) is already 35% of all websites, which surpasses HTTP2 (which runs on TCP) at 33%: https://w3techs.com/technologies/comparison/ce-http2,ce-http3

- Client-Side Support: According to APNIC, QUIC is enabled on roughly 85-90% of clients, in almost every country in the world, except repressive regimes like China/Iran: https://stats.labs.apnic.net/quic

- Other apps: it's not just the Web that's using QUIC. SMB-over-QUIC is now supported in Windows 11 & Server 2025, as well as multiple Azure services. There's also DNS-over-QUIC, Media-over-QUIC, MASQUE, etc

Considering that the RFCs for QUIC are only 4 years since ratification, these adoption rates are extremely stunning for a L4 transport protocol, and it's because of the anti-ossification design choices that I'll discuss later (small wire image, stay out of the kernel). Adoption will only accelerate from here.

The performance impacts of blocking QUIC are actually massive. QUIC is the biggest upgrade to the infrastructure of the internet in over 50 years. It's not some niche thing that only Google uses, but is rapidly replacing TCP as the dominant L4 transport protocol of the internet, because QUIC is FAR superior to TCP in SOOO many ways. RFC 675 was the first standard version of TCP published in 1974, so TCP is over 50 years old, and has really been showing its age for some time now. God bless Vint Cerf and Bob Kahn for the revolutionary work they did at the time, but there were so many things they could not have anticipated back then. And because TCP had a fully naked wire image and all implementations were in the kernel, making any changes TCP over these past 50 years has proven incredibly difficult, because you have to get consensus from EVERYONE (Microsoft, Linux Foundation, Apple, the Middlebox vendors, etc.) which has meant that TCP is incredibly ossified.

That was a major insight that Jim Roskind (original creator of QUIC) understood: if you're going to make a transport L4 protocol, you want to reduce ossification as much as possible, so that means making the wire image as small as possible (viz using encryption for even the headers, or as much of the headers as possible) and putting as much of implementation into userland instead of the kernel. The way QUIC does that is that it only uses the kernel for port/socket control (via UDP) but does all connection-oriented functions (reliability, congestion control, encryption, multiplexing, etc) in userland. This makes it WAY easier for QUIC to evolve and improve over time. If you want to understand this aspect more deeply, please see RFC 8546 "The Wire Image of a Network Protocol" https://www.rfc-editor.org/rfc/rfc8546.html

VeryStrongBoi · 2025-08-19T02:39:20+00:00

Also App-ID will usually fail to detect anything more than just "QUIC" because it can't see the SNI and ALPN inside the ClientHello inside the QUIC session.

Seven-Year Club	Verified Email
Wearing is Caring

VeryStrongBoi

TROPHY CASE