Turkish Registrar Enabled Phishing Attacks Against Google

← Back to Stories (view on slashdot.org)

Turkish Registrar Enabled Phishing Attacks Against Google

Posted by samzenpus on Thursday January 3, 2013 @01: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."

75 comments

Min score:

Reason:

Sort:

What will be the wider response to this? by Anonymous Coward · 2013-01-03 13:53 · Score: 1

The response to DigiNotar was an quick and almost-complete revocation of trust of the DigiNotar root certificate.
1. Re:What will be the wider response to this? by Anonymous Coward · 2013-01-03 14:19 · Score: 2, Informative
  
  Mozilla's response https://blog.mozilla.org/security/2013/01/03/revoking-trust-in-two-turktrust-certficates/
2. Re:What will be the wider response to this? by sabri · 2013-01-03 15:14 · Score: 2
  
  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.
  
  --
  I'm not a complete idiot... Some parts are missing.
3. Re:What will be the wider response to this? by Anonymous Coward · 2013-01-04 01:15 · Score: 0
  
  Good thing there's no shortage of certificate authorities!
Why should I have trusted these people? by Anonymous Coward · 2013-01-03 13:54 · Score: 5, Interesting

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.
1. Re:Why should I have trusted these people? by Cryacin · 2013-01-03 14:09 · Score: 1
  
  Can't fly like an eagle if you're hanging round in Turkey. (ducks)
  
  --
  Science advances one funeral at a time- Max Planck
2. Re:Why should I have trusted these people? by GiganticLyingMouth · 2013-01-03 14:25 · Score: 3, Insightful
  
  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
3. Re:Why should I have trusted these people? by hobarrera · 2013-01-03 14:39 · Score: 2
  
  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.
4. Re:Why should I have trusted these people? by Anonymous Coward · 2013-01-03 14:53 · Score: 0
  
  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.
5. Re:Why should I have trusted these people? by petermgreen · 2013-01-03 15:14 · Score: 2
  
  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 :(
  
  --
  note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
6. Re:Why should I have trusted these people? by Anonymous Coward · 2013-01-03 15:15 · Score: 0
  
  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...
7. Re:Why should I have trusted these people? by John+Hasler · 2013-01-03 15:47 · Score: 4, Insightful
  
  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.
  
  --
  Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
8. Re:Why should I have trusted these people? by TheLink · 2013-01-03 16:19 · Score: 2
  
  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/
  Makes that attack a bit harder.
  --
  
  Too many replies beneath your current threshold
9. Re:Why should I have trusted these people? by sortadan · 2013-01-03 17:22 · Score: 1
  
  Honestly curious why this is set up this way, it seems so inefficient and insecure.
  Moxie had some cool thoughts on the matter here. And tried to create an alternative Convergence.io. Video too: http://www.youtube.com/watch?v=Z7Wl2FW2TcA
10. Re:Why should I have trusted these people? by tlhIngan · 2013-01-03 17:51 · Score: 2
  
  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...
11. Re:Why should I have trusted these people? by TheLink · 2013-01-03 18:23 · Score: 1
  
  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.
  --
  
  Too many replies beneath your current threshold
12. Re:Why should I have trusted these people? by bWareiWare.co.uk · 2013-01-03 22:26 · Score: 1
  
  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.
13. Re:Why should I have trusted these people? by gessel · 2013-01-04 02:21 · Score: 2, Insightful
  
  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
14. Re:Why should I have trusted these people? by Lennie · 2013-01-04 03:51 · Score: 1
  
  Actually, the default lists (because of sub-CAs) trusts about 1200 organisations. At least that is what the EFF SSL Observatory found out.
  
  --
  New things are always on the horizon
15. Re:Why should I have trusted these people? by DaDaDaaaaa · 2013-01-04 04:19 · Score: 1
  
  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.
16. Re:Why should I have trusted these people? by Anonymous Coward · 2013-01-04 05:22 · Score: 0
  
  LOL ---you're duped by the US and Veri$ign! Why trust them? You can't even sue them for *intentional* fraud.
17. Re:Why should I have trusted these people? by nullchar · 2013-01-04 08:41 · Score: 1
  
  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.
18. Re:Why should I have trusted these people? by Bill,+Shooter+of+Bul · 2013-01-04 10:55 · Score: 1
  
  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)
  
  --
  Well.. maybe. Or Maybe not. But Definitely not sort of.
