topic Marvin, in Network Security

ASA Firepower ssl decryption

Vahid Tavajjohi — Tue, 12 Mar 2019 04:52:16 GMT

hi everyone

is Firepower support ssl decryption or should have sourcefire beside ASA?

thanks

I believe if you want to

Marvin Rhoads — Tue, 07 Oct 2014 11:42:08 GMT

I believe if you want to inspect SSL (https) traffic, you will still need to use an SSL decryption appliance.

thanks Marvinif i use ASA CX

Vahid Tavajjohi — Tue, 07 Oct 2014 12:18:38 GMT

thanks Marvin

if i use ASA CX with ssd Drives, then i dont need to ssl decryption appliance?

That's true. The CX can do on

Marvin Rhoads — Tue, 07 Oct 2014 23:49:36 GMT

That's true. The CX can do on-board decryption (albeit at a lower throughput rate than the SSL decryption appliance).

Also, the WSE and AVC inspection services are not quite as mature and doing a thorough a job as the FirePOWER products.

Hi Marvin,Can you help me to

dylan.webb — Wed, 07 Jan 2015 22:58:59 GMT

Hi Marvin,

Can you help me to understand the Cisco offering which provides Firepower services (threat prevention) and the ability to inspect encrypted data streams. Ideally on a single platform.

Thank you.

As of the current FirePOWER

Marvin Rhoads — Thu, 08 Jan 2015 00:28:53 GMT

As of the current FirePOWER software (Release 5.3.1), onboard SSL decryption for inspection of traffic is not supported. I've heard it may be coming in 5.4 (possibly later this quarter) but that's not yet available. When is is available, it will have a performance cost since line rate SSL decryption is computationally intensive.

So for now you would have to use a Cisco SSL appliance. They have purpose-built hardware for SSL decryption.

In either case, the inline device that's opening and inspecting the SSL traffic would need to have a special certificate that's allowed to issue child certificates and be trusted by all your clients. That typically means you need to have (or establish) an Enterprise PKI.

Hi Dylan, at the moment,

nspasov — Thu, 08 Jan 2015 00:39:00 GMT

Hi Dylan, at the moment, there isn't a Cisco with FirePOWER offering that provides ssl decryption on the same box. That is true weather you get the FirePOWER for ASA or the standalone FirePOWER appliances. Both solutions would require a separate, dedicated SSL decryption appliance:

http://www.sourcefire.com/products/next-generation-network-security

I believe this will change in future releases of the Sourcefire but for now you will need a dedicated SSL appliance.

Thank you for rating helpful posts!

Like in case of CWSA,

asad ali — Sat, 01 Aug 2015 13:47:35 GMT

Like in case of CWSA, customer can upload their own certificate and private key or have the appliance generate itself or there is an option of CSR which can be signed by a root CA. Why not follow same model as CWSA? Thanks.

It is the same model.The

Marvin Rhoads — Sat, 01 Aug 2015 14:25:17 GMT

It is the same model.

The enterprise PKI I mentioned is what the Root CA is part of. Public Root CAs will not issue certificates that can be used like a "man in the middle" which is how the WSA and FirePOWER appliance both are able to proxy your SSL sessions.

Most organizations who go to the trouble to deploy this do it with a full-fledged PKI rather than using the self-signed certificate the device is capable of generating as the enterprise approach provides tools to manage a certificate-based infrastructure.

Update on my earlier post - 5.4 did introduce SSL decryption but only for the FirePOWER hardware appliance. The ASA FirePOWER (software) modules should be getting it in Version 6.0.

Agreed, but most

asad ali — Sat, 01 Aug 2015 14:36:34 GMT

Agreed, but most organizations are not wiling to pursuit PKI just for focus of ssl termination and inspection alone. The big motivators is UAM/IM technologies or setup.

You mentioned , root CA'S will not issues certificate to be used in MITM manner but what about option of CSR, can that be signed by CA external to organization and used there-after?

True most won't do it ONLY

