Mozilla's message to certificate authorities [LWN.net]

Mozilla has announced that it has sent a message to all of its recognized certificate authorities about the practice of issuing subordinate root certificates for man-in-the-middle attacks. Such use, they say, is not acceptable. "In addition to this clarification, we have made several requests. We have requested that any such certificates be revoked, and their HSMs destroyed. We have requested the serial numbers of those certificates and fingerprints of their signing roots so that we, and other relying parties, can detect and distrust these subCA certificates if encountered. We have requested that any CAs who have issued subCA certificates fulfill these requests no later than April 27, 2012."

to post comments

Mozilla's message to certificate authorities

Posted Feb 18, 2012 17:58 UTC (Sat) by GhePeU (subscriber, #56133) [Link] (9 responses)

Good, such a certificate has no reason to exist. Even on a closed network (like a company network) a subordinate root certificate issued by a "legitimate" authority wouldn't be required to monitor SSL traffic, because the company could mandate the installation of a company-generated root on all company devices (assuming that this kind of surveillance is lawful).

Mozilla's message to certificate authorities

Posted Feb 18, 2012 18:09 UTC (Sat) by cwillu (guest, #67268) [Link] (8 responses)

But how will you monitor the traffic of the iphones that marketing insists on having (but not permitting IT to take responsibility for?)

*grumble*

Mozilla's message to certificate authorities

Posted Feb 18, 2012 18:20 UTC (Sat) by Kit (guest, #55925) [Link] (3 responses)

Easy: The iPhone owner will either be stuck having to use 3G for usage with SSL websites, or must install the company's CA cert. You _can_ install your own CA certs on iPhones, so this is more than possible.

Of course, I find the entire practice shady, but at least in the US, companies are have been held legally responsible for actions taken by individuals on their networks (such as sending around an offensive email)...

I'm glad Mozilla has come out and taken this stance, although I'm disappointed they didn't say anything about continuing this practice PAST their deadline being a serious, delistable offense. I have a feeling most CAs will just carry on. Now for Google, Apple, and Microsoft to get on the bandwagon...

Mozilla's message to certificate authorities

Posted Feb 18, 2012 18:26 UTC (Sat) by josh (subscriber, #17465) [Link] (2 responses)

Mozilla very explicitly did say that:

After April 27, 2012, if it is found that a subordinate CA is being used for MITM, we will take action to mitigate, including and up to removing the corresponding root certificate. Based on Mozilla’s assessment, we may also remove any of your other root certificates, and root certificates from other organizations that cross-sign your certificates.

Mozilla's message to certificate authorities

Posted Feb 18, 2012 18:28 UTC (Sat) by Kit (guest, #55925) [Link] (1 responses)

Wow, I have no idea how I missed that when I read through it. That's pretty much exactly what I _WANTED_ to see.

Mozilla's message to certificate authorities

Posted Feb 20, 2012 9:31 UTC (Mon) by ekj (guest, #1524) [Link]

I dunno, I think it comes somewhat short of exactly what I wanted to see. Specifically, they include *this* among the "recommended responses":

"b) SubCAs are technically and/or contractually restricted to only issue certificates to domains that they legitimately own or control, and they are specifically not allowed to use their subordinate certificates for the purpose of MITM."

Notice the "or".

A CA that isses certificates that can be used for signing any certificate and is thus perfectly usable for MITM, is thus perfectly acceptable if those receiving the SubCAs are "contractually restricted" from using their SubCA for MITM-activity.

That doesn't give me the fuzzies; because "contractual obligations" are only worth anything if you trust the entity which signed the contract. Do I want to trust any and all companies who are willing to pay what a SubCA costs ?

Not only am I trusting a bunch of CAs that are (demonstrably) of questionable trustworthiness. I'm also trusting anyone who is willing to sign a contract with them saying "I'll be good, promise."

Mozilla's message to certificate authorities

Posted Feb 18, 2012 18:35 UTC (Sat) by josh (subscriber, #17465) [Link] (1 responses)

Don't. If employees want to take responsibility for their own devices, let them, and kick those devices off the network if they do anything wrong (e.g. spam/virus/botnet/illegal-activity/etc).

If you have a security environment with severe restrictions about compartmentalization of information, stick user-managed devices on a separate network segment without access to sensitive internal resources.

What, exactly, do you expect to gain by sniffing SSL traffic from a user's personal smartphone?

Mozilla's message to certificate authorities

Posted Feb 18, 2012 20:05 UTC (Sat) by wblew (subscriber, #39088) [Link]

After all, you cannot claim any ownership of that smart phone, right?

Mozilla's message to certificate authorities

Posted Feb 19, 2012 8:18 UTC (Sun) by epa (subscriber, #39769) [Link]

I guess Apple has (or will have) a similar policy against MITM attacks?

Mozilla's message to certificate authorities

Posted Feb 20, 2012 17:57 UTC (Mon) by dkzm (guest, #55549) [Link]

on iPhones you could easily use iPCU(and enterprise management tools) to do that.
there is more interesting question:how to do that on android?especially old 2.3.x phones,which simple don't support CA install without drastic measures(rooting + patching db)

fix the ssl stack

Posted Feb 18, 2012 20:26 UTC (Sat) by martin.langhoff (subscriber, #61417) [Link] (14 responses)

Subordinate certs have no place in our PKI. Can we fix the SSL stack to refuse them unless I have configured it with "mitm=yesplease"?

fix the ssl stack

Posted Feb 18, 2012 21:45 UTC (Sat) by tialaramex (subscriber, #21167) [Link] (11 responses)

Yes, but, all the major CAs use subordinates. So basically you might as well just remove all the CA certs from your browser. Congratulations, now you have no idea which sites are "really" who they say they are.

fix the ssl stack

Posted Feb 18, 2012 22:47 UTC (Sat) by josh (subscriber, #17465) [Link] (10 responses)

Using a subordinate CA to avoid putting the root certificate on an Internet-connected machine makes perfect sense. Using a subordinate CA with an explicit restriction on them that only allows them to sign subdomains of a particular domain they own makes sense. Almost any other use of a subordinate CA seems like an unwarranted bit of transitive trust; those subordinate CAs should have to follow the same procedures as the root CAs.

fix the ssl stack

Posted Feb 19, 2012 0:03 UTC (Sun) by martin.langhoff (subscriber, #61417) [Link] (4 responses)

Having an unrestricted subordinate cert on an internet connected machine does not make "perfect sense". I hope no CA does this, and security breach becomes a very serious issue right there.

I much prefer upping the requirements to have the root certs sign (almost*) everything from the secluded safetly of having an air gap. It is awkward, but the alternative isn't looking pretty.

* - Subordinates restricted to subdomains are fine.

fix the ssl stack

Posted Feb 19, 2012 5:25 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

>Having an unrestricted subordinate cert on an internet connected machine does not make "perfect sense"

Well, how else are you going to, you know, generate certificates? Though subordinate certs are usually loaded on HSMs (Hardware Security Modules) which communicate with the external world through very simple interfaces.

fix the ssl stack

Posted Feb 19, 2012 6:45 UTC (Sun) by raven667 (subscriber, #5198) [Link] (1 responses)

I don't get that. People put in their credit card info and get a signed cert. how are you supposed to air gap that, it happens hundreds or thousands of times a day

fix the ssl stack

Posted Feb 19, 2012 14:12 UTC (Sun) by leromarinvit (subscriber, #56850) [Link]

Well, they could do some actual work for the money they charge.

fix the ssl stack

Posted Feb 19, 2012 8:03 UTC (Sun) by j16sdiz (guest, #57302) [Link]

Many encryption algorithm depends some never repeated random number (I means RSA and all discrete log algorithm). To give more safe margin, you should not use the same key too many times.

A time-limited subordinates CA helps security. And this is also why we use subkeys in GPG.

fix the ssl stack

Posted Feb 19, 2012 14:05 UTC (Sun) by kleptog (subscriber, #1183) [Link] (4 responses)

I was under the impression that certificates which can only sign for subdomains of a particular domain don't actually work/exist. Wildcard domains are somewhat of a hack.

The whole SSL authority architecture is really not up to the task in the 21st century.

fix the ssl stack

Posted Feb 19, 2012 19:45 UTC (Sun) by josh (subscriber, #17465) [Link] (3 responses)

As I understand it, X.509 supports name constraints anywhere in the chain. So, a root CA could issue a subordinate CA certificate with a name constraint for *.example.com, and that sub-CA could sign separate certificates for www.example.com, customer1.example.com, and customer2.example.com, but it could not validly sign a certificate for example.net.

fix the ssl stack

Posted Feb 20, 2012 11:01 UTC (Mon) by cortana (subscriber, #24596) [Link] (1 responses)

Why on earth isn't this used for the root certificates? There's no reason that a governmental certificate authority would be able to sign certificates out of its ccTLD, for instance.

fix the ssl stack

Posted Feb 24, 2012 22:08 UTC (Fri) by BenHutchings (subscriber, #37955) [Link]

If the browser vendors say that governmental CAs should be restricted to their countries - which is perhaps a reasonable policy - those governments might also reasonably demand that they have monopoly control over certificates for their ccTLDs. For example, CNNIC runs the registry for .cn and also a CA, so while you may not really trust them it's hard to argue that they are not the proper CA for .cn.

So then every non-govermental CA should mark their certificate as authoritative for each of the gTLDs and ccTLDs where the government doesn't do this, and then update the certificate whenever that set changes.

It is maybe better to have this controlled outside of the certificates themselves - like the overall trust bits are today. But the browser vendors could set reasonable defaults.

fix the ssl stack

Posted Feb 24, 2012 22:03 UTC (Fri) by BenHutchings (subscriber, #37955) [Link]

So far as X.509 is concerned, the domain name in an SSL certificate is an arbitrary unstructured name (common name, CN). X.509 supports single-rooted delegation through an X.500 hierarchy (the other naming fields) but not through the common name. Domain name constraints can be added as an extension but older SSL implementations will ignore them.

fix the ssl stack

Posted Feb 18, 2012 22:48 UTC (Sat) by josh (subscriber, #17465) [Link]

Given an appropriate transition period to accommodate the numerous sites whose certificates currently have signatures from subordinate CAs, that seems entirely sensible.

fix the ssl stack

Posted Feb 19, 2012 2:58 UTC (Sun) by leromarinvit (subscriber, #56850) [Link]

I always thought sub-CAs were used for different levels of security (for the private key). Basically, make it damn near impossible to steal the root CA, even if that means it's damn near impossible to work with. As in, the key is split into multiple parts, encrypted with a key no single person knows in its entirety, stored in safes with multiple locks, the keys again held by different persons, in separate buildings in different countries, with guards posted at the door, etc.

This root CA can then be trusted for decades, and it would only be used every few years to generate a new CA for day to day work which much shorter lifetime, and a lot less security. Should that CA be compromised, revoke it and create a new one early. The clients would almost never need to install new root certs, because all intermediate CAs lead back to the super-safe one.

I had no idea CAs would actially issue sub-CAs to third parties more or less unchecked, and that this seems to be even commonplace. Makes me trust CAs a whole lot less...

Mozilla's message to certificate authorities

Posted Feb 18, 2012 22:50 UTC (Sat) by paravoid (subscriber, #32869) [Link] (6 responses)

They can't really force e.g. Verisign or Comodo to do anything, since it would be impossible to remove the CAs from Firefox (too much breakage that it would seem to people like Firefox is broken, rather than the other way around)

So, either this is a bluff, or, more likely, it was done together with the CAs, with the CAs just wanting to give the announcement as a reason to their customers.

Mozilla's message to certificate authorities

Posted Feb 18, 2012 23:31 UTC (Sat) by Tobu (subscriber, #24111) [Link]

They allow for a gradual response. If few things break, for example because Mozilla removes transitive trust and have a less-updated list of reseller CAs (a welcome move anyway), the fallout will be blamed on the negligent CAs (where it belongs).

Mozilla's message to certificate authorities

Posted Feb 19, 2012 8:59 UTC (Sun) by slashdot (guest, #22014) [Link]

Mozilla can just whitelist the certificates for major sites.

That way, Firefox will not seem broken, but all the minor sites using that CA will.

Mozilla's message to certificate authorities

Posted Feb 19, 2012 9:16 UTC (Sun) by epa (subscriber, #39769) [Link] (1 responses)

If they removed Verisign then everyone would just click through the SSL certificate warnings as Firefox has trained them to do already.

Mozilla's message to certificate authorities

Posted Feb 19, 2012 14:32 UTC (Sun) by did447 (guest, #49454) [Link]

Right, but if you have to buy a new certificate what would you do?

Mozilla's message to certificate authorities

Posted Feb 19, 2012 11:55 UTC (Sun) by ewan (guest, #5533) [Link] (1 responses)

Bear in mind that Mozilla controls the messaging that the user sees; they don't need to just drop the certs and fall back to the standard SSL errors. They could detect this situation and give the user a message putting the blame squarely where they want it put.

Mozilla's message to certificate authorities

Posted Feb 20, 2012 5:50 UTC (Mon) by rahvin (guest, #16953) [Link]

Or they could do like they did previously and make it almost completely impossible to trust the certificate short of hand editing configuration variables in about:info.

Mozilla's message to certificate authorities

Posted Feb 19, 2012 19:50 UTC (Sun) by slashdot (guest, #22014) [Link]

Kill the evil CAs with fire!

Now!

Burn burn burn!!!