What are the risks associated with SSL interception in an Organization?

Question

If an SSL interceptor is installed for security reasons in an Organization, and a certificate from intermediate CA is installed on all domain machines, what kind of risks this setup presents?

Answer 1

Compromising your root or intermediate CA is going to be easier than compromising a commercial CA, so it decreases the cost of mounting an undetectable to the user man-in-the-middle attack on HTTPS connections when your employees are directly connected to the internet (e.g. coffee shop wifi). I don't see this as being a very large threat.

There is the obvious increased risk to users from a malicious employer / sysadmin / compromised proxy server - the attacker can now intercept and steal all of their personal social networking/email/bank credentials.

Answer 2

Operationally, this has caused issues for root certificates not in the proxy server's trusted store. This is common if the network administrator doesn't keep up with the patches on the appliance, or if the appliance is out of date (see Bluecoat).

I've noticed that servers that use a HTTPS proxy have a number of issues, especially if the proxy inadvertently proxies network equipment such as load balancers, etc. To this end we disabled proxying for servers.

Finally, there may be issues deploying the CA infrastructure internally, and making it highly available. The CRL must be available over HTTP, (not HTTPS), and OCSP needs to be properly configured.

If the CRL isn't updated often enough, (as specified in next update ) then it's possible for some internal clients to reject the cert based on the premise that they can't prove that it's been revoked.

Finally, the root certificate has to be in all the applicable local stores. For example, Java, Firefox, IE/Windows all have different stores that need to be updated. Deploying a certificate isn't as simple as deploying it though GPO.

Also consider your non AD devices such as Macs, iPhones, mobile devices that aren't centrally managed (BYOD) in deploying this root certificate.

Bottom line

The complexities involved in deploying a centralized SSL proxy may create holes in your security policy that are unexpected, and/or not maintained.

A comprehensive solution should be in place to maintain, exempt, or ban incompatible components that don't fit the security policy. This should be made as simple as possible.

e.g. Exempt servers, and mobile devices on wifi.  Everything on corpnet as a workstation must be proxied.

Answer 3

The risks are about the same as those implied by giving to a designated security guard a key which opens all doors in a building:

• The guard becomes a valuable target; attackers will want to rob the guard or to bribe the guard, in order to obtain the golden key.

• Being all-encompassing, the key bypasses all procedures and security layers; you cannot isolate parts of the building from each other, if the potential attacker has a key which opens all doors.

• Knowledge of the mere existence of an open-everything key in the hands of some security guard will make the users quite distrustful. Human users tend to value their privacy, and don't like the idea that someone will be routinely opening their desks and lockers and inspect the contents.

Beyond the key analogy, using SSL interception (with an organization-specific CA used to build MitM attacks on the fly) has the following specific consequences:

• On the desktop systems, the interception requires installation of the special CA certificate in the "trusted store". This installation has to be done again whenever a new OS is installed; users may remove it themselves; some Web browsers (in particular Firefox) will disregard the OS trust store and use their own. Thus, there is ample room for breakage here. This can be somewhat fixed by locking down the OS configuration and software installation, but the more you lock things down, the less happy the users become.

• The OS trust store may be used for other uses than mere SSL; it can be used to verify signatures on software updates and drivers, for instance. An attacker who succeeds in stealing the private key for the organization CA may thus gain extensive power on the whole network, not just the ability to intercept SSL connections (which is already a lot).

• The private key for the organization CA is thus sensitive, but cannot be protected with high isolation layers, because that special CA, by construction, must be able to issue fake SSL server certificates on the fly. So it must be online, on a server which is "close to the Internet".

• Such MitM interception breaks certificate-based client authentication. https:// Web sites very rarely use client certificates, but I have seen it done by some banks to authenticate their customers (at least as part of experimental deployments).

• In many jurisdictions, automatic inspection of user's communications by the employer is lawful, but subject to some conditions, usually an explicit notification right there in the employee's contract. There can be legal risks related to such interception (similarly to reading letters, tapping on the phone and installing video cameras in offices). Some detour through the law department is strongly advised.

So we can say that while organizational SSL interception allows for inspection of SSL-downloaded contents (thus antivirus and other filters can be applied on the proxy), it also opens new vulnerabilities. Thus, the overall security situation might be worsened by the installation of such system.

Answer 4

I did this last year for a client, and when you run a proper risk analysis, it turns out that the proxy server compromise or loss of root certificat is a technical risk for sure, but other risks factor higher in the final assessment.

Note: This is location-specific. Outside Europe, for example, the privacy risk may not apply.

1. Privacy - if your company allows(1) private use of Internet, you can run into all kinds of troubles when you inspect packages that employees can assume to be protected against just such a thing.
2. Liability - if something happens where SSL plays a role, e.g. an employee makes a transaction in online banking and there is a successful attack on it, you breaking open the SSL session puts you right into the line of fire. Now you need to prove that you are innocent. Without SSL interception, someone else would have to prove that you are guilty.
3. Legal - check with your law department. There are a lot of laws about telecommunication and intercepting of the same, and some of them may apply to SSL interception. This may depend on minute details and only a legal expert can answer it.
4. Exceptions - every company has someone who can claim an exception. It might be a union office, a data privacy officer, a top-level executive, members of the mergers & acquisition team, a medical doctor - there is always someone whose communications are priviledged and you need to check very carefully if you can legally intercept them without ending up in a world of pain.
5. Attack surface - others already answered on the risk of having your proxy server hacked. I just want to add that there are many tests and studies that show many of these SSL proxies are quite badly secured. I found reports from 2004 all the way up to 2016 with details. I don't want to link to any because I don't know which of these vendors fixed their problems in the meantime, but a quick search will reveal them.
6. Certificate handling - also already explained. If you run a PKI or have good certificate and key management processes in place, this should be fine. If you don't, this is a potential source of trouble.

---

(1) "allow" in this context is essentially everything that doesn't strictly forbid it. If you allow with qualifications (during break times, only for urgent matters, as long as it doesn't affect the work, whatever), you allow. I talked this through with a judge of the highest court in my country, and he was very clear that they see this strictly binary.

Answer 5

The main risk I can see is the compromised of the proxy server itself. This will allow the attacker to decrypt all traffic going through that system.

There is the fact that this setup is incompatible with some authentication mechanism: any system that relies on SSL client certificate authentication will fail to work.

A wider issue is the quality of the implementation itself: it needs to use a private root CA as well as intermediary CA, complete with proper revocation mechanism and tight security on all the CA elements. Doing things improperly in the design stage is likely to leave much more than your SSL traffic up for grab.