Posted
by
samzenpus
on Thursday January 03, 2013 @08:32PM
from the protect-ya-neck dept.

tsu doh nimh writes "Google and Microsoft today began warning users about active phishing attacks against Google's online properties. The two companies said the attacks resulted from a fraudulent digital certificate that was mistakenly issued by a domain registrar run by TURKTRUST Inc., a Turkish domain registrar. Google said that on Dec. 24, 2012, its Chrome Web browser detected and blocked an unauthorized digital certificate for the '.google.com' domain. 'TURKTRUST told us that based on our information, they discovered that in August 2011 they had mistakenly issued two intermediate CA certificates to organizations that should have instead received regular SSL certificates,' Google said in a blog post today. Microsoft issued an advisory saying it is aware of active attacks using one of the fraudulent digital certificates issued by TURKTRUST, and that the fraudulent certificate could be used to spoof content, perform phishing attacks, or perform man-in-the-middle attacks against virtually any domain. The incident harkens back to another similar compromise that happened around the same time-frame. In September 2011, Dutch certificate authority Diginotar learned that a security breach at the firm had resulted in the fraudulent issuing of certificates."

I know this must sound Xenophobic, but I have gone into the SSL certs list lately and disabled a bunch I would never trust. Turkish, Russian, etc.

Some of them I was frankly surprised that Mozilla, Google, Microsoft, Apple etc would trust. There are literally a few hundred in most devices. Who vets them? Also shouldn't there be a better way then for a user to wade through hundreds of certs (some in languages they dont know).

Honestly curious why this is set up this way, it seems so inefficient and insecure.

Honestly curious why this is set up this way, it seems so inefficient and insecure.

Hah, welcome to the internet. But seriously though, a lot of the protocols in use weren't designed with the current form of the internet in mind, so looking at them now it's almost amazing that the internet is as functional as it is. The web is built on trust, which made sense back in its infancy. Not quite as much anymore however.
for example, just a few months ago google was effectively inaccessible to a portion of the world, entirely by accident [arstechnica.com]

Following that line of thought, why should the rest of the world trust US-based CAs?I mean, I'm pretty sure the NSA and a couple of other agencies can request that CAs emit certificates to them and force them to keep their mouth shut about it.

If you are dealing in state secrets you shouldn't trust any CA. If, on the other hand, you just want to keep thieves from cleaning out your bank account you needn't worry about any major government: they have more direct ways of getting your money.

I do too, but it's a pain for *.google.com and similar properties, because they have concurrently use certs from two or more CAs. Thus when bouncing between random webservers for google, the cert appears to change. Trusting even the CA doesn't help as the CAs change. So I just look at the CAs themselves and the dates and sometimes investigate the details like key size and TLS mentions and email address; things a sloppy attacker may miss if they're trying to MITM me.

It's a matter of the odds. It's unlikely you are being MITMed the first time you use it.It's when your bank's or email provider's cert changes a bit too early, or to one from a different CA, then you should choose to not to log in till you can confirm that everything is ok.

I don't care about the google problem much since I don't really use gmail and people are free to MITM my search results. Maybe one day I'll see if I can fix Certificate Patrol so that it works better with rotating certificates, if the dev

I think that's the wrong line of thought which isn't very productive. I think the correct observation is that the end user isn't given an importunity to select what level of trust they want to have in which CA's by default.

It would make more sense upon instillation of a browser/os/whatever to select how trustworthy you want to be, with the following selections:

Trust most popular CA's.Trust most Trusted CA'sTrust regionally trusted CA'sTrust all CA's that are globally trusted ( the default right now)

Honestly curious why this is set up this way, it seems so inefficient and insecure.

I remember watching a video on it somewhere and iirc at the time the main concern when https was introduced was evesdropping and protection against MITM attacks was very much an afterthought.

