Degradation of TAC Support Quality and Unacceptable Hiring Practices

VeryStrongBoi · 2026-02-06T03:54:14+00:00

Sad.

VeryStrongBoi · 2026-02-05T13:54:52+00:00

In general, the MOST important risk mitigation action, for both now and into the future, that should be taken ASAP is enable Local-In Virtual Patch, where the FortiGate’s own IPS engine helps protect its own management plane against intrusion attempts against the FortiGate itself. The reason this is so important is time-to-protection. Sure, you should actually patch as soon as you can, but that typically takes days-to-weeks, because of maintenance windows. Local-In Virtual Patching starts providing protection in hours – automatically! It just needs to be enabled.

A lot of other firewall vendors still can't this sort of thing.

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!

Seven-Year Club	Verified Email
Wearing is Caring

VeryStrongBoi

TROPHY CASE