There was some coverage that I came across the other day that I thought was interesting about how Mozilla is considering rejecting TeliaSonera’s application for a new root certificate. At the core of the issue is the question of whether or not they acted appropriately in their practice of knowingly issuing certificates that allow governments to snoop on traffic.
The backstory is that the Swedish television program “Uppdrag granskning” (i.e., “Mission: Investigation”), an investigative journalism program, aired an episode called “The Black Boxes” consisting of an hour long investigation of how TeliaSonera allegedly sells citizen intelligence information to dictatorships (you can watch it subtitled on their site and rebroadcasted through YouTube).
To enable the snooping, TeliaSonera (according to the report) issued certificates from the trusted root that allow governments to snoop on traffic. Meaning, they issued “spoof” certificates. These are certificates issued on behalf of somebody else that the government doesn’t own that were given to the government in question. As an example, if I were able to obtain a cert that claimed I was “google.com” so that I could proxy web traffic and investigate the content of web searches going by. Fun, right? Of course, I couldn’t do that… but I’m not a government. From the CNET coverage:
Allegedly, the telecom company allowed Eastern European and Central Asian governments — specifically Azerbaijan, Kazakhstan, Georgia, Uzbekistan, and Tajikistan — to eavesdrop on citizen’s private Internet use. The way TeliaSonera supposedly let this happen was by issuing certificates to the governments that let them pose as legitimate Web sites and decrypt Web traffic, according to the Register.
Why does Mozilla care about this? Because the practice is in direct conflict with Mozilla’s CA Certificate Inclusion Policy. This is the document that establishes the criteria for what CA’s must do to be included in the trusted certificate store for Firefox (and other Mozilla projects.) Meaning, it’s the public document that describes what CA’s must do to make the list of what is considered “trusted”. The point of having the list at all is so that users can evaluate and choose whether or not to trust the “out of the box” root certificates — i.e., to have an objective standard that helps users understand whether or not sites using those certs are trusted. From that document:
We consider verification of certificate signing requests to be acceptable if it meets or exceeds the following requirements… for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant’s behalf…
Now, if a dictatorship is not the registrant of a domain, the policy requires that they must be “authorized by the domain registrant to act on the registrant’s behalf.” Were they? Since this was a clandestine activity, the answer is probably “no”. So I’m not surprised that Mozilla is considering taking action here. In fact, it seems to me like Mozilla’s in a bit of a bind if they don’t. Why? Because the program requirements speak to this explicitly. If CA’s can knowingly violate the inclusion program all they want, why have one at all? Just let CA’s slap in whatever: Snoop-o-rama Super Shady Terrorist-Watch-List CA? Absolutely. Lulz-Boat Extended Validation Trusted Root? Don’t mind if I do. So in the presence of direct information about a violation, it would seem to me the program would be undermined if they ignore it.
Other browser’s programs don’t have this same issue. At least not right now. Why not? Because they speak to authorization indirectly rather directly (Mozilla also speaks to it indirectly too, by the way… but the pressure to act is caused by the direct reference to it in the root CA program). The “indirect” route I’m referring to is via the certification audit. Meaning, the Microsoft program (and also Mozilla’s program by the way) require annual validation according to a known standard — for example, WebTrust for Certification Authorities, ETSI TS 101 456 or ISO 21188:2006. Apple’s Root CA Program requires WebTrust explicitly. Each of these programs speak to authorization, but do so as part of the validation process. Take the WebTrust requirements as an example — in that case, the audit criteria compares the CA practices against the CA Browser Forum’s SSL Baseline Requirements. Reproduced below is section 11.1.1 of that document (entitled “Verification Practices – Authorization – Authorization by Domain Name Registrant”):
For each Fully-Qualified Domain Name listed in a Certificate, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant either is the Domain Name Registrant or has control over the FQDN by:
- Confirming the Applicant as the Domain Name Registrant directly with the Domain Name Registrar;
- Communicating directly with the Domain Name Registrant using an address, email, or telephone number provided by the Domain Name Registrar;
- Communicating directly with the Domain Name Registrant using the contact information listed in the WHOIS record’s “registrant”, “technical”, or “administrative” field;
- Communicating with the Domain’s administrator using an email address created by pre-pending ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ in the local part, followed by the at-sign (“@”), followed by the Domain Name, which may be formed by pruning zero or more components from the requested FQDN;
- Relying upon a Domain Authorization Document;
- Having the Applicant demonstrate practical control over the FQDN by making an agreed-upon change to information found on an online Web page identified by a uniform resource identifier containing the FQDN; or
- Using any other method of confirmation, provided that the CA maintains documented evidence that the method of confirmation establishes that the Applicant is the Domain Name Registrant or has control over the FQDN to at least the same level of assurance as those methods previously described. …
If the CA relies upon a Domain Authorization Document to confirm the Applicant’s control over a FQDN, then the Domain Authorization Document MUST substantiate that the communication came from either the Domain Name Registrant (including any private, anonymous, or proxy registration service) or the Domain Name Registrar listed in the WHOIS. The CA MUST verify that the Domain Authorization Document was either (i) dated on or after the certificate request date or (ii) used by the CA to verify a previously issued certificate and that the Domain Name’s WHOIS record has not been modified since the previous certificate’s issuance
Meaning, if a CA doesn’t adhere to this, they should fail the audit. TeliaSonera passed the audit. Granted, this is probably something the audit program should be looking at… but the fact of the matter is that since the Apple and Microsoft programs hinge only on the audit, TeliaSonera technically isn’t in violation yet. They might be if they fail future audits, but they aren’t now. So what will Mozilla do? I guess we’ll see. But it’s pretty interesting stuff.
Image source: funnypart.com
<Note: the views presented are my own and not necessarily those of my employer.>