Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Step-by-Step Configuration and Troubleshooting Best Practices for the NGFW, NGIPS and AMP Technologies A Visual Guide to the Cisco Firepower Threat Defense (FTD)
New Member

ASA Firepower ssl decryption

hi everyone

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

 

thanks

2 ACCEPTED SOLUTIONS

Accepted Solutions
Hall of Fame Super Silver

As of the current FirePOWER

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. 

Cisco Employee

6.0 FirePOWER code was

6.0 FirePOWER code was released and is already posted on CCW. Here are the release notes that indicate support for SSL decryption. 

http://www.cisco.com/c/en/us/td/docs/security/firepower/60/relnote/firepower-system-release-notes-version-600.html

Thank you for rating helpful posts!

Thank you for rating helpful posts!
35 REPLIES
Hall of Fame Super Silver

I believe if you want to

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

New Member

thanks Marvinif i use ASA CX

thanks Marvin

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

Hall of Fame Super Silver

That's true. The CX can do on

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.

New Member

Hi Marvin,Can you help me to

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.

Hall of Fame Super Silver

As of the current FirePOWER

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. 

Cisco Employee

Hi Dylan, at the moment,

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!

Thank you for rating helpful posts!
New Member

Like in case of CWSA,

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.

Hall of Fame Super Silver

It is the same model.The

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.

New Member

Agreed, but most

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?

Hall of Fame Super Silver

True most won't do it ONLY

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

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?

New Member

John, What about inspection

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

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

 

Hall of Fame Super Silver

John,While the Scansafe

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

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.

New Member

You are great help.Really I

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.
Hall of Fame Super Silver

Asad,For inspection of

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

New Member

Thanks Marvin,That's

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

Hall of Fame Super Silver

Asad,For the "appliance to

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.

New Member

Marvin, Thanks for giving

Marvin,

 

Thanks for giving much needed clarity on the subject. However, I'm stuck on something which I'm not able to locate in CWSA datasheets, this is in regard to how for e.g inbound ssl mode web-attack such sql injection will be handled / absorbed by the appliance , is there an ips engine running inside CWSA which does that?I'm mean where the signatures for such actions comes from. Thanks.

 

[UPDATE] For e.g in macage ngfw, for inbound ssl inspection, I have the ability through defining a "policy" which features set to apply from ips signatures, anti-malware etc. Does the same concept applies in case of cwsa?

Hall of Fame Super Silver

Asad,Sorry but I believe I

Asad,

Sorry but I believe I misspoke earlier in saying that we could inspect the content for incoming SSL with the WSA. That is a feature specific to the IPS appliances.

My apologies for that. I noted the error in my post.

New Member

Marvin,

Marvin, It's okay no problem at all.To err is human:). So, what any cisco ips would do inbound ssl inspection or esp class like firepower intrgerated module. Can you point to exact ips that enables this feature?
Hall of Fame Super Silver

I'm referring to the Cisco

I'm referring to the Cisco FIrePOWER Next Generation IPS (NGIPS) appliances specifically. That would include the 3D7000, 3D8000 and AMP series of hardware.

It would not be supported (currently - as of 5.4 software) on any of the ASA FirePOWER modules, including the hardware module on the 5585-X. It is also not supported on the virtual FirePOWER appliance.

I believe it is supported on the ASA CX IPS; although that is also end of sales.

It is not supported on any of the legacy Cisco IPS appliances.

New Member

You've mentioned the the

You've mentioned the the FirePOWER (software) may implement SSL inspection capabilities once version 6 is out. 

Is there a timeline for date of release of version 6? If I would be able to perform SSL decryption with an ASA 5506-X in the near future, I would consider purchasing it for my home lab rather than a Palo Alto PA-200.

Hall of Fame Super Silver

Cisco doesn't typically

Cisco doesn't typically announce release date until they are actually shipping the code.

The best projection they were sharing publicly at Cisco Live earlier this summer was "Fall 2015". They also caveat that you will take quite a performance hit by doing the SSL decryption in software, especially in the lower end boxes.

New Member

Thank you for the information

Thank you for the information.

My home lab is a way for me to practice enterprise architecture and security on a micro-scale. It won't be at my home internet perimeter, but will be used to segregate my home lab network from my home recreation network. There won't be too much lab traffic crossing the firewall unless I'm hairpinning, so I'm not too worried about the performance hit.

The PA-200's also take a significant performance hit when they enable inspection.

 

New Member

Marvin,

Marvin,


Have you heard any work yet for SSL decryption on the ASA's yet.  I still can't find anything on it.

Austin

Hall of Fame Super Silver

Austin,

Austin,

We still expect it in 6.0 on the ASA FirePOWER modules. It should be out in the next month or two. 

Cisco Employee

6.0 FirePOWER code was

6.0 FirePOWER code was released and is already posted on CCW. Here are the release notes that indicate support for SSL decryption. 

http://www.cisco.com/c/en/us/td/docs/security/firepower/60/relnote/firepower-system-release-notes-version-600.html

Thank you for rating helpful posts!

Thank you for rating helpful posts!
13278
Views
35
Helpful
35
Replies
CreatePlease to create content