Marvin Rhoads — Sat, 01 Aug 2015 15:14:37 GMT

True most won't do it ONLY for SSL inspection. But the ones who care enough about security to want to decrypt the SSL leaving the enterprise usually have other security initiatives such as the ones you mention so it's all related to the need for a PKI.

Re CSRs, when a public CA issues a certificate, there are various purposes that are assigned in the body of the certificate. Most commonly the purpose is "server". Less common options are "client", "S/MIME signing" etc.

To represent itself as the end host you are trying to get to for SSL/TLS purposes, the certificate purpose must include the ability to do so. One issued by a public CA in response to your CSR will not have that ability.

hi marvin,i'm currently

johnlloyd_13 — Sat, 01 Aug 2015 15:27:49 GMT

hi marvin,

i'm currently evaluating CWS using an ASA connector. does this mean i can't block HTTPS website on a granular or application level basis? i was only able to block facebook on a domain name level (blacklist) only. i wasn't able to block facebook messenger and games.

the cisco security engineer told me to generate the CWS self-signed cert or do CSR with a third party CA in order to do HTTPS decryption and their proxy/scansafe server can do MITM proxy.

i'll be doing firewpower soon. is the same logic applied?

John, What about inspection

asad ali — Sat, 01 Aug 2015 15:42:22 GMT

John,

What about inspection is the connector outside the CWS or in one box? Who is responsible for layer 7 inspection, also can the same setup be used as incoming ssl decryption instead of outbound? thanks.

hi,i just set this up this

johnlloyd_13 — Sat, 01 Aug 2015 15:55:06 GMT

hi,

i just set this up this week running on CWS eval license, so apologies as this is quite new to me.

what i did was, i've applied the service policy map (HTTP and HTTPS) on the 'inside' interface. below is a snippet of what i did. the ASA isn't on production yet and i have only 1 PC behind the inside interface.

what i want is to have granular control especially on SSL/TLS traffic and since most websites are running on HTTPS.

going back to my original question, do i need CA cert or PKI in this case?

# sh run scansafe
!
scansafe general-options
server primary fqdn proxy2332.scansafe.net port 8080
server backup fqdn access615.cws.sco.cisco.com port 8080
retry-count 5
license UqSGYa8xyWWqJ5x1 encrypted

# sh service-policy inspect scansafe

Global policy:
Service-policy: global_policy
Class-map: inspection_default

Interface inside:
Service-policy: PMAP-WEBTRAFFIC
    Class-map: CMAP-HTTP
      Inspect: scansafe HTTP-PMAP fail-open, packet 38799, lock fail 0, drop 0, reset-drop 0, v6-fail-close 0
Number of whitelisted connections: 0
Number of connections allowed without scansafe inspection because of "fail-open" config: 0
Number of connections dropped because of "fail-close" config: 0
Number of HTTP connections inspected: 626
Number of HTTPS connections inspected: 0
Number of HTTP connections dropped because of errors: 0
Number of HTTPS connections dropped because of errors: 0
    Class-map: CMAP-HTTPS
      Inspect: scansafe HTTPS-PMAP fail-open, packet 86686, lock fail 0, drop 80, reset-drop 240, v6-fail-close 0
Number of whitelisted connections: 0
Number of connections allowed without scansafe inspection because of "fail-open" config: 0
Number of connections dropped because of "fail-close" config: 0
Number of HTTP connections inspected: 0
Number of HTTPS connections inspected: 1658
Number of HTTP connections dropped because of errors: 0
Number of HTTPS connections dropped because of errors: 0

You are great help.Really I

asad ali — Sat, 01 Aug 2015 17:02:27 GMT

You are great help.Really I wish there were more cooperating tech profoessionals like you.:) On cisco docs it said WAS wouldn't not support "server cert" on appliance, only "root" it makes sense if setup is for outgoing connections for which there are far many ssl connection points, in my case I have only web server / application and concern is from clients coming externally should the server certificate option be more viable.

