[acdha]

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

[ta1243]

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.

[acdha]

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

[Bluecobra]

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