SSL decryption with ASA FirePOWER

[Dieselboy]

I have rebuilt my FMC and ASA Firepower and I'm looking into SSL decryption. I need to do the following:

   
• make an internal CA to generate a cert used for presenting to the client
• make a self-signed certificate that will protect the proxied content
• distribute and install the cert-chain for the CA on the client systems (or be happy with 'this website is not secure, do you want to proceed' error messages)

Has anyone made a CA that can issue a suitable cert? It looks like I need to issue a cert for "*.com" etc... is this possible or am I missing something here?

[deanwebb]

Windows Active Directory is your best friend here for internal clients.

If this is to be a solution for external users' devices, though, you'll need a commercial certificate and then be sure that a connectivity path exists to the commercial CA.

[Dieselboy]

This question specifically is for inside -> out requests. eg a user accessing youtube (example).
Do you know what the cert should look like? I'm not sure how it's supposed to look. Will one cert do the job?

[Dieselboy]

I've done some more digging and found this: http://docs.fortinet.com/uploaded/files/2041/using-a-custom-certificate-for-SSL-inspection.pdf

So does the SSL inspection module (in my case, FirePOWER) generate a new cert on the fly for each connection? And uses the signing CA cert that I'll generate from Windows CA. I feel like I'm missing how this is going to work, hence confusion on my part.

[deanwebb]

The user thinks he's connecting to an HTTPS website, but he's actually connecting to the proxy via an internal SSL cert. The proxy then looks at all the traffic and gets it into an SSL session with the outside site. As traffic returns, the proxy decrypts it locally for inspection before encrypting it with the internal cert to ship back to the user.

Think of it as a big spy network in the post office, opening every letter, inspecting the contents, and then putting those contents into a new envelope to send on its way. There is no direct connection to the ultimate endpoint, so all SSL encryption is handled between an endpoint and the proxy.

[Otanx]

So the normal way this all works for inside to outside traffic is as follows.

1. You generate a intermediate CA cert from your internal CA (or create a separate CA cert)
2. Install the public cert for the CA created in step one on all the systems you want to intercept. If you don't own the endpoint good luck.
3. Install the private CA key, and public cert on the device doing the SSL intercept. Configure correctly based on the device.

Now when your client tries to connect to say https://www.networking-forums.com the SSL intercept device will intercept the handshake, and identify the hostname. It will setup a new connection with https://www.networking-forums.com, and then on the fly generate a new key/cert signed by the installed CA for that site. This certificate should match any issues with the real certificate (i.e. expired, wrong hostname, untrusted CA, etc). It then presents this certificate to the end device. You have now successfully intercepted an SSL session wthout throwing any warnings.

Some things to keep in mind.
You have to install your CA cert on the end point to get rid of the cert errors. Typically in an enterprise environment you push it out with a GPO. If trying to do this with BYOD, or customer devices good luck. It is more of a pain than it is worth. Your CA will not be trusted, and everyone will get certificate warnings for every site they go to.

Another item is to verify that your device is matching issues with the real certificate. If you go to a website with an expired SSL cert then the certificate generated on the fly should also be expired. Some SSL intercept solutions always present valid certs to the end device, and ignores errors from the real server. This hides real issues with certs, and actually causes more risk.

That CA key on your intercept device is now the most important file on your network. With it I can spoof anyone I want to your systems.

Some applications/appliances will not work with intercept. Some systems have hard coded CA certs that can not be updated. You will need to configure bypasses for these. I suggest you limit where bypassed systems can go on the internet as you will not see that traffic. These systems typically are just doing call homes for licensing, and have very few destinations. If you allow it to the entire internet you now have a encrypted path for someone to exfil data.

Legal/Politics is important. Users don't like their data being intercepted. Make sure you are clear that you are doing it. Don't try to hide it. Someone will notice. Also there are privacy laws that you may not want to intercept health care sites, banking sites, etc. This can get messy quickly. Make sure you are covered. The last thing you want is all your users having their bank accounts owned, and tracing it back to your intercept box being the source of the leak.

-Otanx

[deanwebb]

Regarding phone homes... Google, Apple, and Microsoft traffic needs to be allowed undisturbed or their devices will freak out and disconnect from the network.

[wintermute000]

Also Google certificate pinning. It's killing the SSL decryption market

[Dieselboy]

