cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post

SSL decryption as a security technique: to intercept or not to intercept?

Level 10

Of all of the security techniques, few garner more polarized views than interception and decryption of trusted protocols. There are many reasons to do it and a great deal of legitimate concerns about compromising the integrity of a trusted protocol like SSL. SSL is the most common protocol to intercept, unwrap and inspect and accomplishing this has become easier and requires far less operational overhead than it did even 5 years ago. Weighing those concerns against the information that can be ascertained by cracking it open and looking at its content is often a struggle for enterprise security engineers due to the privacy implied. In previous lives I have personally struggled to reconcile this but have ultimately decided that the ethics involved in what I consider to be violation of implied security outweighed the benefit of SSL intercept. With other options being few, blocking protocols that obfuscate their content seems to be the next logical option, however, with the prolific increase of SSL enabled sites over the last 18 months, even this option seems unrealistic and frankly, clunky. Exfiltration of data, being anything from personally identifiable information to trade secrets and intellectual property is becoming a more and more common "currency" and much more desirable and lucrative to transport out of businesses and other entities. These are hard problems to solve.

Are there options out there that make better sense? Are large and medium sized enterprises doing SSL intercept? How is the data being analyzed and stored?

3 Comments
Level 11

I guess the question really depends on where the SSL interfception is being done? If it is being done through a company you currenty are employed by and using their equipment to reach the network, it should be implied that all the data is the company's property. Thisallows companies to make sure that data is not leaving the company, trade information, data harvesting, etc. That is all the data should be used for.

As far as ISP companies, like AT&T decrypting SSL, this should not be allowed. AT&T is one of the reasons HTTP2 is no longer required to use SSL.

Maybe I am off topic?

Level 10

I am mostly asking from an enterprise security perspective and am trying to feel out the ethics behind it. Since there is implied security with ssl, is it ethical for an enterprise to decrypt that traffic even when those resources being utilized are owned by them? Is it more appropriate to block the services and disallow like many companies do with ssh due to its ability to tunnel?

I have done work with instrumented ssh that is built to reveal the interactive keystrokes for an IDS to consume. It is fundamentally the same, but for some reason doing an intentional MTIM with ssl feels different. In the cases where I have used or implemented instrumented ssh, there is very clear and continual dissemination of the fact that it is happening, mostly due to the fact that credential theft has become to rampant, and the interception is not in the path, it is the actual service itself. Is it the same? I think it mostly is other than the fact that ssl has such a wider scope, but I want to hear more from others. 

Level 15

I think that the better option to ethically look at these data flows, is to verify the destination address of the SSL connection.  If you are looking at exfiltration of data, then by justifying the legitimacy of the destination is the first course.  Then, after you have ruled out that the data is not going strangely, then the use of random SSL interception and review is not out of the question.  I could not justify ethically reviewing every connection but to randomly review would be acceptable. Since there are so many exploits against SSL you would have justification to want to implement addtional security --- say encryption of the payload BEFORE SSL transport -- but you can only justify the costs IF you know how much effort is required to break your SSL data flows and what kinds of data is being sent through the SSL transport.

About the Author
15+ years IT experience ranging from networking, UNIX, security policy, incident response and anything else interesting. Mostly just a networking guy with hobbies including, film, beer brewing, boxing, MMA, jiu jitsu/catch wresting/grappling, skateboarding, cycling and being a Husband and Dad. I don't sleep much.