Comodo Registration Authority compromised

March 24, 2011 8:05 PM

The circumstantial evidence suggests that the attack originated in Iran. Every time you see a little lock icon in your browser and are using HTTPS connections, odds are you're using a site whose certificate was signed by an Certificate Authority like VeriSign, Comodo, or Thawte. This week, SSL certificate provider Comodo announced that one of its accounts had been compromised. The attacker used the account to generate 9 bogus certificates to use for 7 well-known domains. While the breach was discovered and the certificates were revoked, it does raise questions about the chain of trust for all SSL certificates.

The sites that the attacker created false IDs for were main internet hubs like Google, Yahoo, Skype, and Live. As Comodo posted in their blog: It does not escape notice that the domains targeted would be of greatest use to a government attempting surveillance of Internet use by dissident groups. The attack comes at a time when many countries in North Africa and the Gulf region are facing popular protests and many commentators have identified the Internet and in particular social networking sites as a major organizing tool for the protests.

posted by fifteen schnitzengruben is my limit (49 comments total)

This story has been blowing up over the last day or so. It's a pretty big deal. I liked the F-Secure writeup on this for a quick primer. It's been a bad week for security - first the RSA breach and now this.
posted by gemmy at 8:15 PM on March 24, 2011 [1 favorite]

I was just about to ask IT to switch our certs to Comodo and use the savings for a wildcard certificate. So much for that plan.
posted by furtive at 8:34 PM on March 24, 2011

I hate seeing stories like this and realizing that there's probably nothing I can do to minimize any risks from a security breach, except keep my software updated (which I do anyway).
posted by immlass at 8:39 PM on March 24, 2011

I don't know how this story developed, furtive, but Comodo's apparent openness in describing what happened makes me trust them more than a company which might know there was a breach but be as close-mouthed as possible about it.
posted by hattifattener at 8:44 PM on March 24, 2011 [8 favorites]

... there's probably nothing I can do to minimize any risks from a security breach, except keep my software updated (which I do anyway).

Events like this give you just a taste of why smartphones with non-upgradeable firmwares are so terrible, yeah.
posted by mhoye at 8:46 PM on March 24, 2011

Is there a good overview of SSL certificates? I'm realizing I put a lot of trust in my browser's lock icon--but know very little about it.
posted by rockstar at 8:47 PM on March 24, 2011

Is Comodo going to lose business for this? I have no idea what this sector looks like.
posted by grobstein at 8:49 PM on March 24, 2011

I haven't yet read the links, but the Ars writeup is pretty comprehensive and accessible to non-technical folk.
posted by Ickster at 8:52 PM on March 24, 2011 [3 favorites]

Wow, crazy. Somehow I missed hearing about this until now. Not a good week to be a security expert :/

I thought a quote in that last link was interesting: "SSL in practice only provides transport encryption -- it does not provide any meaningful authentication of the user and only minimal authentication of the server. It has always been way overhyped..." Might not be news to most people here, but I'm sure many in the general public would be surprised to learn how un-secure "secure" sites really are.

rockstar - lots of info out there, but here's a rather simple explanation of SSL I found that might help.
posted by photo guy at 8:54 PM on March 24, 2011

I think that if you are getting a few hundred dollars a pop to generate text files, you should be able to afford to hire people who, upon receiving a certificate signing request from Google, have the wherewithal to say, "hmm, wonner if this is legit"
posted by bendybendy at 8:54 PM on March 24, 2011 [6 favorites]

"SSL in practice only provides transport encryption -- it does not provide any meaningful authentication of the user and only minimal authentication of the server. It has always been way overhyped..."

I think that most people administering servers requiring SSL realized long ago that the use of certificates for identification based on a chain of trust just doesn't work unless you're a large company that's 100% in control of its own certificate solution. If you're not, then the identity side of certs is just a pain in the ass. Self-signed certificates are perfectly good for providing the transport encryption, but because browser makers bought into CAs as public entities, I can't set up an SSL secured site without paying a 3rd party for a certificate of dubious additional value.
posted by fatbird at 9:04 PM on March 24, 2011 [3 favorites]