John,While the Scansafe

Marvin Rhoads — Sat, 01 Aug 2015 17:31:57 GMT

John,

While the Scansafe product is a bit outside my primary area of expertise, it works similarly. The difference in this case is that the certificate(s) the clients need to trust resides in Cisco's Scansafe "towers" (their cloud-based scanning complexes).

I found this older (but I believe still accurate) quote on a Cisco document from 2010:

"Where enabled, HTTPS Inspection allows the administrator to set a policy determining which domains and categories of HTTPS traffic are decrypted and inspected on the scanning infrastructure. Data is encrypted from the Web server to the scanning tower in the normal way; however, for sites which the customer wishes to be inspected, the scanning tower will terminate the SSL-based connection, inspect the data in the same way as for HTTP traffic, and then re-encrypt the traffic from the scanning towers to the end user using a different certificate. The corresponding certificate authority will need to be rolled out to the Customer’s Web browsers as a trusted certificate authority to prevent domain mismatch warnings appearing to end users. HTTPS Inspection can be used for both malware detection and enhanced Web filtering actions such as Outbound Content Control. "

hi marvin,thanks for this

johnlloyd_13 — Sun, 02 Aug 2015 00:04:00 GMT

hi marvin,

thanks for this info! +5

i guess the cisco engineer i worked with was right.

anyways, it's just a POC and i'm just getting output data to present to management.

i'll do firepower probably next month. i hope you guys would be around if i post any questions.

Asad,For inspection of

Marvin Rhoads — Sun, 02 Aug 2015 09:42:27 GMT

Asad,

For inspection of incoming https traffic, it's a different story. Assuming you own the server and its certificate, you can put a copy on your inspection engine (~~WSA or~~ FirePOWER appliance).

In that use case, it has the legitimate certificate of the target server and can, for the purposes of terminating SSL session to inspect the content, act as if it is the server itself.

This is not unlike what we do with Application Delivery controllers (aka load balancers such as Citrix Netscaler or F5 BigIP) when they front for an SSL server farm. In those cases we often pass the traffic to the real servers unencrypted (this is desirable as the modern ADCs have purpose-built hardware and optimized software for SSL offload thus allowing the backend servers to devote more resources to application server tasks vs. encryption/decryption); but they all have the option of re-encrypting as well.

(EDIT - note this feature is for IPS only, e.g. FirePOWER appliances.)

Thanks Marvin,That's

asad ali — Sun, 02 Aug 2015 09:42:28 GMT

Thanks Marvin,

That's interesting you mentioned the big-names in load-balancing tech e.g F5 and others, I researched F5 for a few hours and the term they used to describe the concept of "decrypt-inspect-re-encrypt" as ssl-bridging. Now, what I know it requires two profile at least client and server side to ensure complete end-to-end encryption.

In your last post, you mentioned for incoming ssl inspection a copy of server certificate and key would be fine, but it was my mistake I forgot to ask what about the need to re-encrypt once it is done with inspection like does the concept of ssl-briding holds true on WCSA and firepower as well. I remember you said in another post that "YES it does that", but then it makes me confused about use of certificates, for CWSA to act as ssl client to target server it needs a certificate / key as well. Where would that comes from? The certificate from server /key we copied on appliance would do fine to act as "client profile" allowing to act like a server but what about the other half of journey (appliance to target server)

Sorry for confusion

Asad,For the "appliance to

Marvin Rhoads — Sun, 02 Aug 2015 13:22:52 GMT

Asad,

For the "appliance to target server" use case, you don't need a certificate-key pair on the appliance for that backend communications link. The target server(s) have the necessary pair. Remember for that link, the appliance is the client and no more needs its own certificate than you do when you browse to any "https" URL via SSL/TLS.

Netscaler (which I'm most familiar with) calls this "SSL Offloading with End-to-End Encryption". SSL bridging is something else - not decrypting the SSL at all. As described here, it doesn't require a certificate on the appliance at all.