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?
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.
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.
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
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.
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.
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:
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:
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.