False IDs, false certificates... false flag?
posted by grounded at 9:10 PM on March 24, 2011 [2 favorites]

I had an important account compromised this week and have been banging my head against the wall trying to figure out how it happened. Maybe this explains it.
posted by haroon at 9:35 PM on March 24, 2011

I'm surprised how easy it is to get SSL certs nowadays from services like StartSSL -- which is great, because I agree that many if not most online services should have SSL as an option if not by default.

But one of the problems is that a $12.99 cert you get from GoDaddy carries similar weight to a $400 cert you'd get from Verisign/Symantec, at least from a user's perspective. The latter is a Class 3 cert, which includes verification information about the organization assigned to the cert, and displays a little "Twitter, Inc" field (or what-have-you) in the URL bar.

But the cheap certs are Class 1, which don't have any verification information, and don't show the company name -- but users won't really know the difference unless they look. I think on Firefox the Class 3 certs are green vs. blue.

It's hard to make a centralized system scale, and I think we're starting to see the strain. I haven't looked at any of the distributed trust systems mentioned in Jacob Applebaum's post, but it's important to consider these things, especially since we've discovered that DNS (also centralized) has inherent flaws.
posted by RobotVoodooPower at 9:36 PM on March 24, 2011

Self-signed certificates are perfectly good for providing the transport encryption

Only in the case of a purely-passive eavesdropper (in which case you can just use something like ephemeral D-H and not bother with a certificate at all).
posted by hattifattener at 9:37 PM on March 24, 2011 [1 favorite]

Might not be news to most people here, but I'm sure many in the general public would be surprised to learn how un-secure "secure" sites really are.

Explain?

SSL + most banks/Google/Facebook/e-commerce sites are perfectly secure. Or do you know about some massive security loophole that no one else does?
posted by bkudria at 9:42 PM on March 24, 2011 [1 favorite]

Only in the case of a purely-passive eavesdropper

It's a fair point to observe that self-signed certs are defenseless against man-in-the-middle attacks, but having trained users to click 'yes' through scary security warnings, I'm not certain that trusted certs really foil them much either, even leaving aside the substantive content of the OP.
posted by fatbird at 9:43 PM on March 24, 2011 [1 favorite]

Is there a good overview of SSL certificates?

Well, in a quick-and-dirty description, SSL relies on public-key cryptography. What that means is that each key is split into two parts, a public and a private key. The public key can be freely shared with anyone; the private key needs to kept secret.

The way it works is that each half of the certificate can be used as a mathematical key to encrypt things so that only the other half of the cert can decrypt it again. With, say, email, you'd encrypt your email using someone's public key, and then only their private key could decrypt it again. (even you, the sender, can't decrypt it once it's encrypted -- if you don't save the original, it's as impossible for you to read as anyone else.)

They can also be used to 'sign' a document. That is, they take the document, compute a checksum, and then encrypt that checksum with the private key. The public key can then verify that the signature is valid, and that the file wasn't corrupted or deliberately changed. This feature is what makes SSL certs go.

Browser makers build in a bunch of public keys for various root authorities, scattered around the Net. As people buy certificates, they pay to have them signed by the private keys of these root authorities. In theory, the root authorities are supposed to validate that they're who they say they are.

Server operators load the signed key or keys into their web server, which presents it to you when you connect. The browser does some simple verification that the certificate is meant to be used for the site you thought you were connecting to, that everything looks valid for a fairly loose definition of valid, and then checks the signature with its built-in public key database. If the certificate has been signed by an entity the browser trusts, an encrypted session is set up, and all further traffic is encrypted using that website's key. If something doesn't check out, and you get an error, you can add a manual override to trust that site's key, but that's something you want to be really careful about. It means that something is broken in the trust chain, and you may not be talking with who you think you are.

