Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 13:22 UTC (Tue) by kpfleming (subscriber, #23250)
In reply to: Fraudulent *.google.com certificate issued by slashdot
Parent article: Fraudulent *.google.com certificate issued

In the olden days (over 15 years ago), reputable CAs did in fact require positive acknowledgement that the cert requester was in fact who they claimed to be, and had rights to obtain a cert with the name that was requested. Of course, this sort of business model doesn't work when there are tens of thousands of certs being issued daily.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 14:35 UTC (Tue) by tialaramex (subscriber, #21167) [Link]

The problem isn't that it doesn't _work_ but rather that it isn't as profitable, and there has so far been no incentive for a CA to stay safe -- no matter how negligent they are the money keeps flowing. Maybe this incident will be the start of something better but I doubt it.

I see people are already saying maybe just this one CA did a bad job. That shouldn't be reassuring. Vendors like Google, Red Hat, Microsoft ship these CA roots in their product. They have taken on the responsibility of determining which CAs are trustworthy, but their procedures for doing so are completely inadequate.

I don't think reform is realistic at this point, we must search for ways to replace the CA function, and I believe DNSSEC has great potential there.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 19:03 UTC (Tue) by slashdot (guest, #22014) [Link] (7 responses)

Why doesn't this business model work?

Just make the certificate pricy enough to cover the costs.

If that's not competitive, then browsers should just ban all CAs that don't do that.

And obviously, before an issue occurs, by actively trying to game the CA and seeing if it works.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 19:09 UTC (Tue) by dlang (guest, #313) [Link] (6 responses)

unless you are willing to scrap all existing certs and start over from scratch, you can't just ban everyone who doesn't do enough checking.

besides, you need to define what 'enough' checking is.

if someone presents a legal document that says they own a business in some obscure country, should they be allowed to get a cert for the name? how can you tell for sure that the people you are talking to are the ones who you really should be talking to? in this day of outsourceing IT projects, it's very likely that the people running the webservers are not part of the company that actually owns the name.

do you want a fax of a letterhead? I can make up a letterhead for any company pretty quickly (if I don't just get the legitimate company to send me some sort of document on letterhead and just scan it to fax it to you)

the big problem right now is that some of the CAs are charging huge amounts of money (up to $1500/cert) and still not doing real checking.

and none of this will do any good if the CA gets broken into (like this CA is claiming) and has the hackers use their infrastructure to sign certs without the approval of the CA.

Fraudulent *.google.com certificate issued

Posted Sep 1, 2011 8:11 UTC (Thu) by Comet (subscriber, #11646) [Link] (5 responses)

If you're unable to verify, you shouldn't take money to issue a certificate saying that you've verified. Doing so is fraud, since the whole _point_ of the CA system is to be a trusted third party that verifies.

So if you can't recognise papers from some obscure country, you shouldn't be issuing certs for businesses in that country, and some more local CA should be getting that business, or a CA which has researched how to recognise "legitimate" papers for that country.

There's no right to be able to take money from anyone in any country.

Also, British CAs shouldn't be able to issue certs for Argentinian banks and Argentinian CAs shouldn't be able to issue certs for British banks. But ~nobody uses nameConstraints in certs, and no client software has a framework for imposing nameConstraints not found within the cert itself. The X.509 PKI as used right now is not designed to prevent internal fraud within and by the CAs.

Nor is TLS designed to support being able to revoke CA certs, since that would threaten profits from the big providers who pay the salaries of the attendees of the relevant standards bodies. (Yes yes, IETF attendees are in a personal capacity. Always. Uh-huh.) Otherwise, there would be a TLS extension for the server to declare "I have a certs from N CAs, here are those hashes, you can ask for any of those instead" and be able to fail over across CAs; at that point, bad actors could have their CA certs revoked more readily and there would be market forces acting to push CAs to actually verify identities. (And yes, I know there's a whole bunch of specialist nomenclature for identity verification not being strictly part of CA, but for our purposes, that's all part of the CA umbrella).

Instead, the only relevant proposed TLS extension involves the client declaring in the handshake all the CAs it supports, which is (a) a fingerprint technique for client tracking; and (b) massive bloat in the startup, since most clients support hundreds of CAs, and you should only need to know about the 3-5 CAs which the server has certs from.

There is little about the CA business that comes across, to me, as ethical, because the protocols are designed to support market forces that pressure them to not be ethical and to pressure towards a monopoly (get your certs from the CAs accepted by everyone, instead of 3-5 CAs who between them cover everyone, and be resilient to CA revocation by your site visitors).

Bleh.

Fraudulent *.google.com certificate issued

Posted Sep 1, 2011 8:23 UTC (Thu) by Comet (subscriber, #11646) [Link] (4 responses)

PS: while I don't defend DigiNotar, I will note that it's hypocritical of the browser vendors to blacklist them as an entire CA, but keep Geotrust in after their 2006 "mishap", or Verisign after issuing the Microsoft certs.

There is the appearance here of jingoism and a more readily dismissive attitude towards CAs in markets outside the USA.

To repeat: I'm not defending DigiNotar; given the scale of their breach, they absolutely should have been blacklisted, since they should have been revoking the subsidiary CA which we can presume is the only one online, since the master CA cert is _of_ _course_ (*cough*) kept offline and only loaded, in computers without a network connection, to sign the subordinate CAs; they could then issue replacement certs for all the legitimately issued ones, which would be expensive and embarrassing -- but that's as it should be! Expense and embarrassment are countervailing forces to pressure CAs into running a clean shop.

I just think that some other, larger, CAs should have been given the same treatment, instead of the more pragmatic "oh, it would do too much damage to revoke those CAs" approach, which led to "too big to fail" CAs.

Which leads into my point about the TLS protocol being flawed in only permitting one CA; strong security, as long as you trust the CA, but providing for bad market forces which lead to less trustworthy CAs.

Fraudulent *.google.com certificate issued

Posted Sep 1, 2011 10:49 UTC (Thu) by nix (subscriber, #2304) [Link] (3 responses)

DigiNotar didn't have *one* breach, though. It had *numerous*, over *years*, and they didn't spot a single one of them. One is forced to conclude that DigiNotar's systems shouldn't be on the Internet at all, and their sysadmins need serious retraining before they're allowed to administer systems with any security significance.

Fraudulent *.google.com certificate issued

Posted Sep 1, 2011 20:35 UTC (Thu) by Comet (subscriber, #11646) [Link] (2 responses)

The only public evidence I've seen for the multiple breaches claim is screenshots showing that a CMS let people create pages with new names and those pages would be served up, accompanied by hyperbole.

Stupid, but the screenshots were also showing plain text, so there's also a slim chance that there wasn't even a cookie-stealing attack made possible by this. Just bragging rights in getting plaintext up under an available name of your choice.

Stupid CMS for some web content is a long way from breach of the signing systems. If your news source is a company which sells security services, then hyperbolic claims on their part in talking up the implications of what they found is to be expected.

I'd hope that technical decisions about trust are based on more than panicked responses by non-technical decision makers to hyperbole they take at face value because they don't understand the issues.

So I'm assuming that there's yet more to this story that hasn't come out yet.

Fraudulent *.google.com certificate issued

Posted Sep 6, 2011 19:52 UTC (Tue) by Comet (subscriber, #11646) [Link] (1 responses)

Okay, we now have multiple breaches evidence (but not the "over years" part):

https://blog.torproject.org/blog/diginotar-damage-disclosure

Excuse me while I cry into a drink.

Fraudulent *.google.com certificate issued

Posted Sep 6, 2011 20:38 UTC (Tue) by nix (subscriber, #2304) [Link]

Um, those earlier breaches that the Tor post points to were apparently done in *2009*. That would be, well, years ago.

Fraudulent *.google.com certificate issued

Posted Aug 31, 2011 5:16 UTC (Wed) by niner (subscriber, #26151) [Link] (2 responses)

StartSSL still operates that way. They are not only extremely cheap, but also very thorough. We had to send them quite a few documents and they called not only me, but also the company owner on the phone for verification. It's a shame that not more people know about them. They're essentially breaching the certificate oligopoly and make SSL available to a much wider audience.

Fraudulent *.google.com certificate issued

Posted Aug 31, 2011 22:24 UTC (Wed) by ondrej (subscriber, #27872) [Link] (1 responses)

Really? I just issued my cert with StartCom by just clicking on the web and proving just that I am able to read the mail associated with the domain name.

Fraudulent *.google.com certificate issued

Posted Sep 1, 2011 7:19 UTC (Thu) by niner (subscriber, #26151) [Link]

As you may have noticed, StartCom is offering certificates at different verification levels. You got the Class 1 Free certificate while I described the procedure for Class 2 Verified certificates.