5

There are many questions on this site from users finding out that their employer has a certificate proxy in place, essentially implementing a man-in-the-middle attack so that all traffic is able to be decrypted.

I've been told from our security professional who put it in place that this policy is considered best practice. Apparently it helps anti-virus software (in particular, McAfee) do its job. I presume this does not mean that it aids in preventing infection, but that it provides a way to discover where the infection came from.

I've had other people tell me that the only reason companies ever do this is so they can keep tabs on their employees maliciously. In this thinking, any other reasoning given for this policy is not to be believed.

Who is right? Is this policy actually considered best practice? What benefit does a certificate proxy provide?

WhiteWinterWolf
  • 19,082
  • 4
  • 58
  • 104
Nacht
  • 925
  • 1
  • 6
  • 12

3 Answers3

4

No, it's not "best practice". Implementing SSL interception is a trade off, every companies that are considering it have to weigh the downsides of SSL interception heavily.

On one side, implementing SSL interception centralises management of security. It allows the company to scan for malware, and to detect and block (accidental) data exfiltration/leaks, it also allows the company to enforce policies like prohibiting access to NSFW sites.

On the other side, it also makes the job of the attacker much easier as they now have a single high value machine that can compromise the security of the entire company. Compromising this single machine would allow the attacker to intercept every passwords, spoof pages, and distribute malware at unprecedented level.

Additionally, many SSL interception products actually have poorer security than up-to-date browsers, for example, not checking certificate chain correctly, not checking OCSP/CRL, or their root certificate store may not be updated as frequently as browser root store. Most of the interception products in the market is a net negative to security when they aren't implemented properly. Getting net positive from the better interception products are not easy, you cannot just install and forget, they need continuous maintenance, if they have data exfiltration detection, their signature database need to be kept up to date as the business evolves. Implenting interception properly requires a significant investment for somewhat modest benefits.

Common but poor reasons for implementing SSL interception is that SSL interception couldn't really detect or block deliberate data exfiltration. If you don't trust your employees, you have social problem, not technical, and you can't fix social problem with technical solutions.

Another common and poor reason is that it allows the administrators to not have to setup antivirus on individual workstations. Many viruses cannot be detected with static analysis, administrators that uses central antivirus to replace, rather than in addition, to per-workstation antivirus should have their administrator privilege revoked.

Having implemented SSL interception also should never be used as an excuse to keep outdated software that cannot support modern TLS (e.g. IE6 on WinXP).

There are cases where implementing interception makes sense, but most vendors if these products overstates what their product can actually do, and significantly downplays the costs and downsides. Most offices wouldn't really benefit from SSL interception, and usually increase their risks by implementing it.

Lie Ryan
  • 31,089
  • 6
  • 68
  • 93
  • 4
    Add to the drawback list the 'best practice' recommend to use a certificate not signed by a well know CA (so you can say it is not an hidden interception) and you have the drawback of every tool using its own cert store breaking (firefox, ruby, python, java), and finding the store in which to add the company internal CA cert is not always easy. – Tensibai Jul 21 '17 at 08:21
4

According to Mozilla Telemetry half of the top results in the Google search used https in 04/2017 and they projected a further growth to 65% at the end of the year. And while it was once kind of used as an indicator of trust into the content of the site itself, https is now ubiquitous enough to protect traffic to sites delivering malware or phishing, either because they were setup this way or because a formerly harmless site was hacked.

This means content delivered through https cannot be trusted just because of the https but needs to be inspected like any other potentially malicious content. Such inspection can be done either at the endpoint of the encryption or in between. In the latter case one uses for example enterprise firewalls offering SSL interception but also many desktop AV have local proxies doing SSL interception. The other option would be to analyse the content only after decryption, for example using extensions inside the browser which have access to any decrypted content or analyzing any file access. These different methods of content inspection don't have the same capabilities because they work on different data, have different communication context and are applied in environments which are differently trusted, i.e. the different methods have different advantages and disadvantages.

Doing SSL interception in the perimeter firewall gives visibility into both incoming and outgoing data at the network level. This provides a broader picture of the network where data to different systems can be analyzed together. It helps also to detect or restrict botnet communication. And, while basic blocking of whole web sites can often be achieved without SSL interception more granular control, like blocking only posts to Facebook, can only achieved by having access to the content. The biggest problem with SSL interception is that it destroys the expected end-to-end encryption of the traffic and can actually weaken the security if not properly implemented. And unfortunately, often it is badly implemented.

Analyzing the decrypted content in the browser instead is not really less invasive than doing SSL interception and adds some additional problems. To be effective in detecting and blocking malicious content the browser plugin needs to have access to any content in the browser before it gets executed by the browser. But, this is code running on a system which should be treated as less trustable as the firewall since attacks against clients with their huge attack surface are much more common and successful than against a firewall. Thus one has to consider the case that an attacker find a security problem in the plugin and can either disable it or worse hijack it to control everything in the browser.

Detecting potentially malicious content with file system monitoring, system call monitoring or similar provides some advantages because it monitors the malware in real action instead of only doing static analysis or running short test inside a sandbox. But it also loses a lot of information about the communication context in which these activities happen, i.e. where does the content come from. Also, it is impossible to detect the typical phishing sites this way which just trick the users into providing their passwords. Apart from that it might actually increase the attack surface too since these monitoring solutions usually run with elevated privileges but are far from bug free.

In summary: Like other kinds of content analysis SSL interception has its advantages and disadvantages, i.e. it increases the security while also decreasing it in a way. But, properly implemented and used the increase in security will outweigh the decrease in many use cases. And, while there are other ways to fight malware and phishing they have their own advantages and disadvantages and are not necessarily better than SSL interception. Also, it is for example useful to have both central SSL interception in the perimeter firewall and desktop AV as part of a defense in depth strategy.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • But can't a virus simply encrypt its own traffic, even over HTTP, so that an anti-virus can't find it until it's decrypted by the browser, and then executed? – Nacht Jul 24 '17 at 04:56
  • @Nacht: A page in the browser has usually no direct access to the local disk so it cannot be done from a simple web site. But it is common that a successful exploits first installs a minimal and seemingly innocent dropper which then loads and unpacks/decrypts the real malware. It is also common that C+C communication is encrypted without or additionally to HTTPS. Still, SSL interception can help to detect such unusual traffic (dropper, download from dropper, strange traffic from C+C...). Apart from that SSL interception is just one part of security and does not claim to solve all problems. – Steffen Ullrich Jul 24 '17 at 07:26
0

SSL proxies (doing MITM attacks) are the only way to perform deep packet inspection at the external entry point. And the only way to control that security rules are obeyed. It is not to allow a lazy admin not to maintain security on desktops, but to protect the network against employees that cannot understand why they should not act at work as they do at home. The problem is not employees actively willing to leak data, but inadvertantly exposing their desktop to various threats or spending too much time on sites unrelated with their work, or even worse on illegal sites. The responsability of the employer (and of the admin) can be engaged if appropriate actions have not been taken to avoid that organization machines are involved in illicite activities. So while it should be controled to protect employees privacy, best practice rules recommend deep packet inspection on the external firewall.

Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
  • The fact that you mention employees spending time on sites unrelated to work shows that at least some companies use this practise to keep tabs on their employees, which I deem to be a terrible reason. – Nacht Jul 29 '17 at 01:12