What's happened here is that someone broke into Comodo's systems, and apparently used their private key hardware to generate some new certificates. (this is all normally done in tamper-proof hardware, with hardware logging; these companies are paranoid as hell, and rightfully so. Even though they've been compromised, that paranoia let them detect the compromise and even the precise certificates that were generated.)

With those signed certificates in hand, bad guys can set up a 'man in the middle' attack on any site that matches the names they generated. You try to connect to Facebook, but the bad guys either redirect the DNS, or put a physical computer in between you and them. You start talking with the evil server, which can now present a certificate that looks completely, absolutely legitimate, because it [b]is[/b], at least mathematically. Then the evil server sets up a separate connection to Facebook, and forwards everything back and forth between the two of you. You think you're on an encrypted session to Facebook; Facebook thinks the evil server is you logging in. So you use the site normally, and everything looks fine, except you've been wiretapped -- everything between you and them is logged as cleartext by the evil proxy server.

The way to fix this is to revoke the compromised certificates in the various browsers. Firefox just released an 3.5 update that fixes the problem, and apparently 4.0 is already immune, for whatever reason. Microsoft has a hotfix on their website. I'm not sure what Google is doing with Chrome, but they probably have an update out too.

Once the root certificates are revoked, your web browser will correctly warn you that the evil certificates are no longer trusted. However, it will give you the same warning for EVERY certificate that was signed with the compromised key, so Comodo will be scrambling like hell to issue new signatures for its customers.

If you get SSL certificate errors in the next couple of weeks, I'd suggest not trusting the site. Just give up on that site for that session. It'll most likely just be someone who hasn't gotten a certificate reissued yet. But it could also be the bad guys.
posted by Malor at 9:46 PM on March 24, 2011 [11 favorites]

> Or do you know about some massive security loophole that no one else does?

These are a list of all trusted root CA's that are installed by default in Windows 7. While Comodo is a big one, notice there are a few smaller CA's in there as well.

In theory, an SSL certificate issued by any of these authorities would show up as valid on your webbrowser, with the little Lock icon as well.

While going after Comodo (through what looks like a reseller affiliate in the EU) is big bucks, if you wanted other valid certificates you could go through one of these other small CA's as well.

As for the robustness of SSL itself, you can buy firewalls with real time SSL decryption. My friends office has one in place, all their managed windows machines have an additional trusted root CA that validates all SSL certs generated by their firewall. It is an auto real time man in the middle attack that they use for logging all incoming and outgoing traffic to their office building. If you checked the certificate chain for mail.google.com while in their office on one of their computers, you would see that it was signed by their router, and not by verisign, and your browser would be OK with that.
posted by mrzarquon at 9:55 PM on March 24, 2011

Malor-

I don't believe they are revoking Comodo's root certificates (ie, don't trust anything signed by this certificate anymore), they know the hash's of the 9 certificates that were issues, so they have been blacklisted.

Granted if this is rumored to be something in Iran, and to help with eavesdropping on their already compromised internet connection (if it is all state controlled) then they can block access to the update servers and prevent people from getting this revocation patch.

I've seen modern browsers (Chrome, IE8, Safari) actually report certificates as revoked already without an update, just in testing I ended up putting in an old ssl cert after generating a newer one for the same domain, and the old certificate was kicked back as revoked after an hour or so.
posted by mrzarquon at 10:00 PM on March 24, 2011

(more on the revocation process and the really nitty gritty stuff here)
posted by mrzarquon at 10:03 PM on March 24, 2011

Not the first time a Comodo reseller's lack of security has allowed someone to obtain an illegitimate cert for mozilla.com.
posted by JiBB at 10:13 PM on March 24, 2011

> Explain? SSL + most banks/Google/Facebook/e-commerce sites are perfectly secure. Or do you know about some massive security loophole that no one else does?

There is a lot to explain. Some good links in this thread. I don't understand all of it, but might be able to help.

"perfectly secure" is a phrase to describe a theoretical system, not anything that has ever existed or will ever exist, "secure enough" might be a more useful phrase.

The basic threat is a Man-in-the-middle (MiTM) threat, where a bad guy has access to the communication channel and can intercept and inject traffic between you and the computer you are trying to connect to (all banks/google/facebook/e-commerce sites).

While your session may be encrypted, an attacker could intercept your attempt to start a secure session, and instead establish a secure a session with the bad guy. The bad guy would at the same time establish a session to your attempted destination.

TLS (TLS is what we technically generally use instead of SSL) authentication (to re-assure you that you really are talking with your bank, and not a bad guy pretending to be your bank) is managed by your browser, which has a list of trusted Certificate Authorities (CA) that are supposed to confirm the identity of a party to some degree before issuing them a certificate that confirms identity (think of a CA as a DMV). That list is over 100 long in some contexts; there are 100 DMV's. From different countries (any government could compel a CA to generate a certificate to conduct surveillance).

In this case, one of the multitude of certificate authorities detected they had erroneously allowed a set of potentially very dangerous certificates to be issued. Certs that could be used for MiTM attacks.

As for massive security holes, there are a lot of threats that few people understand; and while some of the threats are theoretical there is a long history of folks making the theoretical practical.

I do commend Comodo for being quick to respond, identify the problem, and be seemingly open and honest about all of this. It's worth pondering the impact of a CA that tried to bury a mistake like this and notified no one.

It's not that there is a massive security hole in the entire trust model of authentication on the internet. The problem is more that the entire foundation of authentication that is a standard today is a shaky one, and there is a plethora of actively used security threats to trusted digital exchanges.

So, besides me, who here actively examines the certificates sites they're on(if your bank used one CA yesterday, and uses a different one today, that might be a red flag)? (If effugas shows up here, I'd be willing to bet he does)
posted by el io at 10:24 PM on March 24, 2011 [1 favorite]

oh yeah, a big huge thing... the fact that we have to PATCH OUR BROWSERS when some CA issues bad certificates shows that the entire revocation ecosystem is useless.

and learning about such things won't give you the tools to keep yourself more secure so much as it will give a sense of hopelessness and despair.

I envy bkudria's confidence in our security infrastructure.
posted by el io at 10:44 PM on March 24, 2011

I'm surprised to see how quickly people here are writing off SSL as a means of authenticating a host.

Facts:
1. It's easy to spoof DNS with a man-in-the-middle attack or by tricking DNS servers into accepting bogus record updates.
2. It's much harder to forge an SSL certificate from a trusted authority.

This is the worst breach I know of, and the extent of the damage is minimal. Nine forged certificates that lasted a few hours before the breach was caught and they were blacklisted? That's impressive, but it doesn't undermine my faith in SSL certificates. Sure, it's not perfect, but that little green SSL icon is still going to give me more peace of mind than I would have if everyone were using self-signed certificates.
posted by qxntpqbbbqxl at 10:46 PM on March 24, 2011 [1 favorite]

"Sure, it's not perfect, but that little green SSL icon is still going to give me more peace of mind than I would have if everyone were using self-signed certificates."

effugas has advocated other solutions.

It's consumers (users, businesses, governments) responsibility to demand that vendors in all parts of the ecosystem (clients, servers, routers, security appliances/software, load balancing hardware, operating systems, mobile environments) all get on board in simultaneously adopting better solutions than we have today.

The problem is real. The solutions are out there. Without demand from the consumers of the internet security ecosystem (ie: everyone), vendors won't be responsive. Then, to make it all more fun, all the vendors (who compete with each other) really need to cooperate to make the fundamental changes in our security infrastructure feasible.
posted by el io at 11:00 PM on March 24, 2011

9 times out of 10, it's not a man-in-the-middle attack, what happened is your credit union forgot to renew their certs. So you click OK.
posted by ryanrs at 11:03 PM on March 24, 2011 [2 favorites]

We don't know how quickly Codomo reported the breach to the browser vendors; just because they caught this breach somewhat quickly does not mean we can assume they will do so in the future. We can pretty much guarantee that not all client browsers will be updated quickly, and we know that until everyone out there has an updated browser, they're vulnerable.

In other words, this situation is very bad, affects a lot of people, and there are many ways in which future problems of a similar nature could be much, much worse. We're looking at systemic problems where that green lock could be lying to you for unknown periods of time, and those periods of time could be prolonged by more incompetence inside the system, more clever fraud that takes longer to detect, or a bad actor that covers up the mistake once detected. The "very bad" here is still quite possibly a best case scenario.

To use a driving analogy, we were lucky and managed to survive a car accident while not wearing seat belts. The correct response here is not to resume our previous behavior; it's to develop better habits and technology so this doesn't happen again. We need systems in place that can deal with stuff like this automatically. Requiring millions of people to update their browsers and/or hardware isn't viable.
posted by dvorak_beats_qwerty at 11:26 PM on March 24, 2011

Yeah but this one time my friend's cousin navigated her browser into a lake and she would have drowned if the site was using SSL.
posted by ryanrs at 11:31 PM on March 24, 2011 [2 favorites]

Poor girl tries to close the browser window, but the web site keeps saying

WARNING
You are leaving a secure site.
Are you sure?
[DROWN]    [CANCEL]
posted by ryanrs at 11:56 PM on March 24, 2011 [1 favorite]

.
posted by ryanrs at 11:56 PM on March 24, 2011 [1 favorite]

Malor: The way to fix this is to revoke the compromised certificates in the various browsers. Firefox just released an 3.5 update that fixes the problem, and apparently 4.0 is already immune, for whatever reason. Microsoft has a hotfix on their website. I'm not sure what Google is doing with Chrome, but they probably have an update out too.

Once the root certificates are revoked, your web browser will correctly warn you that the evil certificates are no longer trusted. However, it will give you the same warning for EVERY certificate that was signed with the compromised key, so Comodo will be scrambling like hell to issue new signatures for its customers.

If you get SSL certificate errors in the next couple of weeks, I'd suggest not trusting the site. Just give up on that site for that session. It'll most likely just be someone who hasn't gotten a certificate reissued yet. But it could also be the bad guys.

I haven't seen any indication yet that Comodo are actually revoking their affected root certificate and reissuing all client certs that link to it. It would be the correct thing to do, but it's a massive undertaking so I'm not sure it's actually going to happen.

Firefox 4, chrome and IE all have patches now issued browser side to specifically blacklist these particular certificates (supposedly firefox 4 final was delayed a few hours to get the patch in before release). I presume opera and safari will issue patches if they haven't already. Patches for mobile browsers will probably a while coming. iOS will presumably include in their next update, but updating windows mobile and android phones will take a lot longer due to the delays there.

The frustrating thing is, this shouldn't be a problem. Theoretically, certificates contain a URL to a server that lists whether the certificate has been revoked. However, it's not mandatory for basic signed certificates, and even extended validation certificates will failover to basic SSL if the revocation server is down or unavailable. If CAs maintained those servers, and checking them by browsers was required when seeing if a cert was valid then it would provide a defence against a failure in the issuing process like this. As it is, it's completely worthless.

The other fix I can think of is to have certificates only be shortlived, and the public key gets reissued every few hours or days by the CA. You have an SSL server, it needs to pull down the new public key as part of the use process. You could even set it up so say, one core server pulls down the update and issues it to your server farm if needed. You could implement this without any changes to the way SSL works server side or client side, and in the event of a breech, the stolen or fake key will become invalid very quickly.

You have a SSL cert now, it can be valid for years no matter how it gets compromised; whether it's 'fake' at issue, or the private key gets stolen from the owner, they're damned hard to kill.

The problem is, you need *some* method of knowing whether a certificate is trusted or not. Otherwise, it defeats entirely the whole point of SSL in the first place. If you assume the channel is insecure - i.e. someone can listen in and alter your traffic - then you want encryption to make your traffic useless to them without proxying (i.e. they have to actively interfere, not just listen in), and you need a way to detect that proxying when in happens. But if anyone can issue a certificate for a given website without your browser complaining, then the man in the middle attacker only needs to generate the appropriate fake certificate for his proxy, your browser doesn't complain, and you're back to where you started. Only this time, it's worse, because you think your traffic is secure, and it isn't. That said, it's ludicrous that self-signed certificates are treated worse than http only sites which is completely in the clear. BOTH http AND self-signed certs should be listed with red URL bars, and probably a crossed out lock. http is even less secure than a self-signed cert SSL site, as it can be passively listened into easily - just look at firesheep in web cafes for example.

But just killing off the CAs and going with self-signed certificates is not the answer.
posted by ArkhanJG at 1:06 AM on March 25, 2011

The circumstantial evidence suggests that the attack originated in Iran.
The perpetrator has focussed simply on the communication infrastructure (not the financial infrastructure as a typical cyber-criminal might).
The perpetrator can only make use of these certificates if it had control of the DNS infrastructure.
The perpetrator has executed its attacks with clinical accuracy.
The Iranian government has recently attacked other encrypted methods of communication.
All of the above leads us to one conclusion only:- that this was likely to be a state-driven attack.

Translation - you are not smarter than we are. Fuck with us (Stuxnet) and we willl fuck with you.
posted by three blind mice at 1:59 AM on March 25, 2011

I hate seeing stories like this and realizing that there's probably nothing I can do to minimize any risks from a security breach, except keep my software updated (which I do anyway).

I'm under the impression that Certificate Patrol would give you a warning if you went to a site using one of these bogus certificates (assuming you'd hit the legitimate site at least once before).
posted by mistersix at 3:33 AM on March 25, 2011

