October 30, 2024

Mozilla Debates Whether to Trust Chinese CA

[Note our follow-up posts on this topic: Web Security Trust Models, and Web Certification Fail: Bad Assumptions Lead to Bad Technology]

Sometimes geeky technical details matter only to engineers. But sometimes a seemingly arcane technical decision exposes deep social or political divisions. A classic example is being debated within the Mozilla project now, as designers decide whether the Mozilla Firefox browser should trust a Chinese certification authority by default.

Here’s the technical background: When you browse to a secure website (typically at a URL starting with “https:”), your browser takes two special security precautions: it sets up a private, encrypted “channel” to the server, and it authenticates the server’s identity. The second step, authentication, is necessary because a secure channel is useless if you don’t know who is on the other end. Without authentication, you might be talking to an impostor.

Suppose you’re connecting to https://mail.google.com, to pick up your Gmail. To authenticate itself to you, the server will (1) do some fancy math to prove to you that it knows a certain encryption key, and (2) present you with a digital certificate (or “cert”) attesting that only Google knows that encryption key. The cert is created by a Certification Authority (“CA”), which asserts that it has done the necessary due diligence to establish that the designated encryption key is known only to Google Inc.

If the CA is competent and honest, then you can rely on the cert, and your connection will be secure. But a dishonest CA can trick you into talking to an impostor site, so you need to be cautious about which CAs you trust. Your browser comes preinstalled with a list of CAs whom it will trust. In principle you can change this list, but almost nobody does. So browser vendors effectively decide which CAs their users will trust.

With this background in mind, let’s unpack the Mozilla debate. What set off the debate was the addition of the China Internet Network Information Center (CNNIC) as a trusted CA in Firefox. CNNIC is not part of the Chinese government but many people assert that it would be willing to act in concert with the Chinese government.

To see why this is worrisome, let’s suppose, just for the sake of argument, that CNNIC were a puppet of the Chinese government. Then CNNIC’s status as a trusted CA would give it the technical power to let the Chinese government spy on its citizens’ “secure” web connections. If a Chinese citizen tried to make a secure connection to Gmail, their connection could be directed to an impostor Gmail site run by the Chinese government, and CNNIC could give the impostor a cert saying that the government impostor was the real Gmail site. The Chinese citizen would be fooled by the fake Gmail site (having no reason to suspect anything was wrong) and would happily enter his Gmail password into the impostor site, giving the Chinese government free run of the citizen’s email archive.

CNNIC’s defenders respond that any CA could do such a thing. If the problem is that CNNIC is too close to a government, what about the CAs already on the Firefox CA list that are governments? Isn’t CNNIC being singled out because it is Chinese? Doesn’t the country with the largest Internet population deserve at least one slot among the dozens of already trusted CAs? These are all good questions, even if they’re not the whole story.

Mozilla’s decision touches deep questions of fairness, trust, and institutional integrity that I won’t even pretend to address in this post. No single answer will be right for all users.

Part of the problem is that the underlying technical design is fragile. Any CA can certify to any user that any server owns any name, so the consequences of a misplaced trust decision are about as bad as they can be. It’s tempting to write this off as bonehead design, but in truth the available design options are all unattractive.

