Comment by iso1631
15 days ago
So deploy end point security, which sits in the kernel and can thus access the unencrypted communication
15 days ago
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.
3 replies →
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.