mzarquon: My friends office has one in place, all their managed windows machines have an additional trusted root CA that validates all SSL certs generated by their firewall. It is an auto real time man in the middle attack that they use for logging all incoming and outgoing traffic to their office building. If you checked the certificate chain for mail.google.com while in their office on one of their computers, you would see that it was signed by their router, and not by verisign, and your browser would be OK with that.

Note that this is almost certainly a local-only snoop. That is, there's a local CA certificate that all the machines have added to their local trusted stores, and the firewall creates new certificates for all SSL-enabled websites, signed by that CA. Because the CA is trusted, so is the bogus cert, and the traffic is tappable.

If, however, you were to bring your computer in from home, you'd almost certainly get nothing but certificate errors, because you wouldn't trust their CA unless you explicitly added it to your browser or OS.

It's incredibly unlikely that they're signing bogus certificates with a trust chain that comes from any root authority, because that kind of a local cert would be a ticking time bomb. Someone would just need to crack the firewall to get access to a certificate that would allow them to intercept almost any traffic, anywhere. I suspect that any CA that released that kind of certificate into the wild would shortly be out of business, because everyone would remove them from the trusted list when the news got out.

ArkhanJG: I haven't seen any indication yet that Comodo are actually revoking their affected root certificate and reissuing all client certs that link to it.

