Hacker News Reader

Comment by iso1631 | Hacker News Reader

So deploy end point security, which sits in the kernel and can thus access the unencrypted communication

While eps, edr, etc. solutions have their role in security and some of the products can be used for "TLS inspection" within the localhost already, doing the inspection in separate network appliance brings benefits such as (but not limited to) not needing to care if the client operating system is supported by the eps product or if the eps is functioning correctly, offloading the "heavy lifting" and policy enforcement to the appliances and ensuring that only actual real egress connections to specific services are inspected.

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.

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.

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

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.

IP level blocks will work fine for that

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.

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

Aren’t most TLS implementations still using things like OpenSSL in userspace? How would the kernel get access to the request?

A process with kernel level permissions can patch into userspace process an intercept calls. For example https://github.com/SebastienWae/sslsnoop

You’ve still gotta do that for every TLS library used then. There’s a finite list of them of course, but it’s more than just a few.

Reply on news.ycombinator.com