4 ms·

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

by iso1631 11mo ago

treesknees 11mo ago
Aren’t most TLS implementations still using things like OpenSSL in userspace? How would the kernel get access to the request?
- iso1631 11mo ago
  A process with kernel level permissions can patch into userspace process an intercept calls. For example https://github.com/SebastienWae/sslsnoop https://github.com/SebastienWae/sslsnoop
  - jcgl 11mo ago
    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.
zbentley 11mo ago
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.
- mirashii 11mo ago
  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.
- iso1631 11mo ago
  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
  - zbentley 11mo ago
    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.
    - iso1631 11mo ago
      IP level blocks will work fine for that
      - acdha 11mo ago
        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.
        zbentley 11mo ago
        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).
sqbic 11mo ago
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.

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

by iso1631 11mo ago

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

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

iso1631 11mo ago
A process with kernel level permissions can patch into userspace process an intercept calls. For example https://github.com/SebastienWae/sslsnoop https://github.com/SebastienWae/sslsnoop
- jcgl 11mo ago
  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.

zbentley 11mo ago

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.

mirashii 11mo ago
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.
iso1631 11mo ago
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
- zbentley 11mo ago
  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.
  - iso1631 11mo ago
    IP level blocks will work fine for that
    - acdha 11mo ago
      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.
      - zbentley 11mo ago
        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).

sqbic 11mo ago

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.