I understand how this works in terms of traffic flow. I'm just not understanding the certificates aspect.

For the sites that can't be inspected, I'm going to have the fall back action to simply allow the traffic not decrypted. With this, the SSL connection is established between the client and real server.

At the moment all I have is plain http inspection for malware. It's a bit crappy since SSL certs are free and so easy for anyone to set up sending malware via HTTPS. Plus most sites are HTTPS these days. I want to do this on a best effort.

Next problem is most of our user devices are apple Mac's. Good luck pushing certs via gpo 😊

[Dieselboy]

Regarding phone homes... Google, Apple, and Microsoft traffic needs to be allowed undisturbed or their devices will freak out and disconnect from the network.

Thanks for this how can I tell if a cert is pinned? I'm expecting the fallback "allow connection not decrypted" to take care of this but I want to confirm.

[Dieselboy]

  The last thing you want is all your users having their bank accounts owned, and tracing it back to your intercept box being the source of the leak.

Scary one.

[deanwebb]

  The last thing you want is all your users having their bank accounts owned, and tracing it back to your intercept box being the source of the leak.

Scary one.

Yep. This is why I don't like SSL interception. Yes, I know that bad guys use encryption to do bad things. But good guys use it, as well, and there's an expectation of privacy that's worth respecting. Block access to Tor nodes, implement DNS security, don't have a default route that points to the Internet gateway, you should be OK. For DLP, don't allow encryption software on company PCs and shut down external hard drives, including printers that have hard drive functions. Shut 'em all off.

[Dieselboy]

I have antimalware (amp) on desktops. I could say that HTTPS will be protected by the endpoints, negating the need for sale decryption for end users.
Unfortunately I need a default route for cloud services​, main one being Cisco spark.
I'm still thinking of setting up SSL inspection for non-desktops.
Plus I want to do outbound ssl inspection but that's a whole lot easier since I already make the server certs.

Reminds me of that saying but with a twist
pick 2 only:
Security
Convenience
User acceptance

[Otanx]

I will see if I can dig up my how to generate a CA certificate stuff. I stole it from a web site somewhere. Basically you just use openssl to generate a key, and a csr. Then sign the csr with the same key. This is now a self signed CA. Import the key and cert into the intercept box, and the cert onto the clients.

What Mr. Webb means by no default route is that you configure all your clients to use the proxy, and then they don't need to get to the internet as all they will go to is the proxy. The proxy needs a default out, but it should be sitting in your DMZ, and can have a default. I am not a fan of the no default route stuff, and just block at the firewall. There are too many different stupid apps/devices that can't have proxies configured.

Certificate pinning it does not work as most people think. If you import your CA into the browser then pinning will accept that CA as OK. The pinning RFC says this is acceptable (RFC 7469 section 2.6). See the FAQ below from Chromium for how they handle user defined CAs. I don't have Chrome, but I can confirm that both Apple and Google allow imported CAs to do intercept just fine as of five minutes ago in Firefox with a green lock. Pinning is not a protection against corporate SSL intercept. It is a protection against a "real" CA issuing bogus certificates which has happened a few times.

http://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters-

-Otanx

[Dieselboy]

I will see if I can dig up my how to generate a CA certificate stuff. I stole it from a web site somewhere. Basically you just use openssl to generate a key, and a csr. Then sign the csr with the same key. This is now a self signed CA. Import the key and cert into the intercept box, and the cert onto the clients.

Thanks mate this would be a big help and would be exactly what I'm looking for!

What Mr. Webb means by no default route is that you configure all your clients to use the proxy, and then they don't need to get to the internet as all they will go to is the proxy. The proxy needs a default out, but it should be sitting in your DMZ, and can have a default. I am not a fan of the no default route stuff, and just block at the firewall. There are too many different stupid apps/devices that can't have proxies configured.

Yes I get that and thats the reason why I can't do this, too. Spark is just one of the apps and it's not proxy aware (yet).

Regarding the proxy, I tried to find info on this but as far as I can tell, I can't use the firepower module or FMC as a proxy itself. The FirePOWER module just has traffic passed through it ie a transparent proxy. I can set up a traditional web forward proxy, though. Its traffic will then be inspected by the FirePOWER module upstream. Is this what you mean? I've had this task on my list anyway and then this came up when I was trying to decide how to proceed from here.

Thanks for the info on cert pinning