×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Turkish Registrar Enabled Phishing Attacks Against Google

samzenpus posted about a year ago | from the protect-ya-neck dept.

Google 75

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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

75 comments

What will be the wider response to this? (1)

Anonymous Coward | about a year ago | (#42470451)

The response to DigiNotar was an quick and almost-complete revocation of trust of the DigiNotar root certificate.

Re:What will be the wider response to this? (2)

sabri (584428) | about a year ago | (#42471127)

The response to DigiNotar was an quick and almost-complete revocation of trust of the DigiNotar root certificate.

And the response to that was that Diginotar went bankrupt [wikipedia.org].

Re:What will be the wider response to this? (0)

Anonymous Coward | about a year ago | (#42474159)

Good thing there's no shortage of certificate authorities!

Why should I have trusted these people? (5, Interesting)

Anonymous Coward | about a year ago | (#42470455)

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.

Re:Why should I have trusted these people? (1)

Cryacin (657549) | about a year ago | (#42470607)

Can't fly like an eagle if you're hanging round in Turkey. (ducks)

Re:Why should I have trusted these people? (3, Insightful)

GiganticLyingMouth (1691940) | about a year ago | (#42470737)

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]

Re:Why should I have trusted these people? (2)

hobarrera (2008506) | about a year ago | (#42470841)

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.

Re:Why should I have trusted these people? (0)

Anonymous Coward | about a year ago | (#42470959)

You know, I've often thought on this issue, and it is one of the reasons I personally use half a dozen different self signed certs.

But -- I have an answer for you, compared to the rest of the world. Not a great answer, but better than none.

Because of our first amendment. Backed by our second.

It doesn't count for anything if we comply with requests. And I'm sure the NSA or other groups could plant an agent to spoof them -- I'm sure other intelligence agencies have and will try.

But quite simply -- you can trust us more than Turkey because if somebody finds out, they can go to the new york times with it.

That's all I can give you.

Re:Why should I have trusted these people? (0)

Anonymous Coward | about a year ago | (#42471137)

I don't know about the NSA, but I would contend the logic is still sound. I wouldn't expect anyone from Turkey to trust US certs. But really what I want to know is whether there is a better way...

Re:Why should I have trusted these people? (4, Insightful)

John Hasler (414242) | about a year ago | (#42471371)

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.

Re:Why should I have trusted these people? (2)

TheLink (130905) | about a year ago | (#42471631)

They shouldn't automatically trust them.

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.

I use Certificate Patrol: https://addons.mozilla.org/en-us/firefox/addon/certificate-patrol/ [mozilla.org]
Makes that attack a bit harder.

Re:Why should I have trusted these people? (1)

nullchar (446050) | about a year ago | (#42479737)

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.

Re:Why should I have trusted these people? (1)

TheLink (130905) | about a year ago | (#42486199)

Yeah it needs to be able to track the last X certificates that you say "OK" too and don't give warnings for those.

Re:Why should I have trusted these people? (0)

Anonymous Coward | about a year ago | (#42495027)

I've installed Certificate patrol, but it gives me notifications all the time about certificates changing, and I really don't know what I should be looking for to verify if it is genuine or not.

Re:Why should I have trusted these people? (1)

TheLink (130905) | about a year ago | (#42496159)

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 developers don't get around to fixing it by then.

Re:Why should I have trusted these people? (1)

Bill, Shooter of Bul (629286) | about a year ago | (#42481793)

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's
Trust regionally trusted CA's
Trust all CA's that are globally trusted ( the default right now)

Re:Why should I have trusted these people? (2)

petermgreen (876956) | about a year ago | (#42471133)

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 :(

Re:Why should I have trusted these people? (1)

sortadan (786274) | about a year ago | (#42472147)

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

Moxie had some cool thoughts on the matter here [thoughtcrime.org]. And tried to create an alternative Convergence.io. Video too: http://www.youtube.com/watch?v=Z7Wl2FW2TcA [youtube.com]

Re:Why should I have trusted these people? (1)

DaDaDaaaaa (2720359) | about a year ago | (#42476083)

Unfortunately, development for it has been abandoned for a while, and a good chunk of the time, the SSL notaries will be down, leading to tons of false warnings about invalid certificates.

Re:Why should I have trusted these people? (2)

tlhIngan (30335) | about a year ago | (#42472335)

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.

Well, the question is - what if you're Turkish? Or Russian? Or <other_country>?

Does that mean you have to ask Mozilla to produce a special version of FireFox for Russia with the Russian CAs in it? Ditto everyone else? I'm sure the Turks or the Russians have to use certificates issued by their national CAs.

I suppose it would be handy, to go to the Firefox download page and have to answer 20 questions to figure out what OS you want, what language you want, and what CAs you want to trust, then click Download to get that specific version. (Hell, most people would probably click "Select All" and then Download and be done with it).

Of course, life would be so much simpler if we could just ignore everything except en-us. Dealing with unicode encodings is hard enough, let's just use ASCII and declare everyone else should too...

Re:Why should I have trusted these people? (1)

TheLink (130905) | about a year ago | (#42472521)

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 about sites that rotate amongst a bunch of certs.

Restrict CA signing capacity (0)

Anonymous Coward | about a year ago | (#42472577)

Until there's a good replacement for the CA system, we need a way of restricting the span of control many of these authorities have so that any damage they cause can be contained, using the principle of least privilege.

Why should a Turkish or US Government Certificate Authority have the ability to sign .uk, .ca or .mx domains? (.com is a little more complicated since it's not geography-specific)

It looks like Mozilla has a couple [mozilla.org] of bugs [mozilla.org] open to address this. Vote or work on them if you agree!

Re:Restrict CA signing capacity (0)

Anonymous Coward | about a year ago | (#42474185)

Why should a British company be constrained to only be able to buy certs from British CAs?

Re:Why should I have trusted these people? (1)

bWareiWare.co.uk (660144) | about a year ago | (#42473459)

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.

Re:Why should I have trusted these people? (2, Insightful)

gessel (310103) | about a year ago | (#42474755)

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.

2) To verify that the remote server is who we believe it to be.

Problem 1 is by far the most important, so much more important than number 2 that number 2 is almost irrelevant, and fundamental flaws with feature 2 in the current CA system make even trying to enforce verification almost pointless. Most users have no idea what SSL verification actually means or what any of the cryptic (no pun intended) and increasingly annoying alerts warning of "unvalidated certs" mean anyway.

What I find most annoying is that the extraordinary protective value of SSL encrypted communication is systematically undermined by browsers like Firefox in an intrinsically useless effort to convince users to care about verification. I have never, not once, ever not clicked through the warnings on a web site to access it. And even though I often access web sites from areas that are suspected of occasionally attempting to infiltrate dissident organizations with MITM attacks, I still have yet to see a legit MITM attack in the wild myself. But I do know for sure that without SSL encryption my passwords would be compromised - how many of us get spam from friends with Yahoo accounts? Yahoo still does not SSL encrypt login by default and so accounts are regularly compromised by spammers. Encryption really matters and is really important to keeping communication secure. Anything that adds friction to encryption should be rejected.

Self-signed certs and community certs (like CACert.com) should be accepted without any warnings that might slow down a user at all so that every website, even non-commercial or personal ones have no disincentive to adding encryption. HTTPSEverywhere. Routers should be configured to block non-SSL traffic (and HTML email, but that's another rant. Get off my lawn.).

Verification is unsolvable with SSL certs for a couple of reason, some due to the current model, some due to reasonable human behavior, some due to relatively legitimate law-enforcement concerns:

Obviously the OP makes clear that the current model is badly broken because the vast majority of issuing companies have every reason to minimize the cost of providing a cert which means cutting operational costs and increasing the risk of human error. Though even at a well run notary, human error is likely to occur, especially as notaries in different countries, speaking different languages can issue certs for companies in any other location. Certificate issuance by commercial entities is fail. A simple error can, because registrar certs are by default trusted, compromise anyone in the world. One mistake, everybody is at risk. Pinning does not actually reduce this risk in advance, though rapid response to discovered breaches can limit the damage.

But even if issuance were fixed, it wouldn't necessarily help. Most people would happily click through to www.bankomerica.com without thinking twice. Indeed, as companies may have purchased almost every spelling variation and point them all toward their "most reasonable" domain name, it isn't unreasonable to do so. If bankomerica.com asked for a cert in tashkent, would the (or even should they) be denied? No - green bar, wrong site. Even if they were non-SSL encrypted, it isn't practical to typo-test every legit URL against every possible fake, the vast majority of users would never notice if their usual bank site came up unencrypted (no cert at all). This user behavior limitation fundamentally obviates the value of certs for identifying sites. But even a typo-misdirection is assuming too much - all of my phishing spam uses brand names in anchortext leading to completely random URLs, rarely even reflective of the cover story, the volume of which suggests this is a perfectly viable attack. This user problem is mostly an issue for average users and below, but (hopefully) less so for dissidents or political activists in democracy challenged environments that may be subject to MITM attacks because (one hopes) they might actually pay attention to cert errors or use perspectives or crossbear. User education can help, but in the end you can't really solve the stupid user problem. If people will send bank details to Nigeria to assist in the transfer of millions to help a nationality abandoned astronaut expatriate his back pay, there is no way to educate them on the difference between https://www.bankofamerica.com/ [bankofamerica.com] and http://www.bankomerica.com./ [www.bankomerica.com] The only viable solution is distributed trust as implemented by GPG (explicit chain of trust) or Perspectives (wisdom of the masses); both of these seem infinitely more reliable than trusting any certificate registry, whether national or commercial and both escape the cert mafia by obviating the need for a central authority and the overhead entailed.

Further, law enforcement makes plausible arguments for requiring invisible access to communication. Ignoring the understandable preference for push-button access without review and presuming that sufficient legal barriers are in place to ensure such capabilities protect the innocent and are only used for good, it is not rational to believe that law enforcement will elect to give up on demanding lawful intercept capabilities. Such intercept is currently enabled by law enforcement certificates which permit authorized MITM attacks to capture encrypted data without tipping off the target of the investigation. Of course, if the US has the tool, every other country wants it too. Sooner or later, even with the best vetting, there is a regime change and control of such tools falls into nefarious hands (much like any data you entrust to a cloud service will sooner or later be sold off in an asset auction to whoever can scrape some residual value out of your data under whatever terms they way, but that too is a different rant). Thus it is not reasonable for activists in democracy challenged environments to assume that SSL certs are a secure way to ensure their data is not being read. Changing the model from intrinsic, automatic trust of authority to a web-of-trust model would substantially mitigate the risk of lawful intercept certs falling into the wrong hands, though by making such certs useless or far harder to implement (LE would have to go to specific sites to get either a cert copy or to directly gather decrypted traffic, which would tend to favor US-based LE over foreign entities that might have a harder time convincing a US-based company to give up user data, though big cloud players with an international presence don't have a choice about this).

There is no perfect answer to verification because remote authentication is Really Hard. You have to trust someone and the current model is to trust all or most of the random, faceless, profit or nefarious motive driven certificate authorities. Where verification cannot be quickly made and is essential to security, out of band verification is the only effective mechanism. Sadly, the effort to prop up verification has made at the compromise of encryption, most recently Gmail rejecting self-signed certs for POP. That's insanely stupid. False security is being promoted at the expense of real security.

Re:Why should I have trusted these people? (1)

Lennie (16154) | about a year ago | (#42475747)

Actually, the default lists (because of sub-CAs) trusts about 1200 organisations. At least that is what the EFF SSL Observatory found out.

Re:Why should I have trusted these people? (0)

Anonymous Coward | about a year ago | (#42476989)

LOL ---you're duped by the US and Veri$ign! Why trust them? You can't even sue them for *intentional* fraud.

Another word (-1)

Anonymous Coward | about a year ago | (#42470505)

Dont trust anything from Google?

root trust: the hole in PKI, SSL, TLS! (4, Interesting)

louarnkoz (805588) | about a year ago | (#42470507)

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.

Re:root trust: the hole in PKI, SSL, TLS! (2)

hobarrera (2008506) | about a year ago | (#42470853)

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.

Re:root trust: the hole in PKI, SSL, TLS! (4, Informative)

KiloByte (825081) | about a year ago | (#42471265)

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.

Re:root trust: the hole in PKI, SSL, TLS! (0)

Anonymous Coward | about a year ago | (#42472167)

Shit. I trust GoDaddy about as far as I can throw them.

Re:root trust: the hole in PKI, SSL, TLS! (1)

Anonymous Coward | about a year ago | (#42472469)

The problem with that is many countries DNS registrars are run even more poorly than CA based system that need fixing, going from one busted system to another doesn't solve anything.

Re:root trust: the hole in PKI, SSL, TLS! (1)

Anonymous Coward | about a year ago | (#42473867)

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.

Re:root trust: the hole in PKI, SSL, TLS! (0)

Anonymous Coward | about a year ago | (#42472991)

you want to trust DNS???
sure, DNSSEC - but whats the coverage of that?

Re:root trust: the hole in PKI, SSL, TLS! (0)

Anonymous Coward | about a year ago | (#42473617)

The DNS registrars make TURKTRUST seem like fort knox, why the hell would anyone want to go from one lot of incompetent arseholes to an even worse lot?

Re:root trust: the hole in PKI, SSL, TLS! (1)

KiloByte (825081) | about a year ago | (#42474865)

The DNS registrars make TURKTRUST seem like fort knox, why the hell would anyone want to go from one lot of incompetent arseholes to an even worse lot?

You can select the best registrar, and others can't harm you. With CAs, you're only as secure as the worst CA out of a few hundred.

Re:root trust: the hole in PKI, SSL, TLS! (2)

Rich0 (548339) | about a year ago | (#42473095)

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.

The whole system is in massive need of replacement.

Re:root trust: the hole in PKI, SSL, TLS! (0)

Anonymous Coward | about a year ago | (#42472801)

java does not include all authorities.

TURKTRUST is not a domain registrar (1)

lkangaroo (2663383) | about a year ago | (#42470519)

Re:TURKTRUST is not a domain registrar (0)

Anonymous Coward | about a year ago | (#42474555)

From your own link: "TURKTRUST is the one and only local ECSP that its root certificates are recognized to Windows Programs by Microsoft."

Re:TURKTRUST is not a domain registrar (1)

lkangaroo (2663383) | about a year ago | (#42475131)

From your own link: "TURKTRUST is the one and only local ECSP that its root certificates are recognized to Windows Programs by Microsoft."

Yes, but you don't have to be a domain registrar to be a CA. And in this case, TURKTRUST is just a CA, not a registrar.

Fun times (1)

vajorie (1307049) | about a year ago | (#42470531)

Fun times when I can actually see ./ turn slowly but surely into CNN / Fox. Way to make it sound like this was intentional etc. I guess Diginotar too enabled an attack on Google, eh?

Re:Fun times (1)

Anonymous Coward | about a year ago | (#42470799)

Dude, it's a turkey registrar. This is revenge for the many turkeys killed every year.

Re:Fun times (1)

gweihir (88907) | about a year ago | (#42471045)

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 anything can be done to fix the larger issues.

TURKTRUST's explanation (1)

thue (121682) | about a year ago | (#42470533)

Re:TURKTRUST's explanation (2)

thue (121682) | about a year ago | (#42470645)

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.

So TURKTRUST claims it has all been an accident.

Re:TURKTRUST's explanation (3, Insightful)

hobarrera (2008506) | about a year ago | (#42470897)

I don't really care if it was on purpose or an accident. They clearly cannot be trusted as an Authority in security is they make this kind of mistakes.

Re:TURKTRUST's explanation (1)

Rich0 (548339) | about a year ago | (#42473109)

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).

It isn't that hard to make a very strong CA. The problem is that doing a good job takes a fair bit of manual effort. For the prices they're charging the CAs can easily afford to expend this effort, but why bother when they can just have some software churn out certificates on demand and make even more money?

Re:TURKTRUST's explanation (1)

hobarrera (2008506) | about a year ago | (#42475009)

They should worry a lot more about privacy/not screwing up.
One problem like this is enough to kill the company. Forever.

Re:TURKTRUST's explanation (1)

Rich0 (548339) | about a year ago | (#42514279)

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.

Re:TURKTRUST's explanation (0)

Anonymous Coward | about a year ago | (#42529821)

Then people should bring a law suit for TURKTRUST because they already got money by their poor job.

Re:TURKTRUST's explanation (1)

Rich0 (548339) | about a year ago | (#42532055)

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.

Like Clockwork... (2)

dma_packet (2804603) | about a year ago | (#42470623)

With Google's total victory in the FTC matter one only had to wait for the inevitable anti-Google fanboy tantrum submissions to start hitting Slashdot...

At least.. (0)

Anonymous Coward | about a year ago | (#42470785)

At least they told google and they did say it's their mistake.

Multisigning (1)

Anonymous Coward | about a year ago | (#42470807)

Why don't browsers require certificates to be signed by two (or more) independent authorities? That wouldn't eliminate this kind of attack, but it would make it significantly harder.

Re:Multisigning (1)

starfishsystems (834319) | about a year ago | (#42470871)

X.509 doesn't have this capability. The certificate has exactly one issuer.

See http://tools.ietf.org/html/rfc5280#page-20 [ietf.org]

Re:Multisigning (1)

Chuck Chunder (21021) | about a year ago | (#42471869)

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 multiple certs that would be very useful.

Re:Multisigning (2)

starfishsystems (834319) | about a year ago | (#42472833)

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 specifically what he's suggesting would be a useful safeguard for the client. He requires an and operation and you're proposing an or. Nor is it useful to add some capability to assert multiple certs. If one of the certs is compromised, that's the one which a rogue server will assert is the only one. His proposal requires integrity of a single cert with respect to multiple signers, and X.509 doesn't provide for that.

It's not impossible in principle. Given a sufficiently large key pair, you could split the public key into pieces and have each CA sign one of them. Only if all certs validate will the client concatenate the complete public key and use it perform a handshake with the server. But it's not X.509 and I think we still have the problem of how the client is supposed to know to do this.

Re:Multisigning (1)

gnasher719 (869701) | about a year ago | (#42472935)

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.

Re:Multisigning (1)

leuk_he (194174) | about a year ago | (#42474409)

Beside the fact that this technically is not yet implemented.

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.

And even then the browser implementation to handle failures is broken. You can add an exception, but you have almost no data to tell if that is a good action or not.

Consequences ? (0)

Anonymous Coward | about a year ago | (#42470927)

TURKTRUST Inc. should lose all abilities to sign certificates and should lose their CA privileges, there has to be consequences for this type of crap.

Does not matter that it is turkish... (1, Insightful)

gweihir (88907) | about a year ago | (#42471011)

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 you need to trust implicitly for such a system to work, then you are screwed. But it is not 10 people, it is 10 organizations, and the circumstances are massively geared towards "cheap", not towards "trustworthy". The certificate system is one more thing developed by academics that do not understand the real world, and then implemented by businesses that only care about making a buck and not concerned whether this could actually be done right or not.

The result is that today, you can basically trust your own certificates, maybe those created by your own organization, and only those external ones you verified directly. That will not change, as it is not a technology problem.

Why do we have this proliferation of minor CAs? (3, Interesting)

Rix (54095) | about a year ago | (#42471019)

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.

Re:Why do we have this proliferation of minor CAs? (1)

Anonymous Coward | about a year ago | (#42471579)

The CA cartel is bad enough as it is, let's not give the biggest CAs even more control over the market.

Re:Why do we have this proliferation of minor CAs? (0)

Anonymous Coward | about a year ago | (#42472685)

I agree with you. There are too many trusted root CAs and we have no idea why should we trust them in the first place. Who knows about those companies? How do they operate, how many employees do they have, how much do they invest in security... There are many unanswered questions like these.
I personally know at least two of these companies and I know that they are not good enough to protect the security of the entire human population. (Failure of one of them risks the entire world) They have only a few personnel, poor physical security, not enough financial resources to invest in new technology etc etc.

Re:Why do we have this proliferation of minor CAs? (1)

Rich0 (548339) | about a year ago | (#42473133)

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 effort on each one so that they can pocket more money (auto-renewals, automated checks, etc).

Re:Why do we have this proliferation of minor CAs? (0)

Anonymous Coward | about a year ago | (#42473227)

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 effort on each one so that they can pocket more money (auto-renewals, automated checks, etc).

$100 ? I think not. Drop a zero. Or more if you can use StartSSL.

Didn't see that coming. (0)

Anonymous Coward | about a year ago | (#42471419)

Is it any surprise with the CIA training jihadist extremists in Turkey to fight in Syria that a CA gets infiltrated there?

Re:Didn't see that coming. (1)

NSN A392-99-964-5927 (1559367) | about a year ago | (#42473417)

Is it any surprise with the CIA training jihadist extremists in Turkey to fight in Syria that a CA gets infiltrated there?

You are absolutely right! We know about CIA dirty tricks, hence I have been fucking General Petraeus's wife whilst he was having an affair..... Welcome to the FBI

$$ how much ?? (0)

Anonymous Coward | about a year ago | (#42474563)

How does much turktrust charges it's fraudulent certificates? I want a bootload.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...