←back to thread

Stop Breaking TLS

(www.markround.com)
170 points todsacerdoti | 7 comments | | HN request time: 0.211s | source | bottom
Show context
sqbic ◴[] No.46216863[source]
What changed my mind to be in favor of TLS inspection at work environments was seeing what kind of highly confidential stuff employees might be copy-pasting to random websites, LLM assistants, cloud-based "desktop applications" and such against the approved use policies of each of these tools without giving it a second thought.

TLS inspection products can intercept the paste transaction before the data leaves the company network, hitting the user with a "No you didn't! Shame on you!"-banner and notify the admins how a user just tried to paste hundreds of customers' personal information and credit card details into some snooping website, or into otherwise allowed LLM chat which still is not allowed to be used with confidential information.

There can even be automations to lock the user/device out immediately if something like this is going on, be it the user or some undetected malware in the user's device attempting the intercepted action. Being able to do these kinds of very specifically targeted interceptions can prevent potentially huge disasters from happening while still allowing users more freedom in taking advantage of the huge variety of productivity tools available these days. No need to choose between completely blocking all previously unseen tools or living in fear of disastrous leaks when there are fine-grained possibilities to control what kind of information can be fed to the tools and from where.

There are plenty of organizations out there where it is completely justified to enforce such limitations and monitoring in company devices. Policies can forbid personal use entirely where it is deemed necessary and legal to do so. Of course the policies and the associated enforced monitoring needs to be clearly communicated and there needs to be carefully curated configurations to control where and how TLS is or isn't intercepted so employee privacy laws and regulations aren't breached either.

replies(3): >>46216902 #>>46219891 #>>46228067 #
iso1631 ◴[] No.46216902[source]
So deploy end point security, which sits in the kernel and can thus access the unencrypted communication
replies(3): >>46217267 #>>46217823 #>>46217902 #
1. zbentley ◴[] No.46217823[source]
That’s vastly more failure prone (crowdstrike crashes workstations) and abuse prone (kernel code has the highest privilege level) than processing network traffic at the network/TLS level.
replies(2): >>46218075 #>>46220833 #
2. mirashii ◴[] No.46218075[source]
In practice you don't actually need kernel code on a bunch of platforms for this, e.g. NETransparentProxyManager on MacOS. This is not necessarily an endorsement, just worth not mixing in unrelated issues.
3. iso1631 ◴[] No.46220833[source]
It's also normally deployed by companies who want this level of access anyway

If you don't then you're simply open to encrypted comms over your deep inspection TLS breaking box anyway

replies(1): >>46227443 #
4. zbentley ◴[] No.46227443[source]
Eh, I'm not so sure. Most companies are only somewhat serious about infosec, so they run some light endpoint protection or BYOD, but don't do much network-level restriction on end user devices. For companies in that position, it's much cheaper to do that at the router/VPN endpoint layer with TLS interception--not only is the pricetag of doing that usually a lot lower than the per-seat license of a more capable endpoint protection system, but configuring endpoint protection to allow what it should and not what it shouldn't is a constantly moving target with a failure mode of "breaks someone's workstation and then they have to call IT". IT departments are expensive to staff compared to one or two network administrators issuing edicts about the specific man who is standing in the middle of the SSL link on a particular day.

Also, a lot of nominally serious companies care a lot more about preventing nontechnical employees from watching porn or netflix on company devices/connections than they do about data exfiltration, or any risks posed by employees technical enough to know what phrases like "double encryption" or "TLS MITM evasion" mean.

replies(1): >>46230334 #
5. iso1631 ◴[] No.46230334{3}[source]
IP level blocks will work fine for that
replies(1): >>46232991 #
6. acdha ◴[] No.46232991{4}[source]
Blocking IPs hasn’t worked well since the 2000s: if you block CDNs, you’ll find out how many legitimate services use the same CDN.
replies(1): >>46240049 #
7. zbentley ◴[] No.46240049{5}[source]
Yes. And malicious egress traffic (bad actors or malware exfiltrating data) typically routes to deliberately-unpredictable and constantly changing IPs.

Like, I don't love TLS MITM-ing. It's not a good thing. But it's the least bad of the options available for solving a problem that many people have decided must be solved (regulating behavior on a LAN).