SSL decryption with ASA FirePOWER

[Dieselboy]

I checked with HR and we have a policy which an snip of this says:

[company name removed] will regularly monitor and may copy, access or disclose any information or files stored, processed or transmitted on its communication systems and devices, including internal or external communications (including emails), documents stored on the network, internet usage, duration and sites visited, automated scanning of an employee's files to identify viruses or other malicious codes and logging individual keystrokes.
This includes monitoring the [company name removed] systems and devices outside of regular business hours and personal communications where they were communicated through [company name removed] communication systems and devices. Therefore staff members who use [company name removed] communication systems and devices for personal purposes must not consider this information to be private as they will not have the same personal privacy rights as they would if they were using private communication systems or devices.

This should cover SSL inspection.

[Dieselboy]

PS.
I removed the only line in my SSL decryption rule today because I'm going to come back to this later. The line was a rule to this website. So this meant the policy was empty although it was still attached to the access-control-policy.
For some reason this caused the SFR module to drop a whole bunch of SSL traffic. Not good. Beat this in mind.

[SimonV]

I checked with HR and we have a policy which an snip of this says:

[company name removed] will regularly monitor and may copy, access or disclose any information or files stored, processed or transmitted on its communication systems and devices, including internal or external communications (including emails), documents stored on the network, internet usage, duration and sites visited, automated scanning of an employee's files to identify viruses or other malicious codes and logging individual keystrokes.
This includes monitoring the [company name removed] systems and devices outside of regular business hours and personal communications where they were communicated through [company name removed] communication systems and devices. Therefore staff members who use [company name removed] communication systems and devices for personal purposes must not consider this information to be private as they will not have the same personal privacy rights as they would if they were using private communication systems or devices.

This should cover SSL inspection.

It may be illegal in your country though, you should check with your legal department instead

https://www.sans.org/reading-room/whitepapers/legal/generation-firewalls-employee-privacy-global-enterprise-35467

[Otanx]

I can't find my customized write up at home. Here is the site I used when I did this. Besides changing the obvious stuff like company name I think the only change I made was the intermediate CA cert I created was 2048 not 4096. The system I was playing with only supported 2048 CA certs. I wold hope Cisco can do 4096. The write up is pretty good. Just follow the directions on creating the root pair, and intermediate pair. The root pair needs to go offline (USB stick), and the intermediate pair goes on the FirePOWER box. If you want to start issuing certificates for internal websites instead of doing self signed you can create a second intermediate pair, and use it for signing other stuff. The directions should work on a Mac. I don't have one here to test with, but I think they have openssl on them.

https://jamielinux.com/docs/openssl-certificate-authority/introduction.html

-Otanx

[Otanx]

That SANS link is a really good write up on the privacy issues. I just skimmed it, but going to read the entire thing later when I have some time.

-Otanx

[wintermute000]

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

I haven't read the RFC but my understanding is that certificate pinning will explicitly mandate the specific certs that is valid in the trust chain I.e. you replace with something signed by your CA it's invalid. Not sure exactly how but example is Discordx. Palo for example has a default bypass list where it don't even try decryption as it knows it will break, it caused a minor ruckus when made public as it was doing the bypass silently.
Looked it up and I don't agree with your take. Certificate pinning will mandate  the expected public key, if you change it then no dice. See here https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning

It explicitly calls out interception and that you have to import the interception proxy public key into the pinset otherwise the interception will break. There is no traditional trust chain anymore that's the point

It's also what our Palo, source fire and checkpoint consultants tell me LOL

Btw it calls out that RFC as contentious specifically for that feature you're talking about

[Otanx]

Technically you are correct that certificate pinning fails if the certificate chain presented does not match the pin. However, real life does not match theory.

When doing SSL intercept you have to be clear about three major use cases. The first one is web browsing from normal browsers. By default the major browsers will ignore pinning failures if the CA is a user imported CA. This setting can be changed, but this is the default. This means that as an enterprise I can intercept all my normal users web surfing from managed endpoints by importing a CA cert on the systems. I can now intercept and scan encrypted traffic for bad stuff in a central location. Trying to intercept non managed devices that I can't push a CA cert to is the problem, and usually not worth trying. Just dump BYOD/personal stuff on different network, and treat them as untrusted.

