topic Send HTTPS/SSL traffic to Firesight IPS sensors with no decryption? in Network Security

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

Ralphy006 — Tue, 12 Mar 2019 13:15:48 GMT

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?

The common procedure is to

Rahul Govindan — Tue, 24 Jan 2017 21:06:48 GMT

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.

Ralphy, you're correct.

Claudiu Cismaru — Wed, 25 Jan 2017 14:00:08 GMT

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.

Thanks Claudia.

Ralphy006 — Tue, 31 Jan 2017 08:42:36 GMT

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."

It's Claudiu, not Claudia :)

Claudiu Cismaru — Tue, 31 Jan 2017 08:42:37 GMT

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.

Thanks Claudiu.

Ralphy006 — Tue, 31 Jan 2017 18:49:13 GMT

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!

Non-encrypted portion is not

Claudiu Cismaru — Wed, 01 Feb 2017 14:30:03 GMT

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.