ASA Firepower ssl decryption

[Vahid Tavajjohi]

hi everyone

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

thanks

[Marvin Rhoads]

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

[Vahid Tavajjohi]

thanks Marvin

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

[Marvin Rhoads]

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.

[dylan.webb]

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.

[Marvin Rhoads · Accepted solution]

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. 

[nspasov]

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!

[asad ali]

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.

[Marvin Rhoads]

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.

[asad ali]

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?

[Marvin Rhoads]

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.

[johnlloyd_13]

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?

[asad ali]

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.

[johnlloyd_13]

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

[Marvin Rhoads]

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