The second use case is non-browser applications that use SSL for transport. This is where the interception can break. It is up to the application developer how they want to handle certificate pinning. They can decide to reject all pin failures, or what I find more common is they don't use the system CA store, and don't supply any way to import your own CA cert into their store. This breaks the intercept. This is actually becoming less of an issue as everyone is doing everything "in the cloud" or "from your web browser" No more thick clients, and the intercept works because I am back to using the browser. If you look at the PA bypass list most of those entries fall into this category.

The third use case is appliances or server applications using SSL for call home, or license validation, etc. This is really a subset of the second use case, but I like to break it out separately because it is a different risk level. These are a crap shoot if you can import your own CA or not. I found most don't do certificate pinning at all (yet), but a lot do not have a way to import a different CA cert. The mitigating factor is most appliances or server applications only connect to a few different sites so I can bypass interception for that appliance to those few sites. This category is actually growing as developers are learning that designing their own protocols is a pain, and just use SSL.

In the end can you intercept traffic? Yes. Is interception going to be impossible any time soon? No. Is it worth doing? Maybe. Should you do it? Politics.

-Otanx

[LynK]

Be prepared to pull your hair out. When everything (and I mean everything) stops working. Windows updates, google drive, adobe, SMTP/ActiveSync/etc/etc/etc.

[wintermute000]

Thanks for the clarification on IRL vs theory, I'll go back and question our sec guys again on what they're seeing in the field

[Otanx]

No problem. I had to dig into this for a customer in the past. It isn't as hard as it sounds once you understand all the terminology, but it still isn't easy. I am also ignoring all the privacy and legal concerns that go with it.

-Otanx

[wintermute000]

From what I hear, pretty much what lynk says. For certificate pinned sites, browsing is fine, but server updates etc. all break, and not all those mechanisms have a method for importing your CA, so its basically a giant headache and you end up configuring SSL inspect bypass for 'problem' destinations.

Our resident Palo oracle basically told me point blank that he sees SSL inspection dead in 12 months, having said that he is notoriously pessemistic LOL

[deanwebb]

From what I hear, pretty much what lynk says. For certificate pinned sites, browsing is fine, but server updates etc. all break, and not all those mechanisms have a method for importing your CA, so its basically a giant headache and you end up configuring SSL inspect bypass for 'problem' destinations.

Our resident Palo oracle basically told me point blank that he sees SSL inspection dead in 12 months, having said that he is notoriously pessemistic LOL

I do hope it goes away. It's a damn stupid way to do a damn stupid thing.

If you want to read everyone's web traffic and email, do it at the endpoint. If the endpoint can't be viewed, block it. If the endpoint can't be blocked, you should have spent money on that NAC solution instead of the SSL decryption solution...

[Dieselboy]

Thanks everyone!

If you want to read everyone's web traffic and email, do it at the endpoint. If the endpoint can't be viewed, block it. If the endpoint can't be blocked, you should have spent money on that NAC solution instead of the SSL decryption solution...

^ This

I see that you're saying SSL inspection will break certain things. So with that, why not just exclude those certain things from inspection? At least then you'll be inspecting most things as a best effort. You could create a pass-through rule based on URLs or destination networks. Then, what's is not specified as excluded / passed-through, will hit the inspection rule for SSL. A bit more management but...

[deanwebb]

Anything excluded becomes an attack vector.

"The hackers utilized a flaw in the Windows Update service..." Want that as a headline?

[Otanx]

Nothing is perfect. To quote Shrek "Security is like an onion, it has layers". The problem for any of these solutions (endpoint or central inspection) are appliances/software where you can't install extra software, and that don't allow adding CAs to trust lists. Any system like that means exception to the inspection policy. Now you have an encrypted link you can't see. An attacker can use that either as an ingress if there is a vulnerability, or as a exfil channel to get data out bypassing DLP. It is a risk acceptance decision in the end. You can just exempt that endpoint from inspection all together, that is an easy low work solution. You can exempt it from inspection for specific destinations. This is more work, but more secure. You could make the decision not to deploy the device at all, and accept the loss of that capability.

I think inspection of encrypted traffic however you do it is important for enterprise networks. Too many attacks now are using encrypted channels to bypass inspection. So either watching it at the end point, or with an intercept you should be watching. While writing this I thought it would be interesting to see malware that exfils data by posting to facebook (I think there is one that uses twitter).

My opinion differs from wintermute's PA guy. I think interception will grow, and become easier in the coming years. We will see. However, I think it is going to differ heavily between different markets. Financial, Medical, and Government will see big increases where employee privacy is secondary to preventing exfil of data. Other markets may not be as interested in deploying it to not deal with privacy issues.

-Otanx