Understanding the SSL security breach, preparing for the next one

Electronic Frontier Foundation staff technologist Peter Eckersley has a good, in-depth analysis of the revelation that Iranian hackers acquired fraudulent SSL certificates for Google, Yahoo, Mozilla and others by spoofing Comodo, a major Certificate Authority. CAs are companies that are allowed to sell cryptographically signed certificates that browsers use to verify their network connections; with these spoofed certs, the hackers could undetectably impersonate Yahoo and Google (allowing them to read mail even if it was being read over a secure connection), the Mozilla certificate would allow them to slip malicious spyware onto the computer of anyone installing a Firefox plugin.

It appears that the fraud was detected before any harm could be done, but Eckersley explains how close we came to a global security meltdown, and starts thinking about how we can prepare for a more successful attack in the future.

Most Certificate Authorities do good work. Some make mistakes occasionally,2 but that is normal in computer security. The real problem is a structural one: there are 1,500 CA certificates controlled by around 650 organizations,3 and every time you connect to an HTTPS webserver, or exchange email (POP/IMAP/SMTP) encrypted by TLS, you implicitly trust all of those certificate authorities!

What we need is a robust way to cross-check the good work that CAs currently do, to provide defense in depth and ensure (1) that a private key-compromise failure at a major CA does not lead to an Internet-wide cryptography meltdown and (2) that our software does not need to trust all of the CAs, for everything, all of the time.

For the time being, we will make just one remark about this. Many people have been touting DNSSEC PKI as a solution to the problem. While DNSSEC could be an improvement, we do not believe it is the right solution to the TLS security problem. One reason is that the DNS hierarchy is not trustworthy. Countries like the UAE and Tunisia control certificate authorities, and have a history of compromising their citizens' computer security. But these countries also control top-level DNS domains, and could control the DNSSEC entries for those ccTLDs. And the emergence of DNS manipulation by the US government also raises many concerns about whether DNSSEC will be reliable in the future.

Iranian hackers obtain fraudulent HTTPS certificates: How close to a Web security meltdown did we get?

• [bwcbwc]

  “3 and every time you connect to an HTTPS webserver, or exchange email (POP/IMAP/SMTP) encrypted by TLS, you implicitly trust all of those certificate authorities! ”

  Uhh, no — you only trust the certificate authority that issued the certificate for the site/service you are using. A while back I disabled trust for one certificate authority in my browser(was it Comodo, now that I think about it?) after it surfaced that one of their resellers was granting certificates without any authentication. A security professional managed to obtain a certificate for mozilla.com as I remember.

  Turns out Amazon uses that CA, which makes life interesting when I shop, but most SSL sites work just fine.

  –Update: found a reference @ http://www.sslshopper.com/article-ssl-certificate-for-mozilla.com-issued-without-validation.html

• [Ito Kagehisa]

  What we need is a robust way to cross-check the good work that CAs currently do,

  Well, there’s little enough of that.

  CAs are a racket. They have a history of behaving just like all other unregulated corporations; they are amoral and exist to maximize profit.

  Give a CA money and they will vouch for you. That is the totality of a CA’s function in the real world, they simply prove that you have money.

  • [Anonymous]

    I am bemused that your comment could also apply to the other CAs – Chartered Accountants.

• [Major Variola (ret)]

  Some cypherpunks have been observing this for years.
  You can’t sue a CA; they are intimately linked with
  governments (see Verisign, and in other countries,
  as noted).

  SSL lets you communicate confidentially by shouting in
  a room of strangers. But its a dark room, you don’t know
  who you’re talking to. A cert is just a note from someone
  you might —or might not— trust affirming your
  correspondant is who they claim. But if you don’t
  trust the CA… and actually, why should you?

  Even DNSSEC is just going to map names to IPs securely; any
  upstream router can fool you. That’s why you need crypto,
  the postman can be delivering your messages to a spook
  not Julian.

• [Anonymous]

  1. SSL certs, are supposed to secure communications, and
  2. prove identity
  3. Anything after that is extra.

  The CAs, are supposed to be trustworthy, and “unhackable,” if I had any business with Comodo I’d pull it today, and they would lose my business, and that would be the end of them.

  However, some time ago, months?, we decided to stop using them, if at all, because as other commenters pointed out, they sold SSL certs for $1.95, and there is no verification there, only proof of a $1.95 credit card transaction. Pointless.

  I get great customer service from our present provider, who still charges too much :) for running a key exchange party, but that’s the rules we play by now.

  If the CA also had to issue some kind of insurance / bond posting against this kind of behavior, who would pay? Collect?

  Lawyers are smiling…

  Comodo’s clear goal of grabbing money, make me think they would lack security…

  but then what can we think of RSA, etc.?

  But that there are no truly secure systems.

