Cisco ASA SourceFire SSL Inspection

[jfigueroa8]

Hello

How can the Sourcefire inspect the SSL traffic?

Stay pending for an answer, thanks a lot.

[Marvin Rhoads]

It can only inspect SSL traffic if it is externally decrypted by an appliance.

On the roadmap for 5.4 FirePOWER dedicated hardware appliance is on-box SSL decryption. The ASA-based FirePOWER modules will get that capability a bit later.

[kaustubhmhatre]

Thanks Marvin. Would this require purchase of any additional license? I'm trying to find documentation related to SSL decryption in FireSIGHTv5.4, but am not able to currently. Any pointers? Thanks!

[Marvin Rhoads]

You're welcome.

No additional license is required. This functionality is included in the basic license (Protect + Control) for platforms running the necessary software versions. Depending on how much traffic you're decrypting you will pay in throughput as the decryption is computationally intensive at scale. 

I can confirm it's there and usable (though I haven't set up PKI Objects or a policy) on my Sourcefire 3D7125 running 5.4.

Re documentation, it's covered in the 5.4.1 User Guide - see the section on PKI Objects and the section on SSL Policies.

[kaustubhmhatre]

Wow, that was even quicker than support could get back to me on this. Thanks for all that information, it helps!

[Marvin Rhoads]

You're welcome.

Please rate useful replies. :)

[Ralphy006]

With 5.4, does outbound SSL decryption act as a proxy?

Similar to: https://live.paloaltonetworks.com/docs/DOC-1412

[adhogan]

I guess you could call it a transparent proxy. 

Outbound SSL is decrypted by interception and then resigning the traffic.

[Ralphy006]

Thanks. Do you have any documentation that explains this? It seems like all the SSL decryption I read about, requires the decryption to device to generate it's own certificate to present to the user

For example, for Palo Alto's:

Outbound SSL decryption (called “SSL forward proxy”)

In this case, the firewall proxies outbound SSL connections. It intercepts the outbound SSL requests and generates a certificate on the fly, for the site the user wishes to visit. The validity date on the PA-generated certificate is taken from the validity date on the real server certificate.

The issuing authority of the PA-generated certificate is the Palo Alto Networks device. If the firewall’s certificate is not part of an existing hierarchy, or is not added to a client’s browser cache, then the client will receive a warning message when browsing to a secure site. If the real server certificate has been issued by an authority not trusted by the Palo Alto Networks firewall, then the decryption certificate will be issued using a second “untrusted” CA key. This is to insure that the user will be warned if there are subsequent man-in-the-middle attacks occurring.

[adhogan]

Just the User Guide. 

You can generate your own cert to use for certificate resign. But you can just as easily import your own. Or sign the one generated with your own. That way the traffic will still be trusted. 

[Ralphy006]

Thanks Marvin and adhogan!

Very good explanations.

For outbound SSL traffic, is the "man-in-the-middle" approach the only option we have to decrypt the SSL traffic?

[adhogan]

Technically, yes. You can use the private key or you can man-in-the-middle it.

But the question should be what do you want to accomplish? Why do you need to see into SSL? There may be another solution to your real problem. 

For example, if your issue is wanting to block certain applications then we may be able to do that based on URL or SSL Cert names. If your main concern is stopping malware then the answer is to get AMP on the endpoint so the malware is visible regardless of what encryption scheme is used. 

[Marvin Rhoads]

....what Adam said. :)

[Ralphy006]

Thanks for the response guys.

Our main concern is just URL filtering. I was under the impression, that the IPS URL filtering could NOT see the URL name/string for SSL/HTTPS traffic since it's encrypted.

Can the URL filtering see the URL name/string or HTTPS without using the private key or man-in-the-middle?

For example, we would like to block https://youtube.com. We could block the https access to the public IP associated to the fqdn, but that would block https://google.com since they sometimes share the same IP. Based on previous websense deployments, the websense box could only see the destination IP of the HTTPS traffic I believe ( I could be wrong ), but it couldn't see the URL. I'm guessing they can make an educated guess based on the public IP, but that won't be 100% accurate

[Marvin Rhoads]

Vincent,

adhogan mentioned the User Guide. Specifically look at "Working with PKI Objects" and the "Getting Started with SSL Policies" sections of the 5.4.1 User Guide.

Those explain that you use either an internal self-signed certificate or one from an external CA. In either case, it needs to be trusted by the end users' browsers if it's going to be a man-in-the-middle inspecting outbound traffic.

When used in that use case, we would generally prefer to have an Enterprise PKI since in most cases we can more easily have that automatically trusted by end users (assuming they are in an AD domain where we can push out a GPO to that effect).

If you're only inspecting incoming traffic (say to your secure server), you can put a copy of the server certificate(s) with associated private key(s) on the appliance and create policy so that it presents the legitimate server certificate to the incoming traffic.