With the prevalence of Next-Gen Firewalls, were seeing a new wave of organizations decrypting traffic at the network edge, between organizations and the public internet.
This is a good thing. As we see more and more legit https traffic, were also seeing the attackers follow that trend, where malware and attacks are now often encrypted using standards based protocols as well.
How does this look in practice? width:1025px” />
But as we do the decrypt / inspect / encrypt thing, were also being forced to deal with applications that do things in unexpected ways – stuff like …
What NOT to Decrypt
There is *always* a list of applications that your dont want to decrypt. For privacy reasons, you almost never decrypt healthcare sites and banking/financial sites. Not only is the case that we dont want that information in a log someplace, its likely either illegal or breaks compliance if we decrypt and inspect tha ttraffic. Depending on your jurisdiction and industry, that list may of course vary.
Apps that run a Private CA and/or do Certificate Pinning
Ive seen some banking terminals (both ATMs and POS platforms) do certificate pinning, which is exactly as you would hope should be going on. Of course theyll run their own CA, and reject any traffic that is encrypted using a certificate that isnt their own. And of course, we simply put that banking terminal (ATM or payment card processor) into an exemption list – we dont *want* to decrypt that traffic – if we could decrypt that traffic successfully and still have it operate, wed report that as an issue to the payment processor. Where possible though, its also a good practice to isolate these units, and only allow them to communicate to their payment card mothership. You definitely dont want to be the source of an ATM breach, and if they get compromised from some other source, you dont want their attacker to see your network either.
Surprisingly though, Im seeing the same sort of behaviour in Courier apps. You know, that desktop app that shipping receiving (or the office manager, or whoever does shipping in your organisation) runs? Again, because the private CA is pinned, the only way to deal with it is to exempt the traffic between that workstation and the DN (Directory Name) of the target (*.purolator.com in this case). Good on them for going the extra mile, but it sure was a surprise to find it in the logs! We still get to decrypt everything else to and from those machines – theyre not isolated, but exempting traffic for that one application is straightforward.
Apps that Break the Rules
A more troubling situation is that we do see some applications that break or bend the rules for good encryption. For instance, apps that accept expired certificates from their server.
Logmein (the support/remote control application) for instance is currently in that situation. Their web services back-end currently uses an expired certificate. Worse yet, their upstream has no fixed IP address (its in a CDN), and the traffic is over tcp/443. Without putting some work into the rules, the decryption engine will simply drop the traffic because the cert is expired. So what this means for perimeter rules is that we need to match on the target DN (theres a list), and for those DNs we have to allow expired certificates. And right below that rule, we need a second rule that has the same DNs but doesnt allow expired certificates (for when they fix this situation).
We see similar things for applications that use APIs inside of SSL or TLS – if theyre using weaker ciphers, older protocols or pin certificates, to allow that app to work we need to set the allowed DNs and permit whatever bad habit that app has.
Other Bad Habits:
We also see lots of file downloads happen for one application or another. So if your organization blocks downloading JAR files for instance, any Java based app that pulls a JAR will trigger and block, breaking the application. Its very common for instance to see all-in-one helpdesk applications download a package of EXEs, JARs and MSIs when a new station is enrolled. As a side note, its also common to see these apps pull down older versions of Java, Acrobat Reader and other apps – what could possibly go wrong with that?
Logging is your friend for all of these something is broken situations – for any application that doesnt work, have a test user break it on film and note the time. Once youve got it logged, youll have the info you need to allow that application (and only that application) to do whatever dumb thing (or smart thing) that it needs to do to run, without allowing that behaviour on other applications.
For the helpdesk app example – in some cases we luck out and can set up a local repository, in other cases that cloudy nature of the app cant be worked around, and we need to permit exemptions.
Final advice? Once you have a smarter perimeter appliance like this in play, be prepared for your users to request that you whitelist a never-ending list of websites and applications. Before you do that, make sure that theyre actually blocked for one behaviour or another – in most cases they work just fine. Im still working out why human nature pushes folks to want a mile-long whitelist rule – one that has a pass everything, trust it all permission. So far, for most of those I leave all the decryption, traffic inspection, IPS and file inspection/sandboxing in play – the list of sites where you *dont* want that going on is pretty short.
If youve gone down the decrypt/inspect/re-encrypt road at your network edge, what problems have your found? How did you work around it? Please, use our comment form and let us (and everyone else) know!
===============
Rob VandenBrink
Compugen
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.