Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
add comment

4 Answers

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.

share|improve this answer
add comment

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.

share|improve this answer
    
I understand the use of a certificate from a private trusted root CA in the organization which will be pushed to all the clients to avoid security warnings. but is it really necessary to use the intermediate CA? –  AdnanG Aug 20 '13 at 8:27
    
Yes. You're supposed to use the intermediate CA for signing actual certs. It means that it MUST be readily accessible and therefore more likely to get compromised. if that happens, you can repudiate the CA and use a new one without problem. If your root CA, however, is compromised, then you HAVE to roll out a completely new one to each client manually (since you just lost your trust chain). –  Stephane Aug 20 '13 at 10:08
    
Or maybe generate a self signed certificate on the interceptor and distribute it to the clients in the organization. –  AdnanG Aug 20 '13 at 11:16
1  
@AdnanG That kind of solution doesn't scale at all. Typically, you'll end up with a certificate with very high lifetime (because it's a burden to update) and a poor revocation mechanism. Please, in the name of the next admin that will have to support this mess, do not do this. Ever. –  Stephane Aug 20 '13 at 12:04
add comment

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.
share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.