• [Anonymous]

  First, I dare anyone to prove that the average joe checking into email reviews, or even cares about the secure certificate. I would bet that most would say “what?” when asked if they were using a valid certificate. So when the author states that we implicitly trust those certificates, who is he/she including in the “we”?

  All this boils down to is the same thing it always boils down to: Everyone needs to be suspicious, always. Question everything. As a society today we spend too much time accepting. Saying “OK”. We, particularly we Americans, are primarily sheep, and we only react if we are guided to reacting.

  Two pennies.

• [Mike Scott]

  A pretty good fix against the failure of a single CA to maintain security would be to retool SSL/TLS to require two independent certificates from different CAs before a site is considered secure. That way, an attacker would have to compromise two different CAs simultaneously. It would put up costs slightly for site owners, but one can expect that certificate costs would fall if certificate providers suddenly had twice as much business.

• [jackwilliambell]

  What bothers me about stories like this is the fact these are skilled, but otherwise unremarkable criminals and terrorists. If they can accomplish this much, what are the abilities of similarly skilled operatives working for super-actors (like governments and large corporations) with extensive resources and the ability to subvert the underlying infrastructure?

  Taking over one cert authority is small potatoes to what you could accomplish if you could take over all the cert authorities *and* the top level name servers. If you could change the router tables. (Think for a moment about the recent events where internal U.S. traffic was routed through China, not once but several times.) If you had supercomputers designed expressly to crack RSA and SHA1. IF YOU HAD DESIGNED RSA AND SHA1.

  Frankly, I don’t trust the basic infrastructure of the Internet a great deal. Not because of black-hat hackers working in small groups so much as because of the super-actors with enormous resources and, in some cases, with legal authority for their actions.

  • [shadowfirebird]

    I agree, except where you imply that the government designed RSA.

    RSA was designed by Rivest, Shamir and Adleman.

    • [jackwilliambell]

      Oh… Whoops. You are right. I’m wrong. Heat of the moment, don’cha know? *cough*

• [Nadreck]

  What I found dismaying about all this was the complete lack of practical advice on what to do about this on your desktop. There seems to be an attitude that all you need to do is upgrade to the latest version of your browser, where the evil certificate ban is hardcoded, but what if you don’t feel like breaking your infrastructure with a new browser this morning?

  For example, both Firefox and Safari have, by default, default settings of “don’t bother” as far as Certificate Revocation Lists and OCSP servers go. Is the average user going to know how to extract the Comodo CRL URL from a certificate* to try to get a CRL with these evil certificates on them? Are they then going to notice that Comodo hasn’t issued a CRL since before the incident? What are the privacy implications of turning on OCSP wherein you ask someone’s server to comment on every certificate you use? In clear HTTP no less.

  A good place to start is the Keychain access preferences, certificate tab for Safari (your security settings are centrally set in OS X not in the imbedded browser) and Preferences – Advanced – Encryption – Revocation lists and Validation for Firefox. Speaking of the latter: if I decided to OCSP every certificate I have to choose a server from the list however only the Spanish CA at the top of the list has an OCSP URL automatically attached. For everything else, any URL that I enter, such as http://ocsp.verisign.com, just gets blanked out the next time I go to this preferences window. Say what?

  *Seemingly the only way to get this. Why isn’t this on the front page of every CA instead of being totally obscure?

• [shadowfirebird]

  Well, there you go. Don’t trust a central signing authority. (Unless you’ve exchanged keys with them at a party, of course.)

  That probably makes me sound like some sort of luddite. I don’t know whether central signing authorities are something that we can do without: but that doesn’t mean that we have to *trust* them.

  • [PaulR]

    Um, only if you’ve exchanged the keys early in the party.

    After a half a dozens drinks, any key you collect can’t be trusted.

• [shadowfirebird]

  ….oh, wait. Yes it does.

  The word “trust” has a very limited meaning in this context.

• [Oskar]

  I’ve always found this particular security issue a fascinating car-crash between security, economics, globalization and government control.

  Let me explain: obviously, the security of SSL is inversely proportional to the number of CA’s there are. The more CA’s, the higher the risk that someone will be able to compromise one of them and do all the man-in-the-middle attacks he wants. But on the other hand, these CA’s are all corporations, and basic economics tells us that we’d want as many as possible to ensure competition. Imagine if the only places to get these certificates were VeriSign and Thawte, the price to get them would be outrageous! One way to solve this problem would be to use some sort of government licensing system, but that seems almost anathema to the very idea of the internet. Compound that with the fact that the internet is a global enterprise, that exists outside of national boundaries, it gets even more complicated.

  In addition, the people who really decides whether or not a CA should be trusted is not a government entity or anything like it, it’s the browser manufacturers. Can we trust that they know what they’re doing? Currently, my copy of Firefox trusts a company called “Equifax”, which is apparently some sort of credit report company. It also trusts a number of Turkish CA’s. Can these companies be trusted? I don’t know, they probably can, but is Mozilla really doing the leg-work to make sure of it? Should the US government do that leg-work? Should the Turkish government? And can we really trust them? After all, it would be a really sweet thing for any intelligence agency to be able to break SSL whenever they wanted, which they could easily do if they had access to a universally trusted CA.

  All in all, this is a fascinating issue.