A Pragmatic View of Breaking and Inspecting SSL
Sr. Systems Engineer, Versa Networks
October 11, 2023
SSL Break and Inspect (B&I) has always been a point of contention in the security world. On the one hand, we have the network security teams saying, “We should inspect everything on our network and not allow anything that we cannot inspect.” And on the other hand, endpoint teams (server, desktop, and IoT) are saying, “We use SSL for a reason so no one can break in and man-in-the-middle our traffic.”
Looking at this from the larger viewpoint of endpoint security, SSL and B&I are both needed and have their place. Considering even the strongest endpoint security software, the risks vary from device to device and the same level of risk cannot be assumed for all devices and software. So, if the risk of a compromised device is high, and the cost impact of a compromise would be greater than the cost of mitigation (via B&I), then in my mind B&I is required. It is a matter of closing the door to or countering the attack techniques of bad actors, including insider threats.
Attack techniques that B&I mitigates
So, let’s talk about techniques and risks that are mitigated by B&I, and then hopefully you can decide whether it is worth accepting the risk or if you should go ahead and implement B&I. While MITRE ATT&CK specifies a few techniques that are mitigated by SSL (see https://attack.mitre.org/mitigations/M1020/), I would like to get into a little more detail. Here are a few additional scenarios that SSL B&I can help to mitigate:
- Initial Access – In the Initial Access phase, drive-by compromise, phishing (and variants thereof), and supply chain compromise all could be using SSL/TLS (and are likely to).
- Compromised Website – If an endpoint visits a compromised, trusted website using SSL/TLS, and your endpoint security software does not detect it as a threat (i.e., a false negative).
- Unprotected Devices – If devices that cannot run your endpoint security software (IoT, servers, etc.) visit compromised sites or are used as a control channel using SSL/TLS.
- Compromised Endpoint Control Channel – The control channel of a compromised endpoint can now be encrypted using SSL/TLS and bounced through a ‘trusted site.’
- Compromised Endpoint Exfiltration – A compromised endpoint or an insider threat actor can hide exfiltration of data using SSL/TLS.
Social media ads are often a channel for some of these techniques, along with the “Big Three” cloud providers’ hosts. We cannot realistically block all social media or major cloud providers, so B&I is more a realistic mitigation.
Now it is not all rainbows and butterflies in the B&I world, don’t get me wrong. B&I is the most computationally heavy process that I know of in the network and security space today. In addition, when it comes to all the deep inspection processes needed, we are talking about tremendous resources that will impact the user experience. This deep inspection is just one part of the puzzle, where there are multiple other pieces: application level firewall, inspection for viruses and malware, DLP, as well as evaluation of user rights to access and send content. With all that said, the security industry and implementers must keep in mind that the security architecture should not compromise the network’s resilience or usability. If either of those two things happen, users and management will turn on you quickly.
Tips on how to B&I
Some thoughts to guide you in applying B&I:
- Start small with a few endpoints or users and a few URL categories, many vendors have a few great ones to start with: unknown, risky, etc. You don’t need to inspect everything the first day.
- Know your users’ applications, the URL categories in use and each TLS version in use.
- Know your organization’s certificates and trust chain. Also learn which applications are using pinned certificates and know how your vendor’s B&I can help you with that. (A lot of mobile devices and mobile applications use pinned certificates.)
- Measure the performance of your users’ applications and watch your compute demand and use of resources on your B&I platform. Grow your B&I slowly until your mitigation of techniques is at a comfortable risk level for your origination.
By the way, this is never a one-horse show. As mentioned earlier, the combination of B&I with web content & URL filtering, DLP, application inspection, and IPS are all needed on the network security side to work with B&I. But, for risks that cannot be mitigated with this method, segment them off please! And as always, great endpoint security software and a great IoT solution are must-haves in today’s security landscape (be sure to read up on Zero Trust Everywhere.)