You're right; the first reports I read said that Comodo had been compromised, and so I assumed that a full root revocation would be necessary. But if they instead managed to trick Comodo's staff or automated systems into signing the bogus certs, without actually getting access to the signing key, that wouldn't be necessary. Those specific certs would need to be blacklisted, and the damage would be relatively contained, at least for people staying on top of their patches.
posted by Malor at 3:35 AM on March 25, 2011

Huh, I just double-checked, and it looks like it may actually be possible to become an issuing CA, if you're a medium business or larger. That's actually rather frightening.
posted by Malor at 3:39 AM on March 25, 2011

Even with the bogus certs I highly recommend using HTTPS-Everywhere.
posted by Benny Andajetz at 5:11 AM on March 25, 2011

As mistersix said Cert Patrol is a great way to protect yourself but it doesn't help Mom.

The fact that any organization large enough can become a CA by paying an existing large CA to let them issue certificates for any domain is troubling. Is it time for CAs to rethink reselling the ability to issue certificates in to any arbitrary hostname? I say yes.

As for this particular attack I find it curious that Comodo wasn't protecting the interface to approve certificate requests with something like certificate authentication via a smart card. If Comodo, a large CA that should know better, can't justify deploying certificate authentication via smart cards to protect their infrastructure what makes anyone think that the intermediate CAs will protect themselves adequately?
posted by cmj at 7:27 AM on March 25, 2011

