Send HTTPS/SSL traffic to Firesight IPS sensors with no decryption?

[Ralphy006]

Hi guys,

I'm not interested in doing SSL decryption. However, I believe if I send https traffic to the Firesight IPS sensors, the sensors can still stop certain vulnerabilities from being exploited (ie Heartbleed) WITHOUT decryption.

Am I wrong? Do most people not even send encrypted HTTPS/SSL traffic to the sensors?

[Rahul Govindan]

The common procedure is to send all traffic (https included) to the sensor. Even if you do not want to decrypt SSL, there are a bunch of other checks that it does, for example destination ip address in Global Blacklist (Security intelligence). I guess this adds some layer of protection to the traffic even if you can't see all parts of it.

[Claudiu Cismaru]

Ralphy, you're correct.

Even with encrypted traffic, the base URL is extracted from the SSL flow so you'll be able to have URL based Access Control, have granularity on the HTTPS access based on users, apply SSL vulnerability rules on the SSL flows and more.

The device is smart enough to have the HTTPS portion of the traffic, which is encrypted, to not be analyzed and thus minimizing the CPU impact of this traffic.

[Ralphy006]

Thanks Claudiu.

Do you have this documented anywhere? "The device is smart enough to have the HTTPS portion of the traffic, which is encrypted, to not be analyzed and thus minimizing the CPU impact of this traffic."

[Claudiu Cismaru · Accepted solution]

It's Claudiu, not Claudia :)

http://www.cisco.com/c/en/us/td/docs/security/firepower/60/configuration/guide/fpmc-config-guide-v60/Application_Layer_Preprocessors.html#ID-2244-00000cfc

See

Stop inspecting encrypted traffic.

By default, the option is set to not inspect encrypted data.

[Ralphy006]

Thanks Claudiu.

So indeed have the SSL preprocessor enabled and the "Stop inspecting encrypted traffic"/"Server side data is trusted" checked within my network analysis policy.

However, I'm confused whether or not the non-encrypted portion will be inspected for intrusions and URL filtering. ie the stuff you mentioned:

Even with encrypted traffic, the base URL is extracted from the SSL flow so you'll be able to have URL based Access Control, have granularity on the HTTPS access based on users, apply SSL vulnerability rules on the SSL flows and more.

The device is smart enough to have the HTTPS portion of the traffic, which is encrypted, to not be analyzed and thus minimizing the CPU impact of this traffic.

Also, I'm guessing it's recommended to enable the "SSL Preprocessor Rules" GID 137?

Please confirm, thanks!

[Claudiu Cismaru]

Non-encrypted portion is not actually non-encrypted. If it's part of the SSL protocol, the SSL preprocessor will analyze it and URL filtering is performed based on the URL generated from the SNI from the Client Hello or CN of the Server Cert.

If you need those rules active, you can enable them as well. It solely depends on your use case.