I hate corporate IT. Security with decades old arcane practices. Killing user experience with any way possible. MITM all around..
Compliance. You think your IT dept wants to deploy this crap? How ever painful you think it is as an end user multiply it having to support hundreds/thousands of endpoints.
Look, I hate traffic inspection as much as the next person but this is for security, it's just not for the security you want it to be. This is so you have an audit trail of data exfiltration and there's no way around it. You need the plaintext to do this and the whole network stack is built around making this a huge giant pain in the ass. This is one situation where soulless enterprises and users should actually be aligned. Having the ability in your OS to inspect the plaintext traffic of all incoming and outgoing traffic by forcing apps off raw sockets would be a massive win. People. seem to understand how getting the plaintext for DNS requests is beneficial to the user but not HTTP for some reason.
Be happy your setup is at least opportunistic and not "block any traffic we can't get the plaintext for."
Yes, they do.
I had never experienced just how much power a single dept could hold until we got acquired by a large finance enterprise and had to interact with the Risk dept.
At the end of the day, it's not your network/computer. There's always going to be some unsavvy user duped into something. If you don't like corporate IT, you're free to become a contractor and work at home.
Instead that Corp IT should have put a transparently working antivirus/malware scanner on the workstation that would prevent that download to be run at all. ?
DPS/MITM are not security layers but more of privacy nightmares.
Sure. Then come the complaints that this slows down endpoint devices and has compatibility issues. Somebody gets the idea to do this in the network. Rinse. Repeat.
Unfortunately they still do MITM which breaks connections regularly.
Why do you care so much about your privacy while you're on company time using their computers, software, and network? If you don't like it, bring your own phone/tablet/laptop and use cellular data for your personal web browsing. FWIW, it's standard practice to exempt SSL decryption for banking, healthcare, government sites, etc.
Particularly MITM practice is a net negative. Rolling password resets and bad password requirements are also net negatives. Scanners which does not work as intended, which are not proofed at all and introduce slowness, feature breaks are possible negatives.
Also at some places they introduce predatory privacy nightmares like key loggers, screen recorders..
* Data leakage policy (DLP; insider threat, data exfiltration)
* Malware scanning
* Domain blocking (Gambling, Malware)
* Other detection mechanisms (C2)
* Logging and auditing for forensic investigations
* Hunting generally
I dont see how this breaks security, and of course you also didnt elaborate on why it should be. Assumed TLS MitM is implemented reasonably correctly.
Dont worry tho, zero trust will expose the company laptops again to all the malicious shit out there.
You’re training users to ignore certificate errors – yes, even if you think you’re not – and you’re putting in a critical piece of infrastructure which is now able to view or forge traffic everywhere. Every vendor has a history of security vulnerabilities and you also need to put in robust administrative controls very few places are actually competent enough to implement, or now you have the risk that your security operators are one phish or act of malice away from damaging the company (better hope nobody in security is ever part of a harassment claim).
On the plus side, they’re only marginally effective at the sales points you mentioned. They’ll stop the sales guys from hitting sports betting sites, but attackers have been routinely bypassing these systems since the turn of the century so much of what you’re doing is taking on one of the most expensive challenges in the field to stop the least sophisticated attackers.
If you’re concerned about things like DLP, you should be focused on things like sandboxing and fine-grained access control long before doing SSL interception.
Most orgs don't inspect sensitive things like banking, healthcare, government sites, etc. Also it's very common to make exceptions to get certain applications working (like Dropbox).
You definitely need that but ask anyone who’s done it and they’ll tell you that flushing out all of the different places interception causes problems with pinned certs, protocol level incompatibilities, etc. which inevitably someone will try to solve by turning off some security measures. This will inevitably include this like your help desk people trying to be helpful and not realizing that the first hit on Stack Exchange suggesting adding “-k” is not actually a good idea.
This is exacerbated by the low quality of the vendor appliances most places use to implement these policies. For example, Palo Alto will break the Windows SChannel certificate revocation check - there’s still no workaround but I guarantee you won’t know all of the places where that’s been disabled. They also don’t support the secure session renegotiation extension to TLS 1.2 (RFC 5746 from 2010) which I know because OpenSSL 3 started requiring that and had to stop multiple teams from “solving” using a terrible solution from the first hit on Google. Amusingly, they do correctly implement TLS 1.3 so I’ve been able to fix this for multiple open source projects by getting them to enable 1.3 in their CDN configuration.
Doing this breaks the end-to-end encryption and mutual authentication that is the key benefit of modern cryptography. The security measures implemented in modern web browsers are significantly more advanced and up-to-date than what systems like Zscaler are offering, for example in terms of rejecting deprecated protocols, or enabling better and more secure protocols like QUIC. By using something like Zscaler, you're introducing a single point of failure and a high value target for hackers.
Not everyone in a company is savvy or hard at work. Randy in accounting might spend spend an hour or more a day browsing the internet and scooping up ads and be enticed to download something to help speed up their PC which turns out to be ransomware.
That's the problem with these MITM approaches. They open up a new security SPOF (what happens if there's an exploit on your MITM proxy that an attacker uses to gain access to the entire firehose of corporate traffic) while doing little to protect against malicious users.
All round, full traffic inspection is generally a bad idea except for some very limited cases where there is a clearly defined need.
A competent org and good mitm device will have trusted internal root certs on all endpoints, so cert errors are not a problem. The proxy can be set to passthrough or block sites with cert errors (expired, invalid), so there isn't any "bad habits training" of users clicking through cert errors. Several vendors today support TLS 1.3 decryption.
I don't know what you mean by SPOF for a proxy: they are no more a SPOF than any properly redundant network hop.
A proxy doesn't break encryption. Endpoints trust the mitm.
Now, I think that someday the protocols of the web such as quic will get so locked down that the only feasible threat prevention will be heuristic analysis of network traffic, and running all threat scanning on endpoints (with some future OS that has secure methods of stopping malicious network or executables before said traffic leaves some quarantine).
I'm a network guy, not an endpoint guy.
Yes, of course the Zscaler root certs have been installed on our endpoints. The problem is that the proxy is replacing the TLS certificate of the origin server with its own certificate, which makes impossible for the browser to verify the identity of the origin server and trust the communication. The browser can only verify that it is communicating with the proxy; it cannot verify anymore that it is communicating with the origin server.
That's what makes Zscaler and similar solutions a SPOF. I know that Zscaler is using a distributed architecture with no hardware or network SPOF. But Zscaler is a SPOF from an organizational perspective. If you hack them, you get access to everything. That's what me and other commenters meant by SPOF in that context.
> A proxy doesn't break encryption. Endpoints trust the mitm.
I didn't write that it's breaking encryption. I wrote it's breaking end-to-end encryption and authentication. I'm sure you understand the difference.
> Now, I think that someday the protocols of the web such as quic will get so locked down that the only feasible threat prevention will be heuristic analysis of network traffic
We're already there. HTTP/3 (QUIC) already amounts for about 30% of the traffic served by Cloudflare to humans [1]. QUIC is actually offering a higher level of security by encrypting more metadata that HTTP/1 and 2 (specifically the part within the TCP headers that can be leveraged by an attacker when it is in clear).
> A competent org and good mitm device
That's the main problem. Those proxies are usually less scrutinized and have smaller engineering and security teams than major modern web browsers like Edge, Chrome, Firefox and Safari, and as a consequence have more vulnerabilities.
In general, major modern web browsers enforce stronger security requirements than Zscaler:
- For example, the following website, using a potentially insecure Diffie-Hellman key exchange over a 1024-bit group (Logjam attack), is blocked by Chrome and Firefox but not by Zscaler: https://dh1024.badssl.com/
- Same for that website using a revoked certificate: https://revoked.badssl.com/
- Same for that website requiring certificate transparency but not sending a Signed Certificate Timestamp: https://no-sct.badssl.com/
Also failing:
- pinning-test
- all dh*, except for dh480 and dh512
Well spotted! That's crazy...
Is MITM ever the answer?
Stealing a valid communication channel and identity theft of remote servers is in fact break basic internet security practices.
Yes, but TLS inspection is not the solution.
> Google is already experimenting with no Internet access for some employees, and that might be the endgame.
Source? And I'm pretty sure they are not considering disconnecting most of their employees who actually need Internet for their job.
Eventually I think the endgame here is that you use your own personal BYOD device to browse the internet that is not able to connect to the corporate network.
By chopping the head off?
it's like call and message logs kept by phone companies.
nobody likes to keep them but it's better than the breaking the law and risking for someone abusing your infrastructure.
it would also be great if my colleagues did not use the company network to check the soccer stats every morning for 4 hours straight, so the company had to put up some kind of domain blocking that prevents me from looking up some algorithm i cannot recall from the top of my mind on gamedev.net because it's considered "gaming"
Blocking the website instead of punishing them in their performance reviews (assuming it does impact their performance, if they're still productive why even care) is useless, they'll use their phones and still spend time on it.
it's not because it's illegal, it's because they are wasting time on the job using company's equipment for something not work related. And usually they end up clicking everywhere on shady ads, trackers etc.
We are in Italy, there's no such thing as performance review here, if you get hired you get paid every month (actually 13 times a year, sometimes 14) and nobody can fire you ever again.
> they'll use their phones and still spend time on it.
their choice on their equipment