Fraudulent *.google.com certificate issued [LWN.net]

The Mozilla Security Blog carries an advisory that DigiNotar has revoked a fake digital certificate it issued for Google's domain. "Users on a compromised network could be directed to sites using a fraudulent certificate and mistake them for the legitimate sites. This could deceive them into revealing personal information such as usernames and passwords. It may also deceive users into downloading malware if they believe it's coming from a trusted site. We have received reports of these certificates being used in the wild." Updates to Firefox, Thunderbird, and SeaMonkey are being released in response.

Update: see this EFF release for a lot more information; it does not look good. "Certificate authorities have been caught issuing fraudulent certificates in at least half a dozen high-profile cases in the past two years and EFF has voiced concerns that the problem may be even more widespread. But this is the first time that a fake certificate is known to have been successfully used in the wild. Even worse, the certificate in this attack was issued on July 10th 2011, almost two months ago, and may well have been used to spy on an unknown number of Internet users in Iran from the moment of its issuance until it was revoked earlier today."

to post comments

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 1:39 UTC (Tue) by kjm (subscriber, #4552) [Link] (14 responses)

This one must have been pretty bad. Firefox is removing DigiNotar as a CA in the update.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 2:40 UTC (Tue) by cesarb (subscriber, #6266) [Link] (12 responses)

The public bug report seems to be https://bugzilla.mozilla.org/show_bug.cgi?id=682956 (but the true bug report seems to be restricted, and not even its number seems to be publicly known).

If I understand correctly the comments there (in particular https://bugzilla.mozilla.org/show_bug.cgi?id=682956#c10), it is more than just removing: it is blacklisting _by name_.

We probably will know how bad it was only after the true bug report is opened up.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 3:27 UTC (Tue) by josh (subscriber, #17465) [Link] (9 responses)

Blacklisting by name alone seems like a bad idea; the root CA also needs blacklisting by fingerprint. After all, this incident will probably force them to retire their current brand entirely.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 4:04 UTC (Tue) by dlang (guest, #313) [Link] (8 responses)

blocking by name is broader than blocking by fingerprint.

blocking by fingerprint blocks one particular CA cert, blocking by name blocks every CA cert with that name, effectively passing a death sentence on that CA (at least under that name, and if the same people submit a new CA to be accepted by the browsers, it's unlikely to be accepted)

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 22:36 UTC (Tue) by martinfick (subscriber, #4455) [Link] (7 responses)

> and if the same people submit a new CA to be accepted by the browsers, it's unlikely to be accepted)

How would that work?

Fraudulent *.google.com certificate issued

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

well, if a CA has done something bad enough to be removed (and as far as I am aware, this case is a first), then the same people who had to do the removal and deal with the fallout are the same people who would have to approve putting a new CA into their software, I figure they are unlikely to risk getting into the same mess a second time with the same people.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 22:51 UTC (Tue) by martinfick (subscriber, #4455) [Link] (5 responses)

What is mozilla suppose to track who works for whom now? If not, what do you mean the same people?

Fraudulent *.google.com certificate issued

Posted Aug 31, 2011 15:43 UTC (Wed) by raven667 (subscriber, #5198) [Link] (4 responses)

I would think they do _some_ amount of due diligence that when some CA emails them a public key as says "trust us" that they figure out if where it's coming from is legit. In fact I know that the process is somewhat expensive and can take quite a while from when I worked at an internet company which was also a CA trying to get their new key in vendors default keychains.

Fraudulent *.google.com certificate issued

Posted Aug 31, 2011 15:56 UTC (Wed) by martinfick (subscriber, #4455) [Link] (3 responses)

I am not saying they don't do anything, but I am asking how one would even attempt to approach this problem. So far, you haven't given the slightest hint to how this might actually be possible. I think that it is most likely an extremely vague untractable problem.

Fraudulent *.google.com certificate issued

Posted Aug 31, 2011 16:37 UTC (Wed) by raven667 (subscriber, #5198) [Link]

It's a human problem not a technical one which is why it might seem vague. Clearly a "new" CA showing up in the same area as the old one would come under extra scrutiny. They could check their WebTrust audits and registration and see who audited them and what they found. They could check who are the officers and ownership of the company, how long the company has been around, if it shares office space with the "old" company. They could look at public tax info to see if the organization has been around and has books that make sense. If the company is public they could look at the books themselves (heck for high-value sales private companies have been known to let potential customers look at the books to reassure them).

Building up the paper trail that a CA needs to be accepted by the browsers does require effort and time but you are right in that I have not worked close enough to the CA/browser relationship to know exactly what is required to register with MS, Mozilla, Apple, Opera, Oracle, Google, RIM, and other vendors.

Fraudulent *.google.com certificate issued

Posted Sep 1, 2011 7:56 UTC (Thu) by Comet (guest, #11646) [Link] (1 responses)

This is what companies like Dunn & Bradstreet do, and the other old major merchant houses.

Things like Linkage Analysis, where they figure out which companies own which other companies, and trace down who actually owns a company.

It's human legwork to maintain their databases. Thus they get to charge money for queries against them.

So, I certainly hope that the major CAs are doing at least a paid check with one of the merchant houses before issueing EV certs, and anyone bundling together a group of CAs for others to trust should either be saying "don't trust us, this is just what we find convenient" (amateur, but sometimes appropriate) or should be doing the same due diligence.

Fraudulent *.google.com certificate issued

Posted Sep 1, 2011 18:20 UTC (Thu) by raven667 (subscriber, #5198) [Link]

I'm pretty sure they do, I know the CA I used to be involved with did D&B checks and gathered other docs before issuing new EV certs. The data gathering process usually took a couple of weeks and had to be validated by certified individuals and the actual issuance had to be performed by two managers.

In this case though attackers are believed to have compromised the infrastructure and had enough access that they could issue whatever they liked without going through the audit and security controls. The technical measures which could prevent this are difficult, cumbersome, expensive and not foolproof. At some point you have to be able to accept a CSR from a customer and expose it to the HSA and receive a result. If you can get anywhere in that path you can send your own CSRs and have whatever you want signed.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 6:46 UTC (Tue) by imphil (subscriber, #62487) [Link] (1 responses)

They are blacklisting by name and even disallowing overrides for older certs, see http://groups.google.com/group/mozilla.dev.security.polic...

"The
current patches to Mozilla products will blacklist all DigiNotar-issued
certificates based on "CN=DigiNotar " in the certificate issuer. Users
will be able to add a certificate override for DigiNotar-issued
certificates that have a notBefore date prior to July 1, 2011. Users
will not be able to add a certificate override for any DigiNotar-issued
certificates with a notBefore date after July 1, 2011, which would
include the *.google.com certificate. "

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 10:13 UTC (Tue) by cesarb (subscriber, #6266) [Link]

I read that double negative as the opposite: they are disallowing overrides for *newer* certs (notBefore is the date when a certificate starts being valid, notAfter is the date when a certificate expires).

Worse than I thought

Posted Aug 30, 2011 12:47 UTC (Tue) by cesarb (subscriber, #6266) [Link]

> This one must have been pretty bad.

It seems it is even worse than I thought. Take a look at http://www.f-secure.com/weblog/archives/00002228.html :

> "If you keep digging deeper, you'll find that although these web defacements are still live right now, they are not new. Much worse: they were done years ago. [...] In fact, these hacks are so old, it's unlikely they are connected to the current problem."

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 3:48 UTC (Tue) by jwb (guest, #15467) [Link] (10 responses)

I don't understand why the revocation protects anybody. If you're vulnerable to this cert, your DNS is being spoofed, and that means that the CRL is also being black-holed.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 4:59 UTC (Tue) by butlerm (subscriber, #13312) [Link]

There are two basic ways to revoke a certificate - one is to black list it in client software, and the other is to publish it on a certificate revocation list server. What Mozilla is doing is the former.

The advantage of doing it in the client software is that no one can block it unless they can compromise the software itself. The disadvantage is that it takes a software update or upgrade to become effective.

On the other hand, the CRL server or distribution point is generally operated by the corresponding CA, so if you don't trust the CA you have no alternative than to remove it from your trust list.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 5:18 UTC (Tue) by butlerm (subscriber, #13312) [Link]

Of course if you are referring to Diginotar's revocation of the improperly issued certificate, your point is well taken. Browsers do cache CRLs, so once you have received a valid CRL update for the CA, you should be protected when you wander into insecure networks, no?

Fraudulent *.google.com certificate issued

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

Can CRLs really be blackholed without warning?

If so, that's bad: the browser should connect to it via SSL (using a static certificate) and at least warn if connection fails.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 9:51 UTC (Tue) by cesarb (subscriber, #6266) [Link]

At least for OCSP, there is an option to fail the HTTPS connection if it cannot contact the OCSP server. Go to Preferences>Advanced>Cryptography>Validation and mark the last checkbox.

AFAIK, current browsers prefer to use OCSP instead of CRLs.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 13:42 UTC (Tue) by cortana (subscriber, #24596) [Link] (5 responses)

This is possible using a process known as OCSP, but it causes its own problems:

* It's up to the CA whether to use OCSP or not. Most don't.

* There is a performance hit associated with doing the OCSP query. You don't want every outgoing connection you make to trigger a query, so you have to cache the responses.

* You disclose to the CA which web sites you visit, how often you visit them and how long you remain there. I don't think the connection to the OCSP server is itself encrypted, so anyone between you and the server will also become privy to this information.

* If the OCSP server is down and your browser is configured to ignore the failure, then a DOS attack on the OCSP server could compromise your security as you wouldn't know that a server's certificate has been revoked.

* If the OCSP server is down and your browser is configured to fail the connection, a DOS attack on the OCSP server becomes a DOS attack on all the web sites that use it.

If browser makers were serious about security then they would insist that every CA certificate they ship either:

* maintain an OCSP server; if so, connections to a web site must fail if an OCSP response can not be obtained

* publish CRLs; if so, the browser must be pre-configured to update each CA's CRL at regular intervals and refuse to connect to a web site if a recent CRL for the site's CA is not present.

I just checked Firefox, and it doesn't know about CRLs for *any* of the CAs whose certificates it ships, let alone automatically update them. I also checked Chrome, and it doesn't even have a UI for managing CRLs!

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 20:49 UTC (Tue) by paravoid (subscriber, #32869) [Link] (4 responses)

I have mandatory OCSP in my Firefox. Since I enabled it I had some hiccups here and there but nothing too important. I have, however, experienced a quite interesting situation:

Commercial Wi-Fi hotspots usually redirect your traffic to their own website where you can buy a short-term pass or a subscription.

Since a) those WiFi networks are non-encrypted, b) they require either a short code that's equivalent to some money paid or your credit card, it's frequent to see HTTPS being used on their captive portal.

But the hotspot doesn't allow any kind of traffic besides connecting to the captive portal and even redirects HTTP requests that try to connect elswhere.

which breaks OCSP. And present you with a nice chicken-and-egg problem.

(yes, they're broken by design, and yes I know about iodine :))

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 21:51 UTC (Tue) by raven667 (subscriber, #5198) [Link] (2 responses)

As someone who has a hand in a captive portal deployment what we've done is whitelist the IPs of the OCSP servers for the certs we are using to work around this problem so we don't have helpdesk complaints from customers who have OSCP enabled. A cron jobs can check to see if the IPs have changed.

Fraudulent *.google.com certificate issued

Posted Aug 31, 2011 16:34 UTC (Wed) by cesarb (subscriber, #6266) [Link] (1 responses)

Did you also whitelist all the needed DNS servers? When on untrusted networks, I usually run the bind DNS server on my laptop (querying directly the root servers) so it can validate the records using DNSSEC.

Fraudulent *.google.com certificate issued

Posted Aug 31, 2011 18:03 UTC (Wed) by raven667 (subscriber, #5198) [Link]

No, the only dns servers allowed through the captive portal prior to authentication are the recursive ones we maintain, these are what are suggested via DHCP. I imagine your config would break on a lot of captive portals unless they had blanket rules allowing any dns traffic.

Fraudulent *.google.com certificate issued

Posted Sep 1, 2011 7:58 UTC (Thu) by Comet (guest, #11646) [Link]

This problem is solved with OCSP stapling.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 9:16 UTC (Tue) by slashdot (guest, #22014) [Link] (13 responses)

Maybe there should be better verification procedures?

Like, for instance, calling by phone or sending e-mail to the company allegedly requesting a certificate, and checking that indeed it's them asking for it.

As well as requiring a DNS entry to be added to prove that the domain is indeed owned by who is requesting the certificate.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 13:22 UTC (Tue) by kpfleming (subscriber, #23250) [Link] (12 responses)

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 (guest, #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 (guest, #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 (guest, #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 (guest, #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 (guest, #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 (guest, #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.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 9:36 UTC (Tue) by bjartur (guest, #67801) [Link]

Am I the only one who finds it sarcastic that convergence.io doesn't accept TCP connections on port 443?

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 12:58 UTC (Tue) by mjw (subscriber, #16740) [Link] (3 responses)

This seems pretty bad for Dutch citizens. The revoked root certificate was also used for the national government Digital Identity site DigiD.nl. You need to authenticate through DigiD to submit Dutch tax forms for example...

Dutch coverage:
http://tweakers.net/nieuws/76461/firefox-vertrouwt-certif...

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 13:06 UTC (Tue) by lkundrak (subscriber, #43452) [Link] (2 responses)

This is similar to usual situation around here.

Both Czech and Slovak tax offices (and supposedly more government sites) use CAs that are not bundled with any browser/OS (similarly called "First Certificating" in both countries). Moreover, if you attempt to verify the certificate via phone noone even knows what a fingerprint is. I probably don't want to know how much did the certificates cost.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 13:30 UTC (Tue) by cesarb (subscriber, #6266) [Link]

It is the same here in Brazil, see https://bugzilla.mozilla.org/show_bug.cgi?id=438825 (the tax office is https://www.receita.fazenda.gov.br/).

The trick I use is, whenever installing a new computer, go to https://www.mozilla.org/projects/security/certs/pending/, which has both the links to the correct root certificates for ICP-Brasil and their fingerprints (they are what Mozilla will add if/when the CA is accepted). Just click on each one, set the correct trust bits (also listed in that page - in ICP-Brasil's case, it is only "Websites"), compare the fingerprint, and done. Just remember to check you are using https for that page.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 16:36 UTC (Tue) by iabervon (subscriber, #722) [Link]

I assume the tax offices also distribute information to the public that needs to be correct to protect people's privacy; if someone made tax form booklets that told you to send the forms to an attacker (who would then send them on to the correct address, having copied them), they could steal all sorts of information. If these official mailings included the CA fingerprint where they tell you about the web site, it would be more secure than what Google does, because an attacker couldn't just hack into some insecure CA and get a fraudulent certificate that would act the way the booklet tells you to expect.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 13:09 UTC (Tue) by rich0 (guest, #55509) [Link] (30 responses)

They should have a CRL for the browser root CAs, and it should fail safe if the network is down or at least display a warning.

Updating software every time a CA blows it is crazy.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 13:36 UTC (Tue) by cesarb (subscriber, #6266) [Link]

If I am reading Microsoft's advisory at https://www.microsoft.com/technet/security/advisory/26077... correctly, it appears they have something like that since Windows Vista.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 14:13 UTC (Tue) by jg (guest, #17537) [Link] (28 responses)

Fundamentally, the certificate system in general is broken: there are too many CA's, and their business model is to make certs cheap, rather than be real "certificates" of identity.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 15:10 UTC (Tue) by butlerm (subscriber, #13312) [Link] (27 responses)

The easy way to remedy most of this problem is to drop the use of CA issued certificates for domain validation and use DNSSEC validated certificates instead. Then nobody (for example) could authenticate as *.google.com without compromising the .com DNS registry, or the client software itself.
http://www.imperialviolet.org/2011/06/16/dnssecchrome.html

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 15:45 UTC (Tue) by dkg (subscriber, #55359) [Link] (25 responses)

The easy way to remedy most of this problem is to drop the use of CA issued certificates for domain validation and use DNSSEC validated certificates instead.

Sure, DANE is a decent way to ensure that malicious CAs are out of the loop, so they can't be targeted by governments or corporations who want to impersonate or replace an existing presence on the 'net. DANE does this by placing much more reliance on DNS itself.

However, governments and corporations have already demonstrated a willingness to tamper with DNS directly. It's not clear to me that DANE (or anything else like that relies solely on DNS) going to solve the larger problem of powerful adversaries being able to impersonate or damage specific network services.

This authenticity problem is caused by centralized and implicitly-trusted authority, not just crappy CAs. We need a naming scheme that is decentralized and cryptographically-verifiable with explicit corroboration mechanisms, like Monkeysphere (i contribute to this project) or Convergence to address the issue. A "solution" which further centralizes authority seems likely to consolidate abuse, not eliminate it.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 16:51 UTC (Tue) by job (guest, #670) [Link] (18 responses)

You can not tamper with DNSSEC replies. That's the whole point. Of course, you have to trust the root (and your system administrator, which is likely a weaker link) but that's about a billion times better than hundreds of CAs (where all of them needs to be secure).

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 16:57 UTC (Tue) by dlang (guest, #313) [Link] (17 responses)

if the government is out to get you, what makes you think you can trust the root?

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 17:16 UTC (Tue) by dkg (subscriber, #55359) [Link] (8 responses)

This is exactly my point. We need distributed/decentralized naming schemes that allow corroborative assertions so that our tools can actually reflect explicit, considered reliance on naming/identifying authorities. DNS as currently implemented (including DNSSEC) doesn't provide this decentralization, so it doesn't solve the underlying problem.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 18:44 UTC (Tue) by raven667 (subscriber, #5198) [Link] (6 responses)

IIUC one would need to run an entire shadow DNS infrastructure to pull this off, their own root which signs all of the second level domains which signs all of the third level domains, probably creating the keys as requests come in and caching them. I imagine that this is well within the capabilities of a well funded government program but it would be interesting to figure out exactly how complex the spoofing would need to be to successfully subvert DNSSEC so as to enable this kind of monitoring, how much it would cost. Then we can figure out what the risk is.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 19:03 UTC (Tue) by dkg (subscriber, #55359) [Link]

Or, a powerful adversary could just lean on one of the parties holding a key that sits "above" the target domain, and request that the keyholder quietly provide a properly-signed RR that delegates a sub-zone to the adversary.

Then, the adversary serves this RR in response to the victim's DNS request, and manages the sub-zone themselves. With such an RR in hand, the adversary only needs to control the victim's upstream network connection in order to be able to compromise the integrity and confidentiality of their communications.

if the delegated zone is a high-level one (e.g. .com), then something like phreebird in front of a filtering DNS cache should be fine (filtering to replace the authoritative keys for the sub-zones with its own key, that is). It would take a bit of engineering, but it's far from an insurmountable task.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 19:15 UTC (Tue) by butlerm (subscriber, #13312) [Link]

>one would need to run an entire shadow DNS infrastructure to pull this off

At a minimum you would need the DNS root private key (or the cooperation of the people who hold the key) to do this without compromising the client, which places it out of reach for any but the governments powerful enough to compel ICANN to give them the key or sign a full set of compromised TLDs for them.

Fraudulent *.google.com certificate issued

Posted Sep 1, 2011 8:26 UTC (Thu) by Comet (guest, #11646) [Link] (3 responses)

No, you'd only need to fake up the first level signatures on the TLDs, and then into any TLD where you want to be able to filter traffic; the public keys for the sub-zones are published in the DNS, so for those you want to preserve you just pass through a delegation into the existing keys.

Given that DNS implementations are optimising for fast signing for NSEC3 anyway, it's not an impressive feat to transparently re-sign only those areas needed.

Fraudulent *.google.com certificate issued

Posted Sep 1, 2011 18:06 UTC (Thu) by raven667 (subscriber, #5198) [Link] (2 responses)

So are you saying that for spoofing foobix.com for example you would need a duplicate key for "foobix" signed by the real key for "com", or a duplicate "com" signed by the real root. If so then I think we are saying the same thing, either you have to get duplicates signed by the real keys or you have to spoof the whole thing from the root on down.

One difference between the existing CA infrastructure and DNS that I just thought about is that for DNS there is a lot of coordination to prevent duplicate registrations as dups are not allowed whereas there is zero technical protection from CAs signing anything they like.

Fraudulent *.google.com certificate issued

Posted Sep 1, 2011 20:49 UTC (Thu) by Comet (guest, #11646) [Link] (1 responses)

For spoofing foobix.com, you need fake keys for the root, for com. and for foobix.com. But you don't need fake keys for any domain you're not interested in, as you just sign the anchors for the legitimate keys with your key. And this signing can be done inline, at speed.

CAs can constrain themselves with nameConstraints; more commonly, a trusted CA would charge $$$ for a corporation to be able to issue their own certs without needing to go up, because the corp has scaling issues getting their own root cert onto every client device in a trusted manner, across all the vendors and contractors and the like; so example.com megacorp pays $$$ to the root CA for a basicConstraints CA:TRUE cert and the root CA preserve their income stream by making sure the newly minted CA cert has nameConstraints=permitted;DNS:*.example.com in it.

Another reason to be worried when software doesn't do any certificate chain validation, or tries to roll its own validation steps for the chain.

What's needed is constraints _outside_ the CA's control. A nameConstraints which can be applied to the CA, to keep the certs in-country and optionally warn for use outside the country, for vetting/approval (but default to block, to avoid continuing to train people to click through stuff they don't understand). What's needed is more of the steps like Google's cert-pinning, letting site operators at least get as far as the SSH security model of "latch on first use". Not ideal, but a massively reduced attack window (which can be shrunk to zero if you get the pinning into the source, rather than learnt; that then leaves "just" compromise of the browser distribution mechanism ...)

See:
http://scarybeastsecurity.blogspot.com/2011/04/fiddling-w...

Fraudulent *.google.com certificate issued

Posted Sep 1, 2011 21:47 UTC (Thu) by raven667 (subscriber, #5198) [Link]

I see, in bulk you can just strip the legit signature and replace with your own. Thank you for the patient explanation.

Distributed naming system

Posted Sep 1, 2011 20:09 UTC (Thu) by robbe (guest, #16131) [Link]

There's the namecoin system forked from and inspired by bitcoin:
https://github.com/vinced/namecoin

I don't know whether that's viable though. Bitcoin itself seems to have scaling problems if applied to something as large as current DNS.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 19:00 UTC (Tue) by butlerm (subscriber, #13312) [Link] (5 responses)

>if the government is out to get you, what makes you think you can trust the root?

Perhaps because the root is operated by an organization with no reason to tamper with it, in a country where tampering with a major domain would shortly become common knowledge and lead to major political repercussions?

Assuming the .com registry cooperated, intercepting, re-encrypting, and forwarding a large fraction of Google's HTTPS traffic would be a bit of a trick too. The only way a large government could get away with it is with Google's help, because they would probably be the first to know.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 19:12 UTC (Tue) by dkg (subscriber, #55359) [Link] (4 responses)

intercepting, re-encrypting, and forwarding a large fraction of Google's HTTPS traffic would be a bit of a trick too.

Unless, of course, the adversary is doing a more targeted attack against a specific network they happen to be upstream of.

In that case, they can ignore all the rest of the traffic, and focus their resources on compromising traffic coming out of a network segment they are interested in.

But my larger concern here isn't about Google being compromised. That's bad, but (as the current situation shows) Google actually has the resources and infrastructure to potentially catch when something is going wrong. What about smaller sites? Google vs. a medium-sized government is like King Kong vs. Godzilla. It's not clear who would win. But what if one of these titans turns their focus on small fry? Our current infrastructure suggests a sorry future for the hope of a free and autonomous global network.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 19:38 UTC (Tue) by raven667 (subscriber, #5198) [Link] (3 responses)

How does that work in practice? Wouldn't you need to have a key signed by the next highest upstream authority to make this work, or do clients not do any checking if the key for com. changes between requests? Wouldn't the only sure-fire way to do spoofing for foobix.com. be to have a shadow root with its own complete key infrastructure for all possible zones all the way down to the one that is being spoofed? You aren't going to be able to re-use any of the legitimate public key material because the trust relationships won't be compatible with the spoofed resources, right?

As long as clients don't accept the upstream keys in the hierarchy changing between requests, to spoof one child domain you have to spoof them all, right?

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 22:53 UTC (Tue) by jebba (guest, #4439) [Link] (2 responses)

I'm not certain of it, but it appears to me that x86_64 Firefox in Fedora 14/15 doesn't check the intermediate certs:
https://bugzilla.redhat.com/show_bug.cgi?id=732144

Fraudulent *.google.com certificate issued

Posted Aug 31, 2011 0:29 UTC (Wed) by cesarb (subscriber, #6266) [Link] (1 responses)

Did you check if Firefox had cached the intermediate certificates? It can make things appear to work, but when you try with another computer which has not visited yet any site which uses the same intermediate certificate, it will fail.

(I believe Firefox switched to also caching intermediate certificates because, since Internet Explorer caches intermediate certificates, a lot of people forgot to put the whole chain on their servers, and it "worked" on IE but failed - as it should - on Firefox.)

Fraudulent *.google.com certificate issued

Posted Aug 31, 2011 1:35 UTC (Wed) by jebba (guest, #4439) [Link]

Good suggestion. I believed I would have blown out my ~/.mozilla in the various tests, but I'll confirm that.

Trust the root -- trusssst it

Posted Sep 1, 2011 20:41 UTC (Thu) by robbe (guest, #16131) [Link]

How would the Iranian government (which seems to have replaced the Chinese as the traditional bad guy in these kind of plots) impersonate the root?

The only credible opponent in this game is the US government, which through coercion, legal or otherwise, openly or not (National Security letters, anyone?), could influence any of its subjects. But as I understand it the KSK can only be got at by corrupting three individuals, with most of them living outside the US of A -- see http://www.root-dnssec.org/tcr/selection-2010/ for your list of targets.

If the NSA wants to spy on your google.com traffic it is altogether more likely that they would attack com's key via rubber hose techniques, which is probably not as well-protected.

Fraudulent *.google.com certificate issued

Posted Sep 1, 2011 20:48 UTC (Thu) by job (guest, #670) [Link]

"The government" does not handle the root. ICANN does, and while they are under legislation controlled by the USA government they are very throughly watched by a number of interested parties.

Let's not go overboard with paranoia here. DNS is centralized by design, and most end users would not even notice if SSL was stripped by a DNS-forging middleman so we need to secure it anyway.

Yes, ICANN is a single point of failure in the DNSSEC system -- but we have the opportunity here to replace a system which amounts to multiple points of epic fail.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 18:49 UTC (Tue) by rickmoen (subscriber, #6943) [Link]

Both Convergence and Monkeysphere seem like respect-worthy engineering attempts. I'd really love to see a hard look at both of them by some skeptical experts, as to both usability and security design/implementation. I'll confess I haven't yet given either of them a spin, partly because I'm guessing they require some study and setup before you can get much benefit.

For now, what I've used to mitigate the risk is CertWatch, which is blessedly simple and easy to fully understand: It merely keeps records about usage of SSL certs, root CAs, and intermediate certs in a sqlite database, lets you know every time you're using a new/changed SSL cert or CA root cert or intermediate cert for the first time. So, if suddenly my online banking login for $MY_BANK has an unexpected new cert, and especially if the new cert is from a different certificate authority that doesn't look familiar, I have the opportunity and option to be doubtful about site authenticity.

Rick Moen
rick@linuxmafia.com

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 19:59 UTC (Tue) by pabs (subscriber, #43278) [Link] (4 responses)

I think Moxie Marlinspike puts this the best:

http://blog.thoughtcrime.org/ssl-and-the-future-of-authen...

"So unfortunately the DNSSEC trust relationships depend on sketchy organizations and governments, just like the current CA system."

Marlinspike

Posted Aug 31, 2011 0:50 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

To me Marlinspike's position is silly. First of all there's his rejection of scope: to Marlinspike it is apparently inconceivable that different people are authoritative about whitehouse.gov compared to mfa.gov.cn. No, any potential authority must be all-knowing, an impossible standard which just sets them up to fail like today's CAs.

Secondly his emphasis on trust "agility" that's useless to everybody but a tiny number of nerds like Marlinspike or myself. My mother isn't going to spend hours every week reconsidering her choice of authority, she isn't even going to spend ten minutes a year. She'll accept the out of box default like every other user, the same situation (and thus the same problem) as we have now.

Finally Marlinspike's confusion between the root operators and ICANN is either ignorant (in which case who cares what somebody who doesn't know the first thing about DNS thinks?) or malicious. ICANN lacks the technical capability to do what this blog entry suggests, the KSK isn't in their possession so they simply can't create the imaginary alternate key hierarchy needed for such spoofing. Manipulating ICANN is a very different thing from going after the root operators, either in the form of the corporations and other legal entities or the actual men-with-beards who perform the public key ceremonies.

Fraudulent *.google.com certificate issued

Posted Sep 1, 2011 20:54 UTC (Thu) by job (guest, #670) [Link] (2 responses)

Marlinspike's reasoning is simplified to the point of being flat out wrong. I trust my TLD a whole lot more than I trust the Chinese Internet NIC, or any of the other 1500 CAs that browsers trust today.

Fraudulent *.google.com certificate issued

Posted Sep 6, 2011 4:14 UTC (Tue) by clint (subscriber, #7076) [Link] (1 responses)

Is your TLD run by an organization not rife with incompetence, laziness, and corruption?

Fraudulent *.google.com certificate issued

Posted Sep 6, 2011 7:45 UTC (Tue) by job (guest, #670) [Link]

Absolutely. I recognize some of the technicians responsible from UNIX groups and mailing lists and I have no reason to doubt their competence.

But the point here is that I can choose which TLD I register my domains under, and trust is not implicitly delegated between them. Even if the .xxx top level domain (as a completely made up example) is run by greedy or incompetent people they can't create a mess for any one else, as opposed to the current CA model where DigiNotar can sign "CN=*.*.com".

That's is not just an implementation detail, it's a fundamental difference.

Fraudulent *.google.com certificate issued

Posted Sep 1, 2011 20:57 UTC (Thu) by sgros (guest, #36440) [Link]

Maybe the real solution is somewhere in the middle? There is golden rule in the security that nothing is secure. In essence, any cracker with enough resources (think some government) can attack any CA and issue fraudulent certificates. And nothing can be done against it.

But, it can be made harder. What do you think about using multiple CAs? In other words, browser/user requires that server's certificate is signed by two (or even more) CAs in order to be accepted as valid?

I wrote a bit about that in a short blog post. I appologize for a shameless self promotion but I wanted it to be on one more public place than this comment section. Also, I thought that I already wrote a comment but can not find it.

The patch is out

Posted Aug 30, 2011 19:17 UTC (Tue) by cesarb (subscriber, #6266) [Link] (2 responses)

According to https://bugzilla.mozilla.org/show_bug.cgi?id=682956#c18 the patch is now in the Mercurial repository (http://hg.mozilla.org/releases/mozilla-release/rev/436365...).

Interesting things from the patch (please correct me if I got anything wrong):

1. The true bug number is 682927. Looking at the preceding and following bug reports, it was created between 2011-08-29 11:59 PDT and 2011-08-29 12:05 PDT.
2. Certificates from the "DigiNotar Root CA" issued after "01-JUL-2011 00:00" are blacklisted, and the user cannot override this.
3. Certificates issued by "Staat der Nederlanden Root CA" (and which do not fall into the previous rule) are still trusted by default, according to a code comment, "By request of the Dutch government".
4. Other DigiNotar certificates are considered untrusted by default (but the user can override this according to the comments, probably the same way a user can trust a self-signed certificate).

The patch is out

Posted Aug 30, 2011 23:39 UTC (Tue) by lkundrak (subscriber, #43452) [Link]

    1.55 +    return 0; // No DigiNotor cert => carry on as normal

This is an amusing typo (?)

And the bug report is now open

Posted Aug 31, 2011 12:36 UTC (Wed) by cesarb (subscriber, #6266) [Link]

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

Fraudulent *.google.com certificate issued

Posted Sep 1, 2011 16:40 UTC (Thu) by dashesy (guest, #74652) [Link] (9 responses)

Governments have Cyber army, it only takes a rouge, irresponsible and stupid government to dare start the war. Once you have the resources and money it will be a matter of time.
This will not stop here unless sanctions become something meaningful targeting governments, not citizens of those countries.
DigiNotar put the lives of innocent people in danger to make profit, violating the sanctions.

Fraudulent *.google.com certificate issued

Posted Sep 1, 2011 17:42 UTC (Thu) by nix (subscriber, #2304) [Link] (8 responses)

DigiNotar put the lives of innocent people in danger to make profit, violating the sanctions.

Uh, DigiNotar were penetrated by attackers. They didn't simply say 'oh yes, Iranian government, of course we'll give you a certificate for *.google.com': agents probably acting for Iran attacked them and issued a certificate themselves. If they had simply acquiesced to an Iranian government request, they'd be putting innocent people in danger (though no CA should do that sort of thing on behalf of foreign governments, ha ha); if Iran was additionally subject to sanctions by the government of the Netherlands preventing all business relationships, they'd be sanctions-busters as a result.

But as far as I know Iran is not subject to such sanctions: there are EU-wide sanctions against Iranian banking and energy sectors, and diplomatic relationships are or were frozen at one point this year, but that doesn't mean that all business relationships between Iran and EU companies are verboten. (Not that there were any in this case anyway.)

Fraudulent *.google.com certificate issued

Posted Sep 1, 2011 18:13 UTC (Thu) by dashesy (guest, #74652) [Link] (6 responses)

If I read the articles correctly Google has no business relation with DigiNotar what so ever.
Also according to the public statement here:
http://www.vasco.com/company/press_room/news_archive/2011...
"On July 19th 2011, DigiNotar detected an intrusion into its Certificate Authority (CA) infrastructure, which resulted in the fraudulent issuance of public key certificate requests for a number of domains, including Google.com. "
Then it continue:
"At that time, an external security audit concluded that all fraudulently issued certificates were revoked. Recently, it was discovered that at least one fraudulent certificate had not been revoked at the time."

I cannot believe a security audit did not notice that "Google" is not their customer! I think, the company did not profit well in SSL (Euro 100,000 in the same article), so from the business point of view it would have made sense to get some extra cache from an oil rich government to issue a fake certificate that is unlikely to be used against important people in free nations.
You are right, unfortunately some European companies are less eager to deny their profitable business with rouge governments. They even happily supply internet censorship, and satellite interferer technologies to Iranian government. Without considering much about the health implications those high energy devices have specially on children and pregnant women.
The irony is that Iranians cannot update their Google Chrome because of sanctions! Of course it is Internet and there are ways to get around that, specially for technical savvies . But you see how funny it can be :)

Fraudulent *.google.com certificate issued

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

I cannot believe a security audit did not notice that "Google" is not their customer! I think, the company did not profit well in SSL (Euro 100,000 in the same article), so from the business point of view it would have made sense to get some extra cache from an oil rich government to issue a fake certificate that is unlikely to be used against important people in free nations.

I hope you're not in the UK, then, because that sort of unjustified accusation (with, am I right, no evidence whatsoever?) is just the sort of thing that gets you hit with a libel suit. (UK libel laws are notably extreme: just posting comments on websites can be and has been seen as equivalent to mass-scale publication.)

DigiNotar were terrifyingly incompetent given their role, but I see no cause to assume any malice on their part. It's not like incompetence and insecurity are unheard of in the computing industry.

Fraudulent *.google.com certificate issued

Posted Sep 2, 2011 17:19 UTC (Fri) by dashesy (guest, #74652) [Link] (4 responses)

Ok you are right, I do not have any evidence for my claim. I just raised the popular belief among Iranians.
I should confess it is hard to remain neutral and politically correct when my family and friends (and myself) could suffer from this incident. Any politically active person (or his/her family) could now be tortured to confess crimes, because of her/his emails read by government agents.

Fraudulent *.google.com certificate issued

Posted Sep 3, 2011 11:54 UTC (Sat) by raven667 (subscriber, #5198) [Link] (2 responses)

It is worth pointing out that the DigiNotar compromise may likely result in a loss of life, that is not an overreaction, highlighting how the amount of trust put into CAs is probably misplaced

Fraudulent *.google.com certificate issued

Posted Sep 3, 2011 19:52 UTC (Sat) by endecotp (guest, #36428) [Link] (1 responses)

> It is worth pointing out that the DigiNotar compromise may
> likely result in a loss of life

That would require that the supposed dissident were actually using their e.g. gmail email account to discuss incriminating matters. I consider SSL to be strong enough to protect my credit card numbers, but that's a long way from saying that I would trust my life to it. I would hope that people in that position would think very carefully about what sort of communication they would trust.

Fraudulent *.google.com certificate issued

Posted Sep 6, 2011 18:09 UTC (Tue) by dashesy (guest, #74652) [Link]

A citizen journalist (well it means an ordinary guy with a cellphone) takes a video showing violent crackdown on street unrest. Later she sends the video to Youtube, which is linked against her Gmail account. It is not exactly discussing incriminating matters. In fact government cannot arrest people for daily jokes they make about Ahmadinejad, because they may have to put everyone behind bars then.
You are right however, one should take extra precautions. No matter what the odds or reason to be arrested for, it only takes a hard enough blow to head to be considered dead. Together with a transparent proxy, a dummy Gmail account does not waist too much bits and bytes.

Fraudulent *.google.com certificate issued

Posted Sep 3, 2011 19:48 UTC (Sat) by nix (subscriber, #2304) [Link]

Ah, right. It's a reasonable popular belief: paranoia spreads like weeds under any regime like that in Iran. (Also I suspect there's some sort of paranoia field generated by Pakistan which spreads over the whole area. If you've not been there, the answer to *everything* is a conspiracy. :) )

Fraudulent *.google.com certificate issued

Posted Sep 1, 2011 20:56 UTC (Thu) by job (guest, #670) [Link]

If we are to believe the reports, DigiNotar's systems has been repeatedly breached over a course of several years without them taking action. That's bordering on criminal negligence in my opinion.