By the time everyone realised that the model of having CAs whose financial interests are to issue a cert without asking too many questions and any one of which could declare a server trusted to serve content for a url was fundamentally broken it was too late to do much about it:(

I know this must sound Xenophobic, but I have gone into the SSL certs list lately and disabled a bunch I would never trust. Turkish, Russian, etc.

Some of them I was frankly surprised that Mozilla, Google, Microsoft, Apple etc would trust. There are literally a few hundred in most devices. Who vets them? Also shouldn't there be a better way then for a user to wade through hundreds of certs (some in languages they dont know).

Honestly curious why this is set up this way, it seems so inefficient and insecure.

Just go to Firefox's config stuff and "untrust" the CAs you don't trust.It's much harder to do this in IE because IE does not come with a full list of all the root CAs they will trust. CA's can get added automatically as long as a trusted CA has signed them.

That said in practice there's not a big difference since many major CAs sign other CA's certificates. So if you trust Entrust, you can end up trusting CNNIC (China's main CA).

I just use stuff like Certificate Patrol. However it does need to be cleverer a

How many of they ones that happened to be based in countries you trust have signed intermediary certificates for people you don't. No way of knowing, even Google/Mozilla/Microsoft don't know.The entire concept of security pegged on a few central authorities is naive.

The certificate system is badly broken on a couple of levels. Most obvious and relevant to the OP is that there are 650 root CAs that can issue certs, including some state-run CA's by governments with potentially conflicting political interests or poor human rights records.

It is useful to think about what we use SSL certs for:

1) Establishing an encrypted link between our network client and a remote server to foil eavesdropping and surveillance.

Everybody thinks that if an "https" connection is securely established, if the browser displays a green light, then they are good. But it only proves that the other end of the connection showed a "valid" certificate, where "valid" is defined a "signed by one of the hundreds of authorities allowed to do so, or by any entity who somehow obtained a certificate with signing rights from one of these authorities."

We have seen attacks like that before, e.g. the "Comodo" hacker (http://arstechnica.com/security/2011/09/comodo-hacker-i-hacked-diginotar-too-other-cas-breached/). My bet is that we will continue to see more of these, because the attack surface is just too large.

HTTPS really means "probably more secure than plain text".Regardless of it's efficiency, TLS/SSL/PKI is the best thing we've got, sadly. I've yet to see a mechanism that can replace it. A few can complement it, but that's just about it.

What you want is DANE. Sadly it's hardly supported in browsers at all yet, but it allows throwing out all the CA crap, replacing them with just three parties to trust: ICANN, your country's DNS registry, and your registrar.

But "fix my country's DNS registry" is an achievable goal, and so is "Move to a country whose DNS registry isn't fucked". Whereas "Fix all of the hundreds of tinpot CAs from everywhere in the entire world" is a game of whack-a-mole that we've been losing for more than a decade.

The irony is that plain text never pops up a security warning, but SSL does if the certificate isn't trusted. There is no attack that can be mounted on an untrusted SSL certificate that can't be mounted on plain text, and the latter is susceptible to additional attacks.

Way to make it sound like this was intentional etc. I guess Diginotar too enabled an attack on Google, eh?

I think these people just do not want to see that the certificate system is broken by a design that ignores the constraints of the real world. It is rather obvious that you cannot trust hundreds of organizations to do this right all the time. The certificate system was designed and implemented by people that either do not understand the real world or did not care because they saw a commercial opportunity. Turktrust is just a victim of random chance, and at least they found out what went wrong. Not that anyt

In summary, they claim that a testing profile (which creates intermediate certificates) on a test system were accidentally copied to a production system, and in effect for two days. The MitM *.google.com cert is claimed to be have been automatically issued by a Checkpoint firewall once a CA cert is installed, without intention from the owner of the accidental CA cert.

Agreed. The problem is that CAs are generally for-profit companies and they're optimized for making money. That usually means issuing the largest number of certificates in the least amount of time for the least amount of effort. They also have no inherent interest in privacy, so don't expect them to stand up to any kind of pressure to sign certificates for anybody who has influence over them (governments mostly, but that could also include insiders and partners).

True, but the capital requirements for a CA are pretty darn low. So, if things go badly just declare bankruptcy, sell a copy of your procedures to a "new" company (with the same employees), and apply for WebTrust/etc. Sure it will set you back a few months, but it isn't like you have to buy factories and all that nonsense to start over.

The people who paid them aren't the people who got hurt by their poor performance. Sure, those who bought certificates that are still valid might be able to get a refund for the time left after they're de-listed. However, most of the damage was to the Internet at large, who was exposed to risk by somebody they don't even do business with.

A certificate can (obviously) only have one issuer.
What he's suggesting is having multiple certificates corresponding to one private key.

This seems like an eminently sensible idea. Part of the problem is that the Certifying Authorities get "too big to fail" and it takes something pretty massive for a CA to have their authority revoked as doing so impacts a lot of users.

If sites (at least those interested enough in HA to preemptively guard against the invalidation of a CA) could back their keys with mult

What he's suggesting is having multiple certificates corresponding to one private key.

Ah, interesting. Having generated the key pair, you submit the public key as a cert signing request to multiple CAs. Then you would have a hot spare if one of the certs was revoked. It seems like a worthwhile idea.

But that's not what he's suggesting. You will end up with multiple server certs all right, but there is no way for a client to know that, so it can't undertake to validate all of them, which is specific

This seems like an eminently sensible idea. Part of the problem is that the Certifying Authorities get "too big to fail" and it takes something pretty massive for a CA to have their authority revoked as doing so impacts a lot of users.

I wouldn't say any CA is "too big to fail". If Microsoft, Apple, Google, and Mozilla remove your root certificates, you are gone. And they can go beyond removing your root certificates; they can hardcode revocation of your root certificate into the SSL stack.

The big problem would be: what if one of the 2 signatures fails? Trust one? Only trust if one signature is correct and that it contains what the other signature should be?

And don't forget that a signature does not say that a site is secure. It only says that the site is who it says it is. It can still do evil things, and if it does it still might be very hard to track who the evil site is.

They at least they were able to find out what happened. I bet not all CAs can do that. No, the problem is that when you have hundreds of organizations, some will make mistakes. Especially when they are basically all commercial and feel the cost-pressure that comes with that. And some of these mistakes will get exploited by people that may or may not have contributed to the accident in the first place.

No, the problem is not incidents like this one. The problem is that when you have more than, say, 10 people

They shouldn't have been issuing certificates trusted by default anyway. Pare down the CA list included by default in browsers since so many of them are no more authoritative than self signed certificates anyway. If someone wants to trust TURKTRUST, let them import them themselves. The vast majority has absolutely no reason to.

You don't need a lot of personnel or resources to run a CA. You mainly just need to be meticulous. The problem is that they get greedy and automate the living daylights out of everything, leading to situations like this.

Certificates sell for on the order of $100, so you can easily just pay for background checks, etc. You could have an employee spend an hour on every single certificate/renewal and easily come out ahead. The problem is that these companies instead try to spend about a minute of human effo