For those following along, over the past two months there have been several reports, warnings, blogs and other industry analyses suggesting that HTTPS inspection by security companies is actually weakening security.  Those that know me well know that I am a huge proponent of performing HTTPS inspection.  I found myself arguing against the recommendations of various advisories that suggest the very thing I have been saying, or rather preaching, for the past several years was now bad.

To start at the beginning, I suggest you examine the root of this challenge: the HTTPS traffic and why it is what it is.  There are several reasons why we all wound up surfing an encrypted internet, and while some would blame various breaches, scandals and/or privacy concerns, the result is the same.  The vast majority of the sites that we surf on the internet today are encrypted.  This rightly includes things like banking and e-commerce sites, but it also includes all things social media and web mail. Even a simple internet search is now encrypted within an HTTPS session.  Some would argue explicitly and indefinitely that this is a great leap forward for privacy and that of course would include the bad guys.

That’s right, in this mad rush to encrypt the internet we have seemingly encrypted all the threats that go along with it.  In fact, if you really think about it, every major breach in the past five years either leveraged malicious payload inside the encrypted communication or was carried out against encrypted traffic.  This of course includes attacks such as spear phishing and ransomware embedded in encrypted webmail.  Here a few of the stories that recently got a lot of press:

  • The OPM Breach, March 2014 – resulted in approximately 18 million people having their personal information (including background data on individuals possessing classified and top secret clearances) leaked all over the web. The breach occurred because internal OPM employees were compromised when accessing their personal webmail accounts through malicious attachments, which were obviously encrypted and thus went uninspected.
  • The breach of the DHS, FBI and Justice Department of the United States, February, 2016 – when nearly 30,000 agents had their personal information leaked online due to a single compromised email account.
  • Snapchat breaches (yes, plural: two big ones – 2014 and 2016) – these breaches resulted in millions of users as well as Snapchat employees having their personal details released.
  • My favorite, the Ashley Madison Breach, 2015 – caused by a spear phishing campaign that resulted in a brand new, perfect hit list of only 37 million users.
  • The IRS Breach (I know, there are a few to choose from) in 2015 – exposed over 700,000 Social Security numbers just by normal processes embedded within the HTTPS site.
  • The Yahoo Breach, 2014 – caused by a single employee getting spear phished and resulting in leaking of over 1 billion accounts, passwords, and secret question information.

Again, in each of these breaches, and thousands more I didn’t list, the attack was carried out by either compromising the actual encryption of the sites of these companies, or by delivering malicious content through typically encrypted communications like webmail and social networking sites.  The baffling part is that the vast majority of these breaches could have been prevented by proper security procedures, certainly some end user training and yes, inspecting within the encrypted communications.

Here is where things get confusing and somewhat argumentative, thus the decryption war.  In order for security vendors to inspect the encrypted connection or payloads within the encrypted session itself, they must act as a man-in-the-middle and essentially break the encrypted session between the client and the destination site or service.  That is the rub to various providers who are attempting to ensure the privacy of the end user client connection, when here comes the security vendor to break that encryption deliberately to look inside.  The providers lock it up, the security vendors break it open.

In some cases, this level of inspection is even mandated by federal law.  It’s required to block things like pornography in K-12 schools and there are serious consequences if an organization fails to do so.  I am not just talking about blocking a notorious URL of a popular site, but remember when I wrote above that even internet searches are encrypted.  Well go to your favorite search engine, select to search by images and enter the dirty word of your choice.  At this point, assuming you don’t have safe search enabled, you may be surprised at how well your search engine works to find things.  But again, if you want to keep little Timmy off those search results, HTTPS inspection is paramount.

Yes, I am sure that I will hear pushback by some that say that the privacy of end user computing is more important than keeping little Timmy off of some adult images, but let’s look at another aspect, the enterprise.

Assume the large banking institution that manages your entire life’s savings hires a new employee bent on getting rich quick.  In this economy that is not a stretch to imagine.  One day, while working late, they open a file containing the top 1,000 most lucrative accounts, including yours, and upload it to their personal cloud storage drive or webmail account that is obviously front ended by HTTPS.  How can the bank’s data leakage policies be effective if they can’t inspect inside the HTTPS traffic?

Another example you say?  Okay, what about a harmless little scenario including a small county government.  Believe it or not the county and municipal networks have a lot of personal identifiable information that may pertain to you.  Maybe county records, medical information, employment records or even tax information.  Let’s assume an employee of the county falls for a spear phishing scam in their email or instant message application that unlocks and exflitrates all of the information about you that should have been safeguarded.  Are you okay with that?

The truth is simple.  If you are not inspecting your encrypted communications, then you are essentially blind to more than sixty-five percent of your overall internet usage.  Think about that.  To put that math into simple numbers, if you have a 100 Mbps Internet connection, then on average you may have 65 Mbps that you are not safeguarding.  That equates to roughly seven full length DVDs worth of data an hour.  So, the real question you should be asking is, “Do I feel lucky?”

In the defense of the data providers, there is a point of responsibility on behalf of the security vendors to ensure that they while they are inspecting and performing as a man-in-the-middle, they are not weakening the overall encryption level of the connection.  Meaning they cannot substitute stronger forms of encryption with weaker forms and subsequently some of the various security vendors are in fact, doing this.  However, from the security vendor perspective it is absolutely absurd that any network should inherently trust providers.  This applies directly to various providers from rushing out new forms of encryption that the security industry cannot yet inspect or protect.  The only result will be allowing more threats into the network.  I am sorry, providers, I refuse to simply trust you completely when it is readily proven that you are not always 100% secure.  With that, I will always inspect my encrypted traffic, and as a seasoned cyber warrior, I will always err on the side of caution.

Trust, but verify. 

Download a Solution Brief: Best Practices for Stopping Encrypted Threats

Join my live webcast on May 10.

Watch Webcast

FacebookTwitterGoogle+LinkedIn
Rob Krug
Solution Architect, Security | SonicWall
Rob Krug is currently a Senior Systems Engineer for SonicWall. He has been in the network security space for nearly 25 years, and has certifications in both networking and security disciplines as well as all SonicWall certifications.  Rob has an extensive background in network design, engineering, security, and telecommunications, and is a past SonicWall System Engineer of the Year. 

0 comments

Leave a reply

thirteen − eight =