Breaking TLS: Good or bad for security?
As the use of TLS by malware and phishing increases, some security practitioners are seeking solutions to break TLS so they can monitor all traffic in and out of their network.
Breaking TLS is typically accomplished by loading an inspection CA certificate that dynamically generates certificates by your TLS inspection device. The public key from this CA is loaded into all clients on the network. When a domain is requested, a certificate is generated “on the fly” and returned to the requester. The requester has a trusted connection to the TLS inspection device, and the device then initiates a connection to the destination. The user has a “trusted” connection to the resource they requested and the security team can perform monitoring of the entire session. This is often referred to as a man-in-the-middle, as shown in the graphic below.
I feel that this quest for visibility is taking us in a dangerous direction. Ultimately, I believe that breaking TLS is a bad idea. I have a couple of reasons for my thinking.
1. We’ve conditioned users to “trust the lock”. I think trust in the browser is a cornerstone of a good security program. If I accidentally click on a phish today, I’m going to notice that the connection is not secure and close the window. When you break TLS, you open up your users to all kinds of phishing attacks by always showing them a green lock. Given that 90% of attacks start with a phish, I believe that breaking TLS will ultimately hurt security.
2. When you mess with TLS, lots of tools break. Some apps have either very strong (certificate pinning) or very weak (automatically verifying some fields in a presented CA for validity) validation mechanisms. When you insert yourself in the middle of these, you are guaranteed to break apps in unexpected ways. This is a really rotten thing to do to users and a guaranteed way to get them upset at “the security guys”. I’ve personally seen developers waste countless hours because the tools they use to do their job were impacted by breaking TLS.
3. I’m opposed to network security monitoring at this level. Collecting all of the network traffic at your gateway and then analyzing it is a lot of work. Intrusion detection requires a multi-million dollar investment in not just the intrusion detection software, but security event management and, most importantly, people to monitor the systems. Ask yourself “For what?” When was the last time you found an intruder with your intrusion detection infrastructure?
What you should do
If you don’t have a compelling answer for the question above, please consider an alternative use of your time and resources. I think security practitioners should put their precious energy into user education, instrumenting web apps with useful monitoring, rolling out password managers, and enforcing two factor authentication everywhere. If you have extra time, get faster at patching.
Four phases of phishing protection
I’m not simply talking about making your users watch videos or play cheesy games. Your job is to engage with them and convince them that the threat is real and they are part of the solution. We see phishing protection as four phases: education, evaluation, reporting, and enforcement. Build your phishing protection program by investing time and resources into each of these phases.
Education and evaluation makes your users aware through conversation and then tests them to see if they click. This is becoming commonplace. What’s less common are the final two phases: reporting and enforcement. These trained users should be comfortable coming to you and discussing suspicious e-mails they get. Get them in the habit of forwarding them to a mailbox that your team monitors. There are some gems in there. Use these gems to protect the users if one of them mistakenly clicks. Do this well and you can turn the mantra of “it only takes one click to lose everything” to “it only takes one phish being reported to protect everyone”.
Instrument your web apps
We run a web app hosted in Amazon and have hooked every important event (we can find) in-app to Slack. Our ops channel monitors exceptions, user password resets, user and admin logins/logouts, important netfilter events, and privileged user events (updating an IP, adding a domain). We even have automated jobs run to score our security (think ssllabs) that let us know when systems need patching. By paying attention to the things that matter in our web app, our security team has the right information in the right context to make the right decisions. Slack wrote a wonderful blog about their experiences doing just this. We recommend it.
Improve password management
This last line of effort focuses on removing all traces of password reuse from your enterprise along with pushing two-factor authentication everywhere so that if passwords are stolen, they aren’t worth much for long.
With such scarce resources (time, if not money), we urge you to focus your security program on things that make a difference against attackers and not more cumbersome monitoring that will require more people and tools. Using some of these simple strategies we lay out here, you can build a security program that matters without breaking the bank.