These firewall boxes are on-prem white hat Mallory, reverse-reverse-proxying all TLS traffic. And of course the Linux stack it uses has tons of RCEs and misconfigurations.
Isn't that just insecure???
Take a look at Palo Alto's applipedia[1], it has 4419 protocols/services that you can detect and write security policy for without decrypting anything.
One example, last week our firewall blocked a suspicious (but but in this case legitimate) site using DNS sinkholing, because the domain seemed suspicious (uncommon TLD + recently registered domain).
Suddenly a lot of stuff stopped working, because not every piece of software on my machine uses the OS's certificate store.
For example Docker containers who then curl to set up stuff.
I had to talk to him and say look, what you're trying to do isn't possible without breaking things. It's not a limitation of the products, it's a limitation of the underlying security that you're trying to bypass, and you're making security WORSE, not BETTER.
He wanted to log every employee's Internet traffic so that he could determine if someone was leaking company data, such as source code, customer data, etc. I said that there's nothing you can do to stop that, and even if someone knows their traffic is being monitored, it's easy to bypass by just adding a second layer of encryption.
They asked me to be a Git reviewer for their big workaround, and I found around a dozen new vulnerabilities and future build-breaking defects that the workaround introduced.
I also told them that it's unreasonable for this other team to ask them to work around that mess, and the solution is for the other team to do the thing in a different, much simpler way. I also ended up raising some even bigger security decision problems with the C-suite.
As one engineer from a different team told me (after they'd given notice of leaving, and kindly granted me an exit interview), the company had too many people making other people's jobs harder, for no reason.
A too-entrenched-to-fail-soon company might be able to justify that (say, it was the easiest way to check off a compliance box, with their encumbered velocity at implementing anything). Most companies aren't that, though.
Security teams are often staffed by people who have no operational experience, and do not understand the consequences of what they are recommending or even mandating. Often those staff are blindly following hardening guides or asking for every configuration switch to be flipped to "most secure" setting without having a good understanding of the threat model for the workload and without taking into account the tradeoffs between utility and operational cost. The level of advice can be on par with ChatGPT or worse, but it is taken more seriously due to the advice-giver's job title.
Security teams often have no "skin in the game". There are no real disincentives to stop them from asking for crazy or very expensive things and imposing high costs on other teams. In fact they are incentivised to do that very thing, because the only thing that covers your butt more than recommending everything possible, is recommending everything possible PLUS some things that can't be done with the time & budget available, leaving them able to say "we see you had $security_problem, well, we recommended $impossible_thing but you didn't do it" (e.g. say, $500k of DLP solution [with its own operational risks!] for a workload that only makes $1M a year). To be fair I've seen some good & practical security teams but once you get a bad actor / games player at management level that behaviour can become very sticky.
I have seen variants of this nearly everywhere I've worked, it seems very hard to get incentives aligned between the do-ers and the secure-ers.
The most practical workaround I've seen is to make sure there is a reasonable balance of political power between the various parties.
"Reasonable" can be hard to establish but is context dependent. You would expect "Security" to have more power in an F500 because the brand value, financial and legal exposure are high and individual dev teams aren't necessarily across or exposed to the full consequences of the damage they can cause.
In a startup you would expect "Security" to have much less power because the consequences of not shipping / misallocating effort are almost immediately existential.
The fact is that security is a holistic concept and can ONLY be evaluated in context. That in turn requires good technical and operational knowledge. But people like that are rare and expensive, so instead we have entire armies of box-tickers who lack the intellectual capacity to even understand what a "tradeoff" means.
Something went terribly wrong around the mid-90s, when security changed from a discipline practised and understood by hands-on professionals into a consulting gig.
Disclosure: I've been doing infosec professionally since 1993.
1. put all assets into infrastructure you control, allow pulling only from that infrastructure, no exceptions.
2. understand your containers enough to be able to modify and manage their trusted CA / TLS chains.
You really ought to be in a position to manage your supply chain and you really ought to be in a position to manage what your containers trust. Certainly more work and inconvenient, and maybe not practical everywhere, but worth doing even independently of a middleware box, at least once you get to some level of "in production for reals"
You seem to be singularly focused on the software quality of the VPN. It’s important, but is far from the only aspect of security.
The company is worried both about keeping the bad guys out of their network and keeping their IP + secrets inside. The motivation for the TLS MITM blinks boxes is for the latter.
It’s easy as an employee to simply discount the value of decrypting your internet traffic, but the truth is that the company has a responsibility to protect against malicious insiders, malware/ransomware exfiltration, etc.
These boxes provide a one-stop hacker shop for all data exfil and malware injection that normally don't exist. In theory they can _sign security updates_, send fake announcements, just intercept, redirect and drop emails, etc. It's just too hard for me to understand how it's supposed to add security, unless these would be NSA endorsed or something.
The SSL forward proxy feature of Palos has a number of things that preserve the security of TLS connections, such as requiring a minimum TLS version, "passing through" cert errors like expiration or bad CN, and so on.
I've worked with PA firewalls for a while.
So you’re essentially admitting that these TLS boxes are more about controlling employees and “data loss prevention” than actually preventing real threats and doing honest security. Got it.
I think the parent commenter was pointing out that "MITM TLS box" has nothing to do with sshd scans. Not that MITM TLS boxes have no use.
Oh, and #4 on that "tenets of honest security" is an opinion not shared by all.
In the modern era of guest wifi and ubiquitous personal mobile devices, personal use on a work machine is not necessary or advisable. That said, in most places it is common to *not* decrypt websites related to health and government and banking.
Everything is about liability and protection of company data.
Personal use was not the norm. Locking machines down was. VPNs, corporate network perimeters, blocking copy paste (my god), TLS middleware boxes. It all sucks. And inspecting internet traffic is a breach of human rights among adults.
Then we grew out of it. Now we have identity perimeters. Strong identity and yubi keys, webauthn, SSO. Honest.security reflects how people operate today. Modern IT stacks operated by ethical teams don’t do traffic inspection.
We agree, TLS inspection is about control, not security. And that’s why it’s unethical.
“No personal use” also just doesn't work, ideologically. Gotta access your bank for payroll, financial stuff for 401k, RSUs. HR portal has to be accessible on the personal side too for taxes healthcare and emergencies. Been there done that move on.
I will concede that there are isolated highly security sensitive situations where full device control is needed like maybe for the employees or machines with access to a CA or production deployment keys or classified information with human loss of life at stake. But the no personal use mantra is not a blanket philosophy that’s healthy or good for modern society and isn’t relevant in 99.99% of use cases.
You can even look at MDMs which have shifted from full device control to hybrid support.
a business... without context this appears to be a "free" card for any amount of micromanagement or intra-company snooping.. locks on the cabinets with the cheap coffee in it.. that level of petty.. sure, there are larger objectives but the way this is said, there appear to be no checks and balances.. it could be like a fish-in-a-barrel snooping free-for-all.
as one reference, UC Berkeley put in "deep packet inspecting" mail servers more than 12 years ago.. to watch faculty email content.
Examples:
I was the regional IT director at an extremely large, French owned, financial organization that had a child pornography ring operating among a couple of employees and several outside entities. The investigation and apprehension involved the FBI.
At the same company: FINRA investigation into illegal insider trading at the commodities brokerage part of the company.
This stuff is going on all the time. Some of it involving law enforcement, national intelligence services (I have worked with fusion centers several times, too), and internal HR/legal.
You just don't know about it because you aren't in ops/secops/legal/hr/compliance.
Among reasons one might have seen them was centralised control plane, multipoint VPNs, yes deep-packet inspection (including for simply checking if the expected protocol was running on given traffic), they could be also simply used as pretty advanced router+firewall setup.
I'm just saying that not everyone used PAN NGFW for MITM proxying, and it's not necessary to enable/configure that to use them for other tasks.