19. Re:Why should I have trusted these people? by TheLink · 2013-01-04 21:25 · Score: 1
  
  Yeah it needs to be able to track the last X certificates that you say "OK" too and don't give warnings for those.
  --
  
  Too many replies beneath your current threshold
20. Re:Why should I have trusted these people? by Anonymous Coward · 2013-01-06 02:06 · Score: 0
  
  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.
21. Re:Why should I have trusted these people? by TheLink · 2013-01-06 04:51 · Score: 1
  
  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.
  --
  
  Too many replies beneath your current threshold
root trust: the hole in PKI, SSL, TLS! by louarnkoz · 2013-01-03 13:59 · Score: 4, Interesting

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.
1. Re:root trust: the hole in PKI, SSL, TLS! by hobarrera · 2013-01-03 14:41 · Score: 2
  
  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.
2. Re:root trust: the hole in PKI, SSL, TLS! by KiloByte · 2013-01-03 15:32 · Score: 4, Informative
  
  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.
  
  --
  The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
3. Re:root trust: the hole in PKI, SSL, TLS! by Anonymous Coward · 2013-01-03 17:23 · Score: 0
  
  Shit. I trust GoDaddy about as far as I can throw them.
4. Re:root trust: the hole in PKI, SSL, TLS! by Anonymous Coward · 2013-01-03 18:14 · Score: 1
  
  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.
5. Re:root trust: the hole in PKI, SSL, TLS! by Anonymous Coward · 2013-01-03 19:29 · Score: 0
  
  java does not include all authorities.
6. Re:root trust: the hole in PKI, SSL, TLS! by Anonymous Coward · 2013-01-03 20:11 · Score: 0
  
  you want to trust DNS???
  sure, DNSSEC - but whats the coverage of that?
7. Re:root trust: the hole in PKI, SSL, TLS! by Rich0 · 2013-01-03 20:45 · Score: 2
  
  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.
8. Re:root trust: the hole in PKI, SSL, TLS! by Anonymous Coward · 2013-01-03 23:11 · Score: 0
  
  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?
9. Re:root trust: the hole in PKI, SSL, TLS! by Anonymous Coward · 2013-01-04 00:18 · Score: 1
  
  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.
10. Re:root trust: the hole in PKI, SSL, TLS! by KiloByte · 2013-01-04 02:32 · Score: 1
  
  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.
  
  --
  The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
11. Re:root trust: the hole in PKI, SSL, TLS! by KiloByte · 2013-01-04 02:51 · Score: 1
  
  You don't need to pick YOUR country's top level domain.
  
  --
  The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
12. Re:root trust: the hole in PKI, SSL, TLS! by Lennie · 2013-01-04 03:56 · Score: 1
  
  Exactly.
  
  --
  New things are always on the horizon
13. Re:root trust: the hole in PKI, SSL, TLS! by Bryansix · 2013-01-04 07:05 · Score: 1
  
  So you trust them a lot or you are a weakling? I don't get it.
TURKTRUST is not a domain registrar by lkangaroo · 2013-01-03 14:00 · Score: 1

http://www.turktrust.com.tr/en/hakkimizda.html
1. Re:TURKTRUST is not a domain registrar by Anonymous Coward · 2013-01-04 02:05 · Score: 0
  
  From your own link: "TURKTRUST is the one and only local ECSP that its root certificates are recognized to Windows Programs by Microsoft."
2. Re:TURKTRUST is not a domain registrar by lkangaroo · 2013-01-04 02:54 · Score: 1
  
  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 by vajorie · 2013-01-03 14:02 · Score: 1

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?
1. Re:Fun times by Anonymous Coward · 2013-01-03 14:34 · Score: 1
  
  Dude, it's a turkey registrar. This is revenge for the many turkeys killed every year.
2. Re:Fun times by gweihir · 2013-01-03 15:04 · Score: 1
  
  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.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