Comments

  1. Just a quick thing to add here regarding the neutrality of CNNIC. Just like any major Chinese company, NGO-type organisation, or government department: the management and significant board posts are allocated and administered directly via the central Beijing government.

    For example, if Beijing wanted the boss of Lenovo (Liu Chuanzhi) to be replaced it would be completely legally entitled to. As a major company in China, Lenovo have control network connections with the central government. That doesn’t mean the central government control them, but they can do if they want to, and in particular they can call the shots in anything Lenovo, or in this case CNNIC, do, and as long as they do so with people with too much to lose (execution, imprisonment, or even just making sure family members have a tough time in doing business), they will influence that power with any company operating in China.

  2. I think the Mozilla policy *requires* that the CA doesn’t ask you your private key for SSL server cert issuance (If it doesn’t, I’ll report it when needed. I don’t believe any CA would go through the review process if it’s written somewhere it may ask the private key when issuing a server cert).

    The only CAs that require the private key are private CA, when issuing encryption certificates, as a disaster recovery option, so that you’ll be able to recover of encrypted data after having lost your private encryption key. But never for a signature key. And never for a SSL server key.

  3. Preston L. Bannister says

    Notably, the starting point of this debate appears to be the objection of a Chinese citizen.
    https://bugzilla.mozilla.org/show_bug.cgi?id=476766#c18

    The policy debate at Mozilla.
    http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/17be3bd7e0b33e8c#

    CNNIC is in Mozilla’s list of included certificates.
    http://www.mozilla.org/projects/security/certs/included/#CNNIC

    For shame – an academic that did not cite sources! 🙂

  4. The whole system of using x509 for https is the problem.

    If you have the time to read something in-depth, I suggest checking out this article:

    http://lair.fifthhorseman.net/~dkg/tls-centralization/

  5. Don’t trust the Chinese goverment please please. It is very very EVIL.

  6. Last time I requested a certificate for my company, I created the couple private/public key, then I requested a certificate to the CA by sending him the public key but not the private key. I had to prove that I own the associated private key of course (by sending them a specific random message encrypted with it).

    So even if the CA is corrupted that didn’t lower the security of my connection, as they don’t know my private key.

    What should be ensured is that an approved CA allows this process. Not all work like this.

    • John Millington says

      “So even if the CA is corrupted that didn’t lower the security of my connection, as they don’t know my private key.”

      The danger posed by a corrupt CA isn’t that your private key may be compromised. It’s that they’re positioned to help with a Man in the Middle attack, where people who want your public key can be given someone else’s public key instead, and believe that it’s yours. It’s not your CA that poses the danger; it’s any CA that the user trusts. A corrupt trusted CA taints the whole system, not just the people they certify.

  7. Curt Sampson says

    Actually, Ed, the certificate authority does not “[attest] that only [emphasis mine] Google knows that encryption key.” They merely attest that Google knows it, without indicating whether anybody else does or not.

    This is more than a slight technicality, because you it changes your point of view when using a secure site. You have to consider not only how much you trust the certificate authority that signed the site’s certificate, but how much you trust the site itself to maintain proper security. If an attacker gets hold of a site’s private key, they can then impersonate the site.

    • You’re right, “only” is inaccurate. I thought about this when writing the post, and decided to leave it in anyway, to simplify the explanation.

      As you point out, the CA just certifies that the site knows the key. Everyone assumes that the site would not reveal its private key to anyone else, but this is just an assumption and is not enforced by any technology. In practice the assumption is usually right.

      How exactly this changes the point of view is a bit subtle. It’s worth thinking through if you want to understand the situation fully, but I decided not to try to walk readers through that analysis, so I could get to my main point more quickly.

      Such are the challenges of trying to write a short, accessible summary of a challenging topic.

      • “In practice the assumption is usually right.”

        Furthermore, in practice, if you use mission-critical secure connections to a site, and that site is root-compromised, you’re hosed anyway.

  8. Dan Kaminsky says

    Do you really think that China’s only now getting a “god mode” certificate?

    Go research GeoRoot, or any of the other “we’ll sell you a full intermediate if you promise to be nice” offerings.

    • Indeed, Entrust apparently gave CNNIC their own CA cert awhile back (although I can no longer find it in the keystore of new Firefox distributions even if it is still active):
      https://bugzilla.mozilla.org/show_bug.cgi?id=476766#c36
      http://www.imminentweb.com/technologies/screenshot-remove-cnnic-firefox-and-thunderbird

      The difference here is that Mozilla is actually in a position to make the call directly. These recent events may not make a huge difference practically, but they are happening in a much more public forum.

      • Here’s the cert issued by Entrust. It can only be used to verify end entity certificates. That’s one thing that will change with the inclusion of the CNNIC trust anchor.

        —–BEGIN CERTIFICATE—–
        MIIEFzCCA4CgAwIBAgIEQoeioDANBgkqhkiG9w0BAQUFADCBwzELMAkGA1UEBhMC
        VVMxFDASBgNVBAoTC0VudHJ1c3QubmV0MTswOQYDVQQLEzJ3d3cuZW50cnVzdC5u
        ZXQvQ1BTIGluY29ycC4gYnkgcmVmLiAobGltaXRzIGxpYWIuKTElMCMGA1UECxMc
        KGMpIDE5OTkgRW50cnVzdC5uZXQgTGltaXRlZDE6MDgGA1UEAxMxRW50cnVzdC5u
        ZXQgU2VjdXJlIFNlcnZlciBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzA1
        MTExNDAzMjJaFw0xMjAzMDEwNTAwMDBaMDUxCzAJBgNVBAYTAkNOMRIwEAYDVQQK
        EwlDTk5JQyBTU0wxEjAQBgNVBAMTCUNOTklDIFNTTDCCASIwDQYJKoZIhvcNAQEB
        BQADggEPADCCAQoCggEBAJi/7qMONmdodRqKb5QMZM8XaQLXy26EjTnBblL+WC1y
        PGXxTFyYSjrJKB3iUKP1Inj9dymNfQqD0F0p/aWh6RClHb/NoAwR2zjIf8xrStVO
        eUCieuDz5l7TVKZ/aklW/UcIzImj9SjRzixzJ0Qdd7L0SW11WgzUd/IEqHHy2DHq
        3qJC3qUnfkWLmmPlE7QUJ4cg62kFwZ2vznHb9tlwGEPd2ik4iACBUL8X17x4BV//
        DeOl1z75DpDMLjmUTi/vwmsc/1Ko9ElwrfkjF4L7XY/hbQ/N/qmhMMn8OBiIwbTI
        14oRS/8eiUqTe0L0KwrC+Yo96HBTBRObAZWgV/X0ZxkCAwEAAaOCAR8wggEbMA4G
        A1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMDMGCCsGAQUFBwEBBCcw
        JTAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AuZW50cnVzdC5uZXQwMwYDVR0fBCww
        KjAooCagJIYiaHR0cDovL2NybC5lbnRydXN0Lm5ldC9zZXJ2ZXIxLmNybDARBgNV
        HSAECjAIMAYGBFUdIAAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMB8G
        A1UdIwQYMBaAFPAXYhNVPbP/CgBr+1CEl/PtYtAaMB0GA1UdDgQWBBRL1eFRFqKn
        7aOlx+D/sYcYDsDj1TAZBgkqhkiG9n0HQQAEDDAKGwRWNy4xAwIAgTANBgkqhkiG
        9w0BAQUFAAOBgQBE8Wd1YSChOVKq/nmol4vS1BFliayedJBiTW9EfeyCtfPvCb9m
        RjpT2+k4P2y9xJSFOB7Z9FsvcjMwqUWdf9qDMWqm4QXddxlztDtZ6PZiSvZ3H+mX
        iWa/mCLLmFhoTElB/XYY4aqg/smxWaVJzHcbcP0ED5PeCxQiFpgbHeRVig==
        —–END CERTIFICATE—–

  9. No mention that all of the other browsers already include the CNNIC root certificate? Really? Really!?

  10. ” Summary:

    Perspectives is a new approach to help clients securely identify Internet servers in order to avoid “man-in-the-middle” attacks. Perspectives is simple and cheap compared to existing approaches because it automatically builds a robust database of network identities using lightweight network probing by “network notaries” located in multiple vantage points across the Internet. ”

    http://www.cs.cmu.edu/~perspectives/

  11. What we are seeing is the Balkanization of the Internet. The CA scheme is a relic of a bygone era when web browser designer thought that all top level domains could be trusted. It is a pretty thought representing a more innocent age.

    In October 24, 2003 the Number Resource Organization (NRO) came into existence as part of the trend break up US dominated control of the Internet IP space into the Regional Internet Registries (RIRs) specifically ARIN, RIPE NCC, APNIC, LANIC, and AfriNIC. Trust is not geographic. It has never been. I am in fact more likely to distrust an entity closer to me geographically than one further removed e.g. all politics is local.

    On June 12th, 2007 Extended Validation (EV) SSL Certificates arrived on the scene. All part of an increasing effort to validate a decreasing number of characters that make up uniform resource locators (URLs).

    The truth is that X509 certificates are mess. Most of the fields are in practice meaningless to end users. The browser has no concept of displaying the associated root authority as part of the UI. No one has designed a web browser UI that considers the fact that a web server might need to offer up multiple server certificates from multiple authorities. The user is the person most able to make decision of regional trust. When I go to the local Department of Motor Vehicles (DMV) to get a license I readily need several forms of identification. There is not technical equivalent for the browser.

    There is this massive rush to figure out the Chinese syndrome. In the Internet we thought we finally defended freedom and privacy and became more secure from lawful intercept technologies that are part and parcel of the phone system. Now, we are discovering the consequences are attacks on the integrity of mechanisms by underlying the Internet.

  12. Given the past failures of Verisign and the complicity of U.S. telecommunications companies in the illegal, warrantless wiretapping of the last few years, we have as much empirical evidence for distrusting private CAs operating in the USA as we have for distrusting CNNIC.

    Implementing name-based or region-based constraints on CAs may protect us from attacks by the Chinese government, but it won’t protect us against western CAs and governments, which have already demonstrated their untrustworthiness. Constraint-based solutions won’t protect Chinese citizens, either. Any solution western developers adopt should protect all netizens, not just ourselves.

    Requiring certificates from multiple CAs could provide many benefits:
    – Make it more difficult for governments (ours or China’s) to spy on citizens
    – Limit damage from CA errors (i.e. Verisign’s bogus microsoft.com cert)
    – Mitigate SSL/CA bugs (e.g. NUL-byte handling bugs)

    The downsides are pretty minimal:
    – Financial cost to web sites. Back when certs cost hundreds of dollars, this may have been a valid point, but it’s just not an issue any more.
    – Computational cost. The only additional computation is that the client has to verify multiple signatures, but signature verifications are cheap.
    – Bandwidth costs. Not sure if these would be significant, but I doubt it.

  13. Peter Gutmann says

    At the moment malware authors can buy certs for pretty much anything off pretty much any CA using stolen credit cards (or at least find a less diligent CA and go to them on the off chance that a more diligent CA refuses to sell them a cert for, say, Microsoft’s live.com, or mozilla.org, or whatever). Why would having a Chinese CA that’ll issue who-knows-what certs be any worse than the current situation of non-Chinese CAs who’ll issue who-knows-what certs? We’ve already got the Russian mafia buying their own certs, how much worse will it be with the Chinese playing as well?

    It seems that the principal effect of allowing CNNIC in is to point out just how broken the practice of universal implicit cross-certification is, which doesn’t seem like a bad thing to me.

  14. After reading about the discussion for some time it struck me that perhaps we are approaching the problem from the wrong angle.

    It seems that people are very divided with respect to which CAs (Chinese, etc.) or which kind of CAs (government, close-to-government, non-government) can or deserve to be trusted. But this is the fundamental issue here: trust is a choice, and we should treat it as such. Instead of pushing a better solution on all users, we should push more users to make a better choice.

    The fundamental problem with the CA list shipped with Mozilla and other browsers is that nobody modifies it. In fact, hardly anyone knows even about its existence. Perhaps this needs to be addressed. Let’s give the user a choice of a few basic trust policies (“trust only CAs operating in my country”, “trust major commercial CAs”, “distrust CAs based in these countries” etc.), and let’s make this a part of the basic setup, not an arcane setting hidden deep in the bowels of configuration menus?

  15. The Internet is insecure, period. Sure, you can try to make it better with DNS security, Certificate Authorities, SSL, etc but in the end, you connect to a public untrusted network through a connection delivered to you and managed by a 3rd party…how can you ever have a realistic expectation of privacy?

    That being said, the Mozilla team should by default allow Chinese users to trust a Chinese CA by default. They choose to live in China. They choose to be monitored. Let them feel the repurcussions. It’s not up to Mozilla to tell the Chinese how to behave in China.

    As far as the rest of the world, set it to not trusted by default. If someone really wants to visit a site that uses a Chinese CA, then they have the option to, otherwise if a Chinese site wants to make itself more appealing, it should purchase a cert from an internationally respected CA. Not that any of this will matter. The Chinese government can intercept the transmission, break the encryption and read the contents as it passes through the routing equipment.

    Getting back to my original point, if you’re worried about the Chinese government monitoring your communications, don’t send your traffic through a Chinese network. For users in China, purchase satellite communications equipment and bypass the firewall.

    -Sean

    • Have you talked to anyone who has tried not to live in China? It’s kind of difficult. Saying they chose to live in China just isn’t respecting the people that live there.

  16. Then why not toss out the CAs of any party, and not just a government, that has proven untrustworthy in some way. Like, oh, network solutions, or verisign. Personally I see no reason at all to trust them other than the sheer market share they have.

    Or aol, or any of the CAs that are sat on by companies I haven’t even heard of. What are they doing in my browser? They’re convenient and allow me to forego thinking in hopes of not being scammed. Meaning that there’s a far more fundamental problem here, and that is that trusting trust anchors because it is convenient is snake oil, and thus detrimental to trust. But that leaves us with a big large inconvenient hole of what to do next.

    Not unsurprising that the ‘standard American solution’ so far has been to just sit back and accept root CAs from various commercial parties. But that only protects you from parties those commerical root CAs don’t take money from. Very secure, no?

    My point? Trust is too much an individual decision, even when overriden by some state (and not all of the state certs in the store are china!), to have global “good enough” defaults. So, they must go. All of them. Yes, All Of Them.

    If that breaks the business model of the scum at verisign et al., well, cry me a river. If we keep them around we’re ignoring the real problem and therefore won’t have real trust. China is small fry by comparison.

  17. This is why we need domain restrictions on certificates! Restrict the US CA’s to US domains, and the Chinese CA(s) to Chinese domains!

    https://bugzilla.mozilla.org/show_bug.cgi?id=501697

  18. The addition of CNNIC to the trusted CA list might be a good time to raise awareness, but the whole CA system can be abused easily. To obtain an illegitimate certificate one only has to convince (coerce) one single CA to provide that certificate (and all sessions with the trojaned webserver will show up as genuine in all webbrowsers. Do you want “green” validation, that can be arranged too!) “Wildcard certificates” are great value for someone who wants to abuse the system.

    What options are there to coerce a certificate (from any CA):
    Government pressure on the company
    Undercover government agents
    Bribery
    Other criminal pressure (kidnapping of children, …)

    The cynical me says that the illegitimate options are far more than the legitimate. But how do we “fix the system”, that’s the $1000000 question!

  19. This may be a trivial remark, but I think it is presumed that in a “functioning” democracy with rule of law and separation of powers that provide checks and balances on the dealings of individuals and groups, institutions (including government agencies) are by and large not corrupted by government influence, or influence by individual power brokers in government. The US and most Western nations are held to be of that description while China is not. Now, for how much corporate entities are subject to those principles *and their enforcement* …

  20. I’ve never understood why the installation process, or the first run of a newly installed browser doesn’t just give the user the options. Going through the process of trusting the DoD CAs every time I want to install a new browser, reformat my hard drive, or use a new computer is unnecessarily time consuming. Let me as the user decide which CAs I want to trust. Set CNNIC and DoD as untrusted by default, but please make it just a checkbox. And point the users to it the first time they run the browser.

    • Robert O'Callahan says

      It’s not a good idea to ask users questions they have no way to answer.

      • Well, you could guide user responses with default settings. A list of checkboxes, with some checked by default and others unchecked by default, would be a huge improvement.

        Asking users questions they have no way to answer is bad, but answering the questions for them without consulting the user is probably worse.

      • Many Chinese would not care, or for nationalistic or convenience reasons, would like to go with the Chinese version. But I have a Chinese programmer friend, for example, who rarely visits Chinese websites and is quite distrustful. Probably not unlike how Westerners may trust or distrust their government.

        I think if at least the origin of the country was made clear, and a good explanation given of what it means (as this article did)–maybe with further details in an expanded “Explain more” box along with a friendly default indication of “Just choose it for me”, and for the sake of public sites, the ability to discern which authority is currently active, it could be the best compromise–in line with Firefox’s tradition of offering choice. If a choice is given, it could also promote awareness so that more people know that Firefox has these options built-in.

      • John Millington says

        the “experts” have no way to answer it either.

  21. What does that buy you? The problem is that there’s no way to impose meaningful limits on trust anchors.

  22. The laws governing a CA should be taken into account when deciding whether to use them. That should be formalized.

  23. China is no friend of the internet. Firefox shouldn’t trust them.

    How about only the chinese version of firefox trusts chinese CA’s by default?

    • The CA trust issue is most important for Chinese users, so that wouldn’t help.

      • couldn’t the chinese government right now just create its own firefox , add any cert it wants and send it to users when they request for a firefox-install.exe download from inside the great firewall ?

        • They could, but they don’t. If they did, it would be immediately noticed and it would be all over the tech news.

  24. I think what Ed is hinting at via this media-hot Chinese issue is the trust we place in powerful institutions, like banks and governments, can fall victim to the revolving door relationships amongst such “pillars of the golden rule” and move down the path of authoritarianism. Wouldn’t be the first time…

    That becomes an especially intriguing dichotomy given the populist image of the Internet as a democratizing force.

  25. Perhaps I get the technicalities wrong, but wouldn’t a lot be won if the browser wouldn’t just check with one CA but serverals?

  26. See Kaminsky’s talk at 26c3.
    This whole article is really missing a lot of critical information. For example, where does the mail.google.com in the example come from? DNS. So, the real issue here is DNS and we need DNSSEC since there is simply no way to ‘fix’ the CAs.

    The least competent assurer that still has a valid root cert in the major browsers is the de facto security level for all. It doesn’t have to be as blatant as China taking over all SSL connections they are interested in, it’s enough to trick a sloppy CA into issuing you a cert you shouldn’t have.

    • This post doesn’t try to be comprehensive. The goal is to introduce the issue in a way that is accessible to non-experts, in a post of limited length. Discussion of design alternatives such as using DNSSEC, and other drawbacks of the status quo, will have to wait for another post.

    • Even if DNSSEC was enabled what would prevent China from rerouting the IP address itself? They already have their great firewall.

  27. John Millington says

    “Any CA can certify to any user that any server owns any name, so the consequences of a misplaced trust decision are about as bad as they can be. It’s tempting to write this off as bonehead design, but in truth the available design options are all unattractive.”

    Set CNNIC (and most other CAs) by default to moderately trusted. Require a conspiracy of n CAs. Ok, so that makes it a little harder for some people (they now have to get certified by multiple parties instead of one) but maybe that’s not such a bad thing. We don’t know if we can trust CNNIC but we never really knew Verisign very well either.

    Oh wait, we didn’t use OpenPGP for authentication on the web? Oops. When https appeared in the mid-1990s we already knew we were doing it wrong, that you can never be sure about how much to trust a total stranger, that there are shades of gray, and that conspiracies are fairly difficult to orchestrate.

    The totally-trust-’em-or-don’t-trust-’em-at-all approach was obsolete from the day https appeared. So: what should the Mozilla team do? Don’t worry so much about how to fit CNNIC into the x.509 model (just flip a coin or something), and have the next build of Firefox support OpenPGP certs, so that people can start upgrading to a modern (and by that I mean 1990-era) more flexible trust model.

    • Daniel Kahn Gillmor says

      You might be interested in the monkeysphere project. While we’re currently supporting OpenPGP as a PKI for ssh connections, HTTPS (and other TLS) certification review via OpenPGP is in the works.

      Our current approach is to leave the TLS session unchanged, but to treat the certificate simply as a carrier for the RSA public key, which is then looked up (along with the desired host/service information) in the OpenPGP keyserver pool.

  28. In firefox, when I go to any US military affiliated https site in .mil the browser always complains that it’s untrusted, so am I right in thinking the Mozilla team trusts China more than the USG?

  29. Fully disagree with “the available design options are all unattractive”. There’s no particular reason why trust anchors should be unconstrained (or only constrained using key usage constraints that don’t align with the way folks operate CAs). Similar mechanisms could be used for trust anchors as are used in certificates, i.e., name constraints, etc.

    • But what do you propose? One could introduce domain-based Name Constraints on a given CA — something that is already supported in x.509 (RFC 3280 section 4.2.1.11). However, CA’s are not necessarily organized by domain. Indeed, even though CNNIC in this case happens to be the registrar for .cn, there are reasons why you would want to allow .cn domains to use other CAs or vice-versa.

      One could certainly introduce any number of constraints, but you would need some way for rationalizing those decisions. It’s not clear what such a system would be.

      • For enterprise scenarios, it would be fairly straightforward. Trust anchors could be constrained using mechanisms that are included in cross certificates today. Trust is established between enterprises currently in one of three ways: by installing a partner’s root certificate as a trust anchor, by issuing a certificate to a partner’s root or via a bridge CA. The trust anchor approach is the only one of the three that lacks a constraints mechanism.

        For the Internet at large, it is trickier and I may agree that the available options are not attractive. They may be more attractive than nothing at all though. Name constraints could work if initialized when a site was first visited, for example.

        • Just get the browser to remember certs it encounters and have it warn the user when:
          1) The site’s cert’s CA has changed (default mode)
          2) The site’s cert has changed rather early (cautious mode)
          3) The site’s cert has changed (paranoid mode, or when the user has told the browser to do so for that particular site).

          This will help the users that do care about security. You don’t really need to care about the security of the users who click through browser warnings- they can usually be easily “pwned” in other ways. Flash, pdf, dancing bunnies/pigs, etc.

          This has been a known problem for years. The way things are, self signed certs can be safer since you can control the first encounter with the cert. Whereas CA signed certs could be switched at any time without you being warned.

          The Mozilla team should just fix their browser first and do the debating later.

          • There’s a bug filed for this 5 years ago:

            https://bugzilla.mozilla.org/show_bug.cgi?id=286107

            As for the concern there about “same site, different CAs”, I’m sure the browser can handle by warning the user for each new CA+cert for that site (if you get lots of new CA warnings you SHOULD get suspicious and not do any important transactions).

            The fact is, all that fancy CA and browser stuff is less about security and more as a way for CAs to collect “protection money” just so users don’t have to get those scary warnings.

            CAs have mis-signed certs before (Verisign being a notorious example), and they will in the future. And the browser makers have done NOTHING to protect users against that.

          • It’s not just a browser problem.

      • If I understand correctly Dan Kaminsky is advocating for the use of DNSSEC to solve the problems with CAs.

        http://it.slashdot.org/article.pl?sid=09/06/25/1354212

        • Daniel Bernstein has pointed out some of the inherent flaws in DNSSEC in his presentation “Breaking DNSSEC”. DNSSEC may solve a problem with CAs, but not without introducing other major problems.

          http://cr.yp.to/talks/2009.08.10/slides.pdf

          • Dan Kaminsky says

            Bernstein’s brilliant, but that presentation is by no means his best work. (I’m being kind.)

            DNSSEC has some serious issues but they’re not where Bernstein thinks. Luckily they’re all things that be dealt with, once the root is signed (and, to a lesser extent, com gets on board).

      • A “social media” approach might have people cross checking public keys using “out of band” approaches.

        If google’s certificate looks different when I am talking to my friend that works at google than when I use gmail, I have a problem I need to fix, and when I have found and identified my problem I would have news that would interest my friends.