Hacker News new | ask | show | jobs
by dobin 982 days ago
Full inspection of user traffic is required to implement:

* 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.

3 comments

> I dont see how this breaks security

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.

A competent organisation will have a root certificate trusted on all machines so you won't be ignoring certificate errors. You are right however that you are funnelling your entire corporate traffic unencrypted through a single system, break into that and you have hit the goldmine.
> A competent organisation will have a root certificate trusted on all machines so you won't be ignoring certificate errors.

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.

Correct, this is table stakes to get SSL Decryption working for any vendor. Typically we're talking about Windows PC's joined to Active Directory and they already trust the domain's CA. The firewall then gets it's own CA cert issued by the domain CA, so when you go to www.facebook.com and inspect the certificate it says it is from the firewall.

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).

Yes, if you want/need to do those things, then you need to inspect user traffic. But why do you want/need to do those things in the first place? What's your threat model?

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.

Most of what you said is inaccurate in practice.

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.

Everything I wrote earlier is based on the use of Zscaler proxy at work, so it's very much about practice, not theory.

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/

[1] https://blog.cloudflare.com/http3-usage-one-year-on/

Oof, I’ve complained about practical problems in my developer life above, but that’s even worse than I thought. I was able to reproduce dh1024 and no-sct on my work laptop with zScaler. Interestingly it blocks the revoked one by turning it into a self-signed one.

Also failing:

- pinning-test

- all dh*, except for dh480 and dh512

> Interestingly it blocks the revoked one by turning it into a self-signed one.

Well spotted! That's crazy...

> But why do you want/need to do those things in the first place? What's your threat model?

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.

This assumes Randy is incompetent, but not malicious. Nothing is stopping an attacker from contacting Randy out of band, say over a phone or personal email, and then blackmailing him to get him to hand out company information. The key here is to scope down Randy's access so that no matter what kind of an employee he is, the only access Randy has is the minimum necessary and that all of his accesses to company information is logged for audit and threat intelligence purposes.

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.

I think the undertone of your comment says a lot - corporations that feel the need to MITM all traffic tend to not trust their employees (from my experience dealing with this area) - either their competence or their work ethic.

All round, full traffic inspection is generally a bad idea except for some very limited cases where there is a clearly defined need.

In which case as Randy only has access to a few files you simply restore the snapshot of those files and away you go.
* Data leaks are not prevented by MITM attack. A sufficiently determined data leaker will easily find easier or elaborate ways to circumvent it. * Malware scanning can be done very efficiently at the end user workstation. ( But always done inefficiently ) * How domain blocking requires a MITM? * C2 scanning can efficiently done at the end user workstation. * Audits does not require "full contents of communication"

Is MITM ever the answer?

Stealing a valid communication channel and identity theft of remote servers is in fact break basic internet security practices.