TURKTRUST's explanation by thue · 2013-01-03 14:02 · Score: 1

TURKTRUST's explanation is here: https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/aqn0Zm-KxQ0/x1hfTMGwE2AJ
1. Re:TURKTRUST's explanation by thue · 2013-01-03 14:12 · Score: 2
  
  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.
2. Re:TURKTRUST's explanation by hobarrera · 2013-01-03 14:47 · Score: 3, Insightful
  
  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.
3. Re:TURKTRUST's explanation by Rich0 · 2013-01-03 20:49 · Score: 1
  
  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?
4. Re:TURKTRUST's explanation by hobarrera · 2013-01-04 02:45 · Score: 1
  
  They should worry a lot more about privacy/not screwing up.
  One problem like this is enough to kill the company. Forever.
5. Re:TURKTRUST's explanation by Rich0 · 2013-01-07 15:23 · Score: 1
  
  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.
6. Re:TURKTRUST's explanation by Anonymous Coward · 2013-01-08 21:44 · Score: 0
  
  Then people should bring a law suit for TURKTRUST because they already got money by their poor job.
7. Re:TURKTRUST's explanation by Rich0 · 2013-01-09 03:09 · Score: 1
  
  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... by dma_packet · 2013-01-03 14:11 · Score: 0

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.. by Anonymous Coward · 2013-01-03 14:31 · Score: 0

At least they told google and they did say it's their mistake.
Multisigning by Anonymous Coward · 2013-01-03 14:35 · Score: 1

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.
1. Re:Multisigning by starfishsystems · 2013-01-03 14:42 · Score: 1
  
  X.509 doesn't have this capability. The certificate has exactly one issuer.
  
  See http://tools.ietf.org/html/rfc5280#page-20
  
  --
  Parity: What to do when the weekend comes.
2. Re:Multisigning by Chuck+Chunder · 2013-01-03 16:47 · Score: 1
  
  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.
  
  --
  Boffoonery - downloadable Comedy Benefit for Bletchley Park
3. Re:Multisigning by starfishsystems · 2013-01-03 19:36 · Score: 2
  
  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.
  
  --
  Parity: What to do when the weekend comes.
4. Re:Multisigning by gnasher719 · 2013-01-03 19:59 · Score: 1
  
  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.
5. Re:Multisigning by leuk_he · 2013-01-04 01:49 · Score: 1
  
  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 ? by Anonymous Coward · 2013-01-03 14:50 · Score: 0

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... by gweihir · 2013-01-03 15:00 · Score: 1, Insightful

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.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Why do we have this proliferation of minor CAs? by Rix · 2013-01-03 15:00 · Score: 3, Interesting

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.
1. Re:Why do we have this proliferation of minor CAs? by Anonymous Coward · 2013-01-03 16:14 · Score: 1
  
  The CA cartel is bad enough as it is, let's not give the biggest CAs even more control over the market.
2. Re:Why do we have this proliferation of minor CAs? by Anonymous Coward · 2013-01-03 19:02 · Score: 0
  
  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.
3. Re:Why do we have this proliferation of minor CAs? by Rich0 · 2013-01-03 20:53 · Score: 1
  
  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).
4. Re:Why do we have this proliferation of minor CAs? by Anonymous Coward · 2013-01-03 21:22 · Score: 0
  
  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. by Anonymous Coward · 2013-01-03 15:51 · Score: 0

Is it any surprise with the CIA training jihadist extremists in Turkey to fight in Syria that a CA gets infiltrated there?
1. Re:Didn't see that coming. by NSN+A392-99-964-5927 · 2013-01-03 22:13 · Score: 1
  
  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
  
  --
  All cows eat grass!
Restrict CA signing capacity by Anonymous Coward · 2013-01-03 18:34 · Score: 0

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 of bugs open to address this. Vote or work on them if you agree!
1. Re:Restrict CA signing capacity by Anonymous Coward · 2013-01-04 01:20 · Score: 0
  
  Why should a British company be constrained to only be able to buy certs from British CAs?
$$ how much ?? by Anonymous Coward · 2013-01-04 02:06 · Score: 0

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