Re: Web Browsers and Comodo Announce A Successful Certificate Authority Attack, Perhaps From Iran
Brian Smith
> http://freedom-to-tinker.com/blog/sjs/web-browsers-and-comodo-announce-successful-certificate-authority-attack-perhaps-iran
It seems to me that Comodo could have easily, cheaply, and painlessly avoided this situation by implementing some simple checks:
1. Instead of trusting the RA do the domain control validation, it should have done the domain control validation itself.
2. Simply by opening an HTTPS connection on port 443 for each site, it could have detected that each of the sites already have a cert from a different CA with different private/public key pairs. This should have triggered manual review by a security officer and more thorough determination of domain control before the certs were issued.
3. By doing #2, Comodo could have easily detected that some of the sites are using EV certs. No CA should be issuing (non-EV) certs for a website in this situation without comprehensive authentication of the requester.
4. AFAICT, the "global trustee" certificate should never have been issued by any CA because "global trustee" isn't even a valid DNS name. Why would the software even allow a cert with "DNS Name=global trustee" to be generated, regardless of claims of validity?
5. The "global trustee" case shows evidence that the RA's system does not require any network-based (email, http request) validation. AFAICT, the alternate forms of validation of the requester are pretty rare and it seems very reasonable to mandate that someone from Comodo re-validate the request after the RA has done so when this alternative type of validation is used.
6. It seems trivial to build a list of high-value target domains, which would have included all of the domains targeted in this attack. Flagging these high-risk domains as for manual review by multiple people at Comodo would have almost definitely prevented these certs from being issued.
7. The mismatch between the country of the requester (Iran) and the subjects of the certificates (US), and the mismatch between the country of the requester and the geo-ip lookup for the servers in question similarly should have been red flags triggering more validation to be done.
In all the cases where there is a red flag, it makes the most sense to halt the process and do the extra validation *before* the cert is *generated* (not just before it is *sent* to the requester).
It seems to me that it is reasonable to expect and require CAs in our root program to commit to making doing these checks and to require audits of CAs to verify that carefully-secured mechanisms for doing these checks are in place. (Interestingly, I read that Comodo already claimed it started doing #1 after a previous incident; I do not understand how the attacker was able to get Comodo to issues these certs in this situation, based on their description of the events.)
- Brian Smith (no relation to the Brian Smith @ Comodo)
Eddy Nigg
> 1. Instead of trusting the RA do the domain control validation, it should have done the domain control validation itself.
See https://bugzilla.mozilla.org/show_bug.cgi?id=470897#c93
> 4. AFAICT, the "global trustee" certificate should never have been issued by any CA because "global trustee" isn't even a valid DNS name. Why would the software even allow a cert with "DNS Name=global trustee" to be generated, regardless of claims of validity?
Apparently not the slightest sanity checks happen before issuance of a
certificate.
> 5. The "global trustee" case shows evidence that the RA's system does not require any network-based (email, http request) validation. AFAICT, the alternate forms of validation of the requester are pretty rare and it seems very reasonable to mandate that someone from Comodo re-validate the request after the RA has done so when this alternative type of validation is used.
The policy requirement of Mozilla are not enforced. There are
insufficient controls in place to ensure those.
> 6. It seems trivial to build a list of high-value target domains, which would have included all of the domains targeted in this attack. Flagging these high-risk domains as for manual review by multiple people at Comodo would have almost definitely prevented these certs from being issued.
YES! I thought that CAs today are at least that smart, I admit that I
was wrong.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Kyle Hamilton
On Thu, Mar 24, 2011 at 1:09 AM, Brian Smith <bsm...@mozilla.com> wrote:
> "Steve Schultze" wrote:
>> http://freedom-to-tinker.com/blog/sjs/web-browsers-and-comodo-announce-successful-certificate-authority-attack-perhaps-iran
>
> It seems to me that Comodo could have easily, cheaply, and painlessly avoided this situation by implementing some simple checks:
>
> 4. AFAICT, the "global trustee" certificate should never have been issued by any CA because "global trustee" isn't even a valid DNS name. Why would the software even allow a cert with "DNS Name=global trustee" to be generated, regardless of claims of validity?
Are we sure it was only in the SubjectAlternativeName, and not the CommonName? As far as I know, Comodo notified the browsers of the serial numbers, not the full certificates. For all we know, "global trustee" could be an improperly-encoded 0xff byte instead of a 0x20.
> 5. The "global trustee" case shows evidence that the RA's system does not require any network-based (email, http request) validation. AFAICT, the alternate forms of validation of the requester are pretty rare and it seems very reasonable to mandate that someone from Comodo re-validate the request after the RA has done so when this alternative type of validation is used.
Comodo has absolutely failed in its mandate to ensure that only certificates with authoritative information are minted.
Worse, this is the -third- RA-related revocation that Comodo has had to perform.
> In all the cases where there is a red flag, it makes the most sense to halt the process and do the extra validation *before* the cert is *generated* (not just before it is *sent* to the requester).
Absolutely. A certificate is a record of an action: the action of deciding that one is confident in an identity claim to the extent necessary for them to meet their due diligence requirement.
> It seems to me that it is reasonable to expect and require CAs in our root program to commit to making doing these checks and to require audits of CAs to verify that carefully-secured mechanisms for doing these checks are in place. (Interestingly, I read that Comodo already claimed it started doing #1 after a previous incident; I do not understand how the attacker was able to get Comodo to issues these certs in this situation, based on their description of the events.)
To me, it looks as though Comodo has been lying to Mozilla about its internal controls. At this time, I have no recourse but to recommend that their internal controls be deemed insufficient to meet the legitimate security needs of Mozilla's users, and their trust revoked. It as a corporate body has shown that it is either wildly inept or negligent, and it's almost criminally irresponsible to allow them to continue placing Mozilla's entire user base at risk.
The solution is inevitable for any untrustworthy CA: remove Comodo's roots. There's no conceivable way that this could possibly be allowed to stand -- by any trustworthy organization, anyway. I'd like to think that Mozilla actually does have its users' interests at heart.
> - Brian Smith (no relation to the Brian Smith @ Comodo)
-Kyle H
Kyle Hamilton
I propose that Mozilla includes a clause of "only identity information verified with (or through a chain of) authenticated credentials issued by a state-instituted authoritative public record keeper, and which matches what is in those records, may appear in the DN and SAN".
IP addresses are managed by ICANN, instituted by US state authority.
DNS names are managed by ICANN, instituted by US state authority.
Email address namespaces depend on DNS names and/or IP addresses; as a result, ICANN is ultimately responsible for email addresses as well.
Distinguished Names are assigned and managed by the civil register (the clerks of vital statistics) and the corporate register (the secretaries of state).
Telephone network addresses (phone numbers) are managed by the ITU, which is instituted by authority of international treaty.
The current wording permits verification to be performed against any entity, not constrained to the set of authoritative-for-their-namespaces state-instituted entities.
Stating this would make it clear that private addresses and non-qualified host names are prohibited, and non-public authority DNS-like root servers are also prohibited. Remember the new.net fiasco, where they tried to hijack the DNS roots by abuse of ISP capacity to change their nameservers? The current wording permits this. The proposed wording makes it clearly impermissible.
-Kyle H
On Thu, Mar 24, 2011 at 5:08 PM, Kathleen Wilson <kathle...@yahoo.com> wrote:
> On Mar 24, 2:31 pm, "Steingruebl, Andy" <asteingru...@paypal-inc.com>
> wrote:
>> > -----Original Message-----
>> > From: Kathleen Wilson
>>
>> > 5) Move, in a short time-frame (small number of months) towards a model
>> > where each RA issues from a separate subordinate CA certificate.
>> > (started)
>>
>> ....
>>
>> > I have added a few items to
>> >https://wiki.mozilla.org/CA:CertPolicyUpdates#Second_Phase
>> > Under the heading “RAs and Subordinate CAs”
>> > There are some practices, such as some roots signing end-entity certs
>> > directly, that this incident has demonstrated should no longer be allowed,
>> > and need to be corrected soon.
>>
>> Kathleen,
>>
>> Is your stipulation that the "parent" CA should still be in full control of those subordinates and able to audit/control all activities of the subordinates? Maybe that is implicit in your requirements, but I don't see it specifically called out. Comodo's current model allowed them to see these certs, had they used a "fully delegated" subordinate with their RAs this activity wouldn't have had the same visibility.
>>
>> - Andy
>
> Hmmm. I'm not seeing this posting in Thunderbird, only in Google
> Groups.
>
> Yes, for the case where an intermediate CA corresponds to an RA, I was
> assuming that the "parent" CA would be in full control of the
> intermediate CAs.
>
> I add this clarification to the related bullet point in the wiki page:
> https://wiki.mozilla.org/CA:CertPolicyUpdates#RAs_and_Subordinate_CAs
>
> Thanks,
> Kathleen
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
Kyle Hamilton
On Thu, Mar 24, 2011 at 8:44 PM, Peter Gutmann <pgu...@cs.auckland.ac.nz> wrote:
>
> What we have is an industry that claims to be selling trust, but that has
> repeatedly demonstrated its untrustworthiness in a very public manner. And
> while other trust-based industries rely on "trust but verify", the browsers
> just give us "trust and hope". When the PKI fails, as it has repeatedly,
> there's nothing else there to fall back on. If you read the discussion on
> various web forums (admittedly not a representative survey, but the best we
> have to go on at the moment), most people have pretty much zero confidence in
> browser PKI, and very low confidence in browser vendors' seriousness about
> protecting users from harm. This is the real problem that browsers should be
> looking at, not "how wet shall we make the bus ticket before we slap the CA's
> wrist with it" but "how do we deal with the fact that our chosen (and only)
> web security mechanism is repeatedly, and publicly, failing, and our only
> response to date has been PKI-me-harder".
Seconded.
Frankly, this is a lecture that Mozilla has needed to receive and take to heart for a long time now.
This reeks of an illegal protection racket, holding the site's UI hostage to the disclosure of information and payment of fees to the browser's enforcers (the CAs).
The original advertising of SSL certificates to the public was "you know who you're dealing with so you can bring legal action if necessary". The moment that the first domain-validated certificate was issued by an accepted CA, that advertising became false.
<retrospective rambling>
The real reason for strong identity tagging encrypted streams in the clear appears to have been uncertainty about how the sovereign state was going to react to the proposal to relax cryptographic export restrictions. It had always banned export of cryptography because of the potential national security implications -- if people could send messages without the state being able to read them, it would permit espionage; this is why it was (and still is) classed as a munition. This was a source of much confusion and consternation at the time to international business travelers who wanted to use cryptography on their laptops to protect their businesses' information against laptop theft.
When the US government put openly-available cryptographic source code under license exemption TSU in 1998 (as a direct result of Dan Bernstein's ultimately-mooted lawsuit), after it became signatory to the Wassennar Arrangement in 1996, it essentially said "we don't need that kind of tool". The EU privacy directives are a bit more clear in their prescription: "Not only do we not legitimately need that kind of tool, but nobody else has a legitimate use for that tool against personal interactions either." RFC 2527 was hastily thrown together by people who really didn't understand the Wassennar Arrangement's capacity to enable export of strong cryptography.
Since cryptography is still considered a munition under the Arrangement ('dual-use'), and closed-source cryptography is still subject to armament review before export, AND since the 2nd Amendment of the US constitution protects the individual's right to keep and bear arms, it's an armament which has never truly been made available to the people -- the consumers -- who make it the most ubiquitous personal munition in the world.
It's the only thing that could possibly protect them against state-level adversaries, and the blind adherence to the X.509 Dogma that authoritative identity is the only identity worth caring about has crippled their ability to use it.
</rambling>
The problem ultimately comes down to this: The browser has conflated the ideas of "identification" and "authorization".
There is no excuse for this. An identification tells me who I'm talking to. An authorization tells my software that it's okay to not interrupt my flow with the jarring full-stop warning and exception UI when someone in its exclusive club says not to, after having to provide either cash or personal information to one of the club members -- and the shiftiest one of all issued erroneous high-value certificates, after having been called on the carpet -twice- for the same conduct.
And somehow, you think that this is okay.
This situation needs to change, and it needs to change now. Your dogmatic interpretation of X.509 is actively hindering attempts to improve the state of the art. Gentlemen, this conduct is -criminal-. You need to get off your ivory tower and come into the real world where your software's consumers can't use what you're offering them because it is completely WORTHLESS. Improve the security UI. Make it easier for the end consumer to understand what's going on, without interrupting his workflow. You have nothing to lose but the shackles of your dogma.
If you do, everyone wins.
If you don't, everyone loses.
-Kyle H
Kyle Hamilton
On Thu, Mar 24, 2011 at 6:48 PM, Steve Schultze <sjschult...@gmail.com> wrote:
>
> However, I'm not sure that applying these policies against "RAs" is the
> right approach. Or maybe it is, depending on what the definition of "RA"
> is. According to WebTrust (http://www.webtrust.org/item27804.pdf):
>
> "The CA or RA verifies the identity of the subscriber in accordance with the
> CA’s established business practices (that may be contained in a
> certification practice statement), and then issues a digital certificate."
> and
> "An RA is an entity that is responsible for the identification and
> authentication of subscribers, but does not sign or issue certificates."
>
> So perhaps even WebTrust isn't consistent... does an RA issue certs? Does it
> verify identity? I think that any entity that has the operational and/or
> cryptographic ability to issue certs (directly, or by asserting identity to
> an entity that issues the certs) should be audited and publicly disclosed.
> Is that unreasonable?
The relationship between an RA and a CA is contractual, and outside the scope of technical standards. If the RA is not compliant, the contract (the treaty) is broken and the CA can refuse to accept those assertions.
So, what an RA does is verify and authenticate information, and then (in some manner which is outside the scope of the standards) communicates that to the CA. The CA is the one who issues the certificate (and the one who the CA policy has been attached to), but the RA can issue a statement that the subject identity information has been verified (as far as it goes), and recommend the issuance of the certificate.
The RA essentially is the result of the CA outsourcing the identity verification bit. This is necessary at the state level because there are agencies devoted to finding correct information for the benefit of the rest of the state's body, whereas the administration of the state CA is a treaty matter and thus needs to be perfectly-specified and perfectly-presented. (The penalty for violation of this is the revocation of recognized state identity by every other state that receives false information.) This is not necessary or even desirable in the world of the sovereign citizen.
X.500 (and all of its companion specifications) is perfect for the sovereign state. It's also perfect for conveying information that will be needed for the state to be brought into any dispute. It isn't useful for enabling society to function without realizing that every subject within the state (be it a natural person or a corporation, in the US) is just as sovereign when relating to the other subjects of the many states.
In other words, the individual subject is effectively a state of his own when dealing with other individual subjects. The individual subject is indeed an Authority, sovereign and authoritative for the set of identities he can legitimately claim. He can choose which subset of his identities he wants to assert in any given interaction.
The individual is not authoritative for any individual identity or reputation he can claim, though, which is why CAs are integral to the system. Basically, a publicly-trusted CA can be viewed as an information broker, like credit reporting agencies. They don't have any particular authority of their own, they have only their reputation to back up their advertisements that they can be trusted to some degree.
Comodo has earned itself a bad reputation, and simply must be culled. After this third RA-related failure, it would be almost criminally negligent in its due diligence for Mozilla to allow Comodo -- as a corporation, not merely the single root affected -- to continue to be trusted in its root certification program.
There is -no- possible way for Comodo to regain my trust, and I truly fear for the online security of my friends and acquaintances. Even an action by the state couldn't make me trust them ever again. Let me tell you, the state is the closest thing to God that we humans provably have. If the state can't force me to put my trust in something, I would indeed be damned if I didn't object to Mozilla silently causing anyone else (indeed, almost everyone else) to silently trust it. I will indeed object to every wrong I see, and I cannot see anything which I don't object to in this root program and the security implications of the failure to act.)
I really wish that I could trust Mozilla. It's a shame that it has shown time and time again that its certification program is, to put it inelegantly, complete and utter bull hockey.
I believe that Mozilla Foundation should not have control over the root program any longer. It has shown, time and again, that it can't be trusted with its most valuable (and as Peter points out, only) security measure against fraud and malfeasance.
-Kyle H
Jeremy Rowley
Ben Bucksch
On 24.03.2011 09:09, Brian Smith wrote:
> 4. AFAICT, the "global trustee" certificate should never have been issued by any CA because "global trustee" isn't even a valid DNS name. Why would the software even allow a cert with "DNS Name=global trustee" to be generated, regardless of claims of validity?
I assume that was the string "*", not "global trustee"
[lots of good ideas for sanity checks]
> 7. The mismatch between the country of the requester (Iran) and the subjects of the certificates (US), and the mismatch between the country of the requester and the geo-ip lookup for the servers in question similarly
I have to disagree here. I may be a German with a German company, but
sitting in a home or office in Italy. I should not be subject to
discrimination in that case.
> In all the cases where there is a red flag, it makes the most sense to halt the process and do the extra validation *before* the cert is *generated* (not just before it is *sent* to the requester).
Agreed.
Ben
Kathleen Wilson
https://wiki.mozilla.org/CA:CertPolicyUpdates#Domain_Names
Kathleeen
Erwann Abalea
> On 24.03.2011 09:09, Brian Smith wrote:
> > 4. AFAICT, the "global trustee" certificate should never have been issued by any CA because "global trustee" isn't even a valid DNS name. Why would the software even allow a cert with "DNS Name=global trustee" to be generated, regardless of claims of validity?
>
> I assume that was the string "*", not "global trustee"
That's really the PrintableString "global trustee", with a \x20
character.
You can get the 9 certificates on Windows, after having applied the
security updates.
--
Erwann.
Florian Weimer
> I propose that Mozilla includes a clause of "only identity
> information verified with (or through a chain of) authenticated
> credentials issued by a state-instituted authoritative public record
> keeper, and which matches what is in those records, may appear in
> the DN and SAN".
Would this apply to EV certificates? The EV certificates are
deliberately written in such a way that organization A may obtain an
EV certificate for organization B (which cannot obtain an EV
certificate on their own because it is a legal person of the wrong
kind).
> IP addresses are managed by ICANN, instituted by US state authority.
> DNS names are managed by ICANN, instituted by US state authority.
> Email address namespaces depend on DNS names and/or IP addresses; as
> a result, ICANN is ultimately responsible for email addresses as
> well.
This seems to be a gross oversimplification to me.
> Distinguished Names are assigned and managed by the civil register
> (the clerks of vital statistics) and the corporate register (the
> secretaries of state).
There are some large countries which lack a civil register. I don't
think this will work.
> Stating this would make it clear that private addresses and
> non-qualified host names are prohibited, and non-public authority
> DNS-like root servers are also prohibited.
Huh? This is already extremely clear. It's just that CA practice
doesn't match. If the current rules are unenforceable, why should be
the new ones any different?
Kyle Hamilton
On Sun, Mar 27, 2011 at 11:51 AM, Eddy Nigg <eddy...@startcom.org> wrote:
>
> Some more possible information here:
>
> http://pastebin.com/74KXCaEZ
>
> Just got it from https://bugzilla.mozilla.org/show_bug.cgi?id=642395
...so this person, if I understand it correctly, is claiming that Comodo is using a username/password authentication system for its RAs.
Would this be legitimate basis for a Mozilla CA program requirement that all CA functions must be cryptographically authenticated?
-Kyle H
Eddy Nigg
> ....so this person, if I understand it correctly, is claiming that
>
> Would this be legitimate basis for a Mozilla CA program requirement
> that all CA functions must be cryptographically authenticated?
>
No - but the fact that domain control validation was not performed by
the CA is a serious problem. We've been there already...