Local CAs and an interesting consequence of the SSL security model

December 19, 2009

Suppose that your organization creates an internal organizational Certificate Authority, so that it can issue SSL certificates for strictly internal hostnames. Of course, everyone needs to have the internal CA's certificate loaded in their browser and so on in order to get work done on your intranet; as a practical matter, you probably preload it in your standard machine setups. I suspect that this is a not uncommon setup in sufficiently large companies.

It's recently struck me that this has an interesting consequence: your company security and firewall people can now intercept and proxy any or all external https websites without certificate warnings. All they have to do is make a certificate for whatever hostname they want and sign it with the internal CA certificate. This works because CA certs do not have restricted spheres of operation (at least as far as I know), so you cannot create a CA certificate that can only be used to sign your internal hostnames.

(You can only use your internal CA cert for this purpose, but the difference between 'only used' and 'can only be used', while small, is vital.)

Since this will be more or less transparent (although not difficult to detect), it's unfortunately now probably significantly more attractive to the powers that be. There are all sorts of firewall security people who probably salivate over the prospects of no longer having to pass https traffic uninspected and unmolested, or block it entirely.

(The cynical view is that even having restricted spheres of operation for CA certificates wouldn't help. The kind of people who would push for firewall https interception would also push for the company CA certificate having no sphere of operation restriction, and that's always going to be possible.)


Comments on this page:

From 24.112.150.130 at 2009-12-19 06:55:56:

Assuming this is done legally, and with clear expectations, I think it is not only good practice, but inevitable. Right now 20-30% of web traffic is in encrypted. It's growing so fast that it will default to HTTPS in the next 18 months or so.

So, if a local browser exploit allows for outbound, unmonitored traffic that essentially creates a VPN for the bad guy. That's not a tolerable risk. I forecast SSL inspection as standard practice in two to three years. Several commercial vendors already offer it out of the box.

From 78.86.233.73 at 2009-12-20 03:45:49:

Yes, you can add name constraints. X509v3 has the, unsurprisingly named "NameConstraints" extension where you would say "permittedSubtrees: DNS:mycompany" which should disallow it from issuing certificates outside of *.mycompany.

I don't know if any clients actually check this, though. I suspect they generally don't.

– Tollef Fog Heen, tfheen@err.no

From 195.171.114.194 at 2009-12-21 08:23:10:

I can confirm that this is being done in at least one company I know of. In addition to stripping out and proxying https, they also inspect the contents and whitelist the sites. The staff -- at least the one I know -- do know about this.

Written on 19 December 2009.
« Secure or useful: pick one
Some thoughts on intercepting https traffic »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Sat Dec 19 02:49:43 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.