1. It's easy to spoof DNS with a man-in-the-middle attack or by tricking DNS servers into accepting bogus record updates.

This is only the case because certain people have been dragging their feet on DNSSEC for, oh, about a decade now. There's no reason it needs to be the case.

And once the DNS chain is secured, most of the reason for having a separate authentication chain based on SSL certs goes away. Why screw around with certificates and revocation lists if you can do it all through DNS? That's how it should have been from the beginning. Do your authentication there and then do your transport encryption however you'd like to do it, using ephemeral keys or whatever.

I agree with you that the certificate model works okay, but it's a kludge that reeks of OSI model. I'll be quite happy to get rid of it at the earliest opportunity.
posted by Kadin2048 at 8:15 AM on March 25, 2011

The problem with relying on DNSSEC entirely is that then you're trusting domain registrars to do the right thing, not certificate authorities. No matter what protocol you use, someone has to do the hard work of verifying that the guy who says he's Google is actually a representative of Google, and everyone's taking shortcuts in doing that.
posted by miyabo at 8:32 AM on March 25, 2011

> Note that this is almost certainly a local-only snoop

Of course, it was really only to illustrate the point that doing this doesn't require l33t skills. It requires a credit card so you buy the dedicated hardware appliance to perform realtime man in the middle attacks for you. If you had one of those rogue certs, you could probably also configure the same device to only log access to mail.google.com and to sign everything with the illicitly acquired certificate.

> Huh, I just double-checked, and it looks like it may actually be possible to become an issuing CA, if you're a medium business or larger. That's actually rather frightening.

Issuing CA or Trusted CA? I mean, anyone can become a CA, I've seen a lot of large entities setup their own CA internally just to generate SSL certs for all their servers and network equipment, and since they control all of it, they just add their CA root certificate to the trusted list of those systems and their workstations. In fact when setting up their imaging workflow for new workstations, they have steps to make sure they get their root CA installed on all systems. And for a while I had setup my own CA internally just to test stuff on my lab. I had to install my root cert on my computers before they trust the connection, but it let me switch from having to trust every ssl cert I would create for testing manually to being able to trust my own CA's root certificate once and everything it signed would come through fine. University of Washington does something like this as well.

Now the real problem is convincing Microsoft or Apple or Mozilla to agree to add your root certificate on their OS / Browsers. Which is why UW has a webpage instructing people to install their root cert manually, since their certificate isn't on anyones trust list by default.
posted by mrzarquon at 9:17 AM on March 25, 2011

The most interesting part of this story to me is how poorly the certificate revocation system works. It works so badly that Mozilla and Google rushed binary patches to their browsers to block the bad certs rather than rely on the revocation infrastructure. That's pretty damning.

I mean seriously, the code for Chrome now includes a X509Certificate::IsBlacklisted() method with constants in it like {0x04,0x7e,0xcb,0xe9,0xfc,0xa5,0x5f,0x7b,0xd0,0x9e,0xae,0x36,0xe1,0x0c,0xae,0x1e}. What a mess.
posted by Nelson at 9:17 AM on March 25, 2011 [1 favorite]

Related, about a year back Firefox added China Internet Network Information Center as a trusted root. That means your web browser could connect to google.com and be presented a certificate that looks 100% valid, signed by CNNIC, and you'd never know that in fact the Great Firewall had intercepted your browser session and was reading all your email. Needless to say there was some controversy, I haven't followed the story.

The real problem is a single global network of trust has problems. Mozilla can't exactly say "no Chinese company can sign certificates". And China isn't uniquely a bad actor: plenty of US companies have been willing to illegally collaborate with NSA, for instance. Trust is complicated.
posted by Nelson at 9:25 AM on March 25, 2011 [1 favorite]

Certificate revocation is something I hadn't really looked at too closely, but after reading some of the links here, as well as other places, it's clear that our current system for secure connections over SSL is broken. When I say broken, I mean "needs overhaul" not "needs fresh paint job".

Even a non-technical person can understand that if a certificate is fraudulently issued, it should not take a browser-patch to fix the problem. There are methods in place for revocation, and they failed. If a site presents that fraudulent certificate, the user must be warned/stopped (or forced to jump through 13 "OK" dialog boxes -- kidding!).

Instead, we're now reliant upon the decision-making of browser-manufacturers to maintain lists of "trusted" CAs? Where's the transparency there? (That's not entirely rhetorical - maybe I'm not looking hard enough)

At the heart of the solution is the fact that existing CAs are already entrenched as "trusted", so I expect to hear a lot of "it's not the system, it's just one bug". Our existing "trusted" CAs have nothing to gain by moving towards increased security at the cost of their existing relative position within the certificate market.

Also, mad props to Jacob Appelbaum for his work on this and many other security issues.
posted by antonymous at 9:43 AM on March 25, 2011

The problem with relying on DNSSEC entirely is that then you're trusting domain registrars to do the right thing, not certificate authorities

I don't really see why that's any worse. And registrars are supposed to be doing some level of validation anyway, plus they need to handle payment for the domain, so they're well-positioned to handle authentication.

So, the way I envision it, if someone wanted authentication on their domain, they'd prove their identity to their registrar (at time of registration or at some later date), and if the registrar was satisfied, the registrar would include the information in DNS and sign the record. If you wanted to stay anonymous or just don't care about authentication, then you don't do this and you just get a normal DNS record without any additional information in it.

Having a separate, parallel infrastructure for authentication that's different from domain names doesn't seem to buy us anything, particularly since it's now apparent to everyone that DNS needs to be secure anyway.
posted by Kadin2048 at 9:57 AM on March 25, 2011

Issuing CA or Trusted CA?

Well, in cursory checking, it looks like GeoTrust is willing to set you up as a signing CA, if you're reasonably well-heeled, carry liability insurance, and do your key generation and signing on dedicated hardware. The GeoTrust site was down when I was looking, so I'm unclear on whether that CA authority is limited to certain domains, or if they'll let you generate keys for any site.
posted by Malor at 11:23 AM on March 25, 2011

That comodo screwed up is bad. But what's really bad is that one screwup from one CA has the potential to compromise every user of TLS. That is, the way we manage "trusted root" CAs is a weakest-link operation. There are hundreds of CAs, and if any one of them decides (or is convinced) to issue a bogus certificate, your communications could be tampered with or snooped on without your knowledge.

How did we get into such a mess? I've argued before that the perverse incentives of the current CA system is rooted in a fundamental technical mistake. And those perverse incentives make it much harder for everyone to be able to have integrity-checked, authenticated, private communication over the internet.

To really fix the situation, we need to have identity models that are corroborative instead of weakest-link -- that is, your tools should be able to check with multiple independent parties to verify that you are connecting to the site/person you think you are connecting to. And unfortunately, i think people will ultimately need to pay a bit more attention to their tools to understand when they have a private/integrity-checked connection and when they don't. This means our tools need to be much friendlier and easier to report this sort of info too.

There's a lot of work to be done to get it right, and there are some seductive proposals that aim to help people avoid having to think about communications security by glomming cryptographic identity into the domain name system. While this would be nice, it doesn't solve two problems: (a) people are fooled by DNS phishing attacks all the time because it doesn't occur to them that bankofamericaa.com is not owned by the Bank of America, and (b) DNS itself is a nice tempting centralized single-point-of-failure, vulnerable to pressure from powerful forces like state actors (e.g. the apparent culprits in the recent comodo breach).

I'm a contributor to one of the projects attempting to address the root causes of the situation: the monkeysphere; we're using the existing OpenPGP web of trust as a means of corroborative identity checks. There's lots to work on -- we welcome discussion on our mailing list.

If you're a server administrator, you can enable this kind of corroborative check without affecting your other users just by signing and publishing your server's public key to the WoT. Please try it out!
posted by dkg at 1:40 PM on March 25, 2011 [2 favorites]

Comodo hacker's manifesto
Comodo hacker's proof
Analysis of Comodo hack
posted by scalefree at 4:56 PM on March 27, 2011

"Officials at Comodo have acknowledged that an additional two registration authorities affiliated with the company have been compromised in the wake of the high-profile attack on the company that was disclosed last week. However, no forged certificates were issued as a result of the new attacks."
posted by JiBB at 5:26 PM on March 30, 2011