Superfish vs. Corporate MITM

Question

I work for a consulting company, and I have been implementing a tool from a security vendor, which is a cloud proxy for all user traffic. It will perform malware scanning and filtering of all web traffic. It works by enforcing a proxy autoconfiguration file to redirect HTTP/HTTPS traffic to one of the vendor's global data centers. We, of course, need to deploy certificates to each workstation in order to proxy HTTPS traffic and perform the MITM for malware scanning.

My question: how is this different from Superfish installing a root cert? I've been reading about how the private key for Superfish is stored on the machine. I assume corporate MITM attacks do not have this same vulnerability, but how does the architecture work differently in a corporate environment?

Answer 1

What makes Superfish, and similar products (all herein just referred to as "Superfish"), different from corporate MitM is that Superfish is doing the MitM on the client machine. Corporate MitM is performed on a separate server or appliance.

This is important because the system performing the MitM must have the private key of a Trusted Root CA in order to work. (Strictly speaking, the Root CA doesn't need to be trusted. But the user will see red flags if it's not.)

For Superfish, that means the key has to be on the client device - one which is notoriously not well-maintained and generally very vulnerable to attacks.

For corporate MitMs, the key is on the monitoring server - typically maintained by experienced personnel who perform regular maintenance and do not do things (e.g.: web browsing, downloading extra software, opening documents, etc.) that would expose the system to unnecessary risk.

However, all SSL proxies (corporate or otherwise) still need to be carefully implemented to account for the fact that they are removing the client's ability to self-validate the remote system's certificate. Particularly this means:

1. The SSL proxy must properly validate the remote systems' certificates and either appropriately warn the user or drop the connection entirely when something is amiss. As Charles Duffy mentioned in the comments, properly validating certificates also requires that the proxy does not trust its own built-in CA.
2. Ideally, the SSL proxy should also do some integrity verification against historical or community-aggregated reference certificates. This is implemented in some web browser extensions, and under normal circumstances can be manually performed by the user, to help detect fraudulent use of otherwise-trustworty Root CAs. Since the SSL proxy removes the user's ability to do this themselves, or to effectively use a browser extension for this purpose, it would be best if the proxy could do its own checking to compensate. (Though I doubt this is available in most corporate MitM products.)

Another thing you need to be careful about, since you mentioned that this service is provided to you by an outside vendor, is that the SSL proxy can see all of your users' traffic as if it was unencrypted. (That's the very purpose of an SSL proxy.) This means that data you would otherwise want to have protected from third-party viewers is going to be fully visible by the vendor should they choose to abuse your trust.

Answer 2

The main difference between Superfish and a Corporate Proxy is how the new SSL certificate is generated.

In the Superfish case, the CA certificate and the private key stands on the client computer, and the software generates a new SSL certificate with a key it have on itself. The traffic is intercepted locally, a new certificate is generated on the client, and sent to the browser. Anyone having access to debug tools can extract the certificate and the key, because they are both on the client computer.

In the Corporate Proxy case, the CA Certificate will be installed on every client computer, but the private key resides on the proxy server. If the server is have adequate protection, the key will not be compromised. The traffic is intercepted on the proxy server, and sent with a new certificate to the client. It's not possible to extract the private key on the client, because the key is only on the server.

Answer 3

while the other amswers are correct about implementation details, the security issue in play is one of authorization.

In the case of Superfish and related stuffs, the system owner typically doesn't want Superfish to be able to read all the stuff that is sent and received via HTTPS. On your home computer, you probably don't want Superfish to have your credit card details, online health details, etc. In a corporation, you typically don't want Superfish to be able to konitor everything you access for business purposes, like when accessing corporate web email clients or when researching something for a trade secret. Also, superfish does all this somewhat surreptitiously in that it's installed before you ever get the computer and you aren't warned that it's in place, so you have no opportunity to authorize or reject its use.

With a corporate MitM, the company is the system owner., not the end user, and not Superfish. The company, in an attempt to improve security sets up a proxy server that is authorized and whose risks and value has been accepted.

It's not that the basic idea of a proxy is necessarily bad. It's that an unauthorized proxy that allows unauthorized companies/imdividuals to access your stuff is bad.