Comodo Says Two More RAs Compromised 144
Trailrunner7 writes "Officials at Comodo have acknowledged that an additional two registration authorities affiliated with the company have been compromised in the wake of the high-profile attack on the company that was disclosed last week. Addressing a list of concerns about Comodo's practices raised by customers and browser vendors in the wake of the attack, Alden said that the company is now in the process of rolling out a new two-factor authentication system for its RAs. Comodo also is installing other security measures as a result of the attack."
Re: (Score:2)
The whole CA system is fundamentally broken, your browser trusts a huge list of CAs and further those CAs have the power to delegate their authority (either through signing a cert that delegates authority or by allowing those people to request certificates with little to know further checking). The result is a huge number of people who have the power to sign certificates that your browser will treat as evidence that a web site is who they say they are. Further the CAs don't really have much interest in secu
Re: (Score:3)
There is nothing wrong with the fact that many people can sign certificates. What is wrong is that there's no easy way to mark that up and control it and there are no ways to have multiple independent signing bodies. E.g. for financial transactions I would only want to trust a bank signed by an extended verification certificate from at least two registries + the government regulatory body of the country where the bank is registered. When I'm browsing slashdot I would probably be happy just to have a self
Simple solution. (Score:5, Interesting)
Store the certificates in DNS, and access them with DNSSEC.
http://blog.fupps.com/2011/02/16/ssl-certificate-validation-and-dnssec/ [fupps.com]
Re: (Score:2)
Right. Because nobody has ever hijacked a domain.
Re: (Score:2)
Re: (Score:3)
Spoofing a domain is effectively impossible, but hijacking it is not. If you can convince the registrar that you are the owner of the domain, you can change the DNS servers *and* the domain's DS records.
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
You are mistaken. DNSSEC relies on each level of the DNS hierarchy vouching for the keys used to sign records in the child zone. The root zone signs keys for com, and com signs records for example.com, including the keys used by example.com to sign www.example.com. If the keeper of com believes the domain has rightfully changed hands (or maybe an attacker figures out your password), new DNSSEC keys can be provided and the com zone will dutifully sign them, effectively transferring DNSSEC-provable ownersh
Re: (Score:2)
Very, very, very interesting... and brilliant. This solves four major problems:
With this solution you only have to trust your TLD authority and the root DNS certificate.
Lets hope this gets standardized and that DNSSEC get's rolled out for all TLD's as quick as possible.
Re: (Score:1)
I wish. Verisign and others make too much money for that to ever happen.
Re: (Score:2)
They are already doing DNSSEC-services. Would it matter to them what services they sell to people ?
Re: (Score:2)
Just to correct that, Verisign sold off their CA operations to Symantec. They don't issue certs any more.
They just control the gTLDs.
Re: (Score:2)
It will take years for this to be rolled out.
Have a look at this recent post by me:
http://slashdot.org/comments.pl?sid=2051242&cid=35598706 [slashdot.org]
Re: (Score:3)
Except you can't meaningfully have real-world identity validation without trusted third parties. The guy owning ebay-payments-this-is-real.com can generate a cert for his web server that says "eBay", but you can't trust such an assertion if the only trust you have is the DNS hierarchy.
Re: (Score:2)
True enough for the most part. However, it can be an actually trusted 3rd party rather than one of dozens of companies I've never heard of in countries whose governments I don't trust.
If my friend buys something from someone and gives me rave reviews, if he also gives me their cert fingerprint with the link, I can KNOW for a fact that I am dealing with the same entity that my friend recommended. At that point, I don't know if his name is Joe Smith or Blusdfua Ykjfuiwqhfp for certain, but I don't care becaus
Re: (Score:2)
True enough for the most part. However, it can be an actually trusted 3rd party rather than one of dozens of companies I've never heard of in countries whose governments I don't trust.
Yes, but you're still only applying that to the second-level domain. If I were to register ebay-payments-this-is-real.com, and the .com registry says my real-world identity is "Scammer", that's great. But we're delegating trust, couldn't I just create a "no-really.ebay-payments-this-is-real.com" and say that its real-world identity is "eBay"? You'd have to create a whole new system that establishes the top-level domains and which levels are authorized to make assertions about real-world identity. If I w
Re: (Score:2)
couldn't I just create a "no-really.ebay-payments-this-is-real.com" and say that its real-world identity is "eBay"?couldn't I just create a "no-really.ebay-payments-this-is-real.com" and say that its real-world identity is "eBay"?
Sure, but if you then scam my friend, instead of recommending the URL with the fingerprint of your cert, he will tell me this is a scam. You might fool Comodo, but you will not get a friend of mine to recommend your URL and fingerprint as a good place.
Sure, that makes a lot of sense. But is it practical to expect your customers to manually inspect cert fingerprints? People click through cert warnings ("I don't care, just show me the damn page") all the time without realizing the implications. I think this would be a step backward.
Those people cannot be helped. You could get them right now with a fake banking site and a self signed cert. As you say, they'll just click right through the warning. They will click through any warning on any trust system.
This doesn't have to replace the curr
Re: (Score:2)
See http://en.wikipedia.org/wiki/Startssl#StartSSL [wikipedia.org] for details. Unfortunately under XP the certificate updates are not sent out marked as important so many people won't have them installed on that OS (and perhaps Vista too?) but this only affects IE users. So if you feel safe letting some XP+IE users get certificate warning messa
Re: (Score:2)
Re: (Score:2)
Errrr... did you forget your medication or something?
Re: (Score:2, Offtopic)
I don't need a degree in psychology to see you have issues.
You post (and respond to my post with) an incoherent and rambling post that looks like a "stream of consciousness" posting from a consciousness that isn't very coherent. That's a warning sign for trouble if ever I saw one. Especially the use of bold and capitals.
If you want people to actually read your post and take it serious, stop using weird interpunction, bold, and capitalization. Try to write a few coherent sentences with a start, an end, and a
Re: (Score:2)
Do you still have Comodo CA on your browser? (Score:1, Insightful)
Re: (Score:3)
Didn't quite follow your third sentence there, but yeah, I'm de-listing Comodo and all Comodo-authorized CAs from my trusted list. We may not have perfect certificate revocation solutions, but that'll have to do for now.
How do you do that in Firefox? (Score:2)
Re: (Score:2)
Oh, I don't actually know how to do it, I was just trying to sound elite.
Some of the other posters on this topic are giving more specific instructions, give them a try.
Re: (Score:3)
Hell I'm removing all CA's from the browser as I don't trust any of them. Yes it creates a bit of an issue with some websites but all I have to do is add an exception for that site instead of blindly trusting the damn certificate.
What annoys me no end in Firefox is the fact that there is no simple way to disable all certs below a CA w/o having to disable each and everyone of them. This makes no sense. If I don't trust the Root CA then why in hell should I trust any of their subsidary CA's to be any better a
Re: (Score:2)
Hell I'm removing all CA's from the browser as I don't trust any of them. Yes it creates a bit of an issue with some websites but all I have to do is add an exception for that site instead of blindly trusting the damn certificate.
LOL. How do you verify them? Look up their phone numbers in the physical yellow pages, convince the phone monkeys that you need to talk to their CIO to have him read the cert to you letter by letter? ...for every https page every X years?
Re: (Score:2)
Ok but if you add that exception are you not blindly trusting the remote server is who it says it is? I guess you'll know if the cert changes but then what? Do you have someone at Amazon you can call ask why the cert changed before it expired or if it has really changed? Its not as if there are not plenty of totally legitimate reasons the certificate could change.
I am not saying you are wrong, I am just saying not trusting ANY CAs is not a practical option for most people.
Possibly you only use a small
Its not their fault... (Score:4, Funny)
I mean, few systems can avoid being compromised by a person with "experience of 1,000 hackers"
http://it.slashdot.org/story/11/03/28/2159202/Lone-Iranian-Claims-Credit-For-Comodo-Hack [slashdot.org]
Re: (Score:3)
Re: (Score:2)
If you liked the "with the force of 1000 suns" meme, you'll love "with the experience of 1000 hackers!"*
*Be sure to stay behind 7 proxies when hacking, and exercise caution so you don't accidentally the whole thing.
Re: (Score:2)
Make sure to do it over starbucks wifi from the safety of your bicycle and old man mask on. while you're at it, make sure to buy the laptop from craigslist and pick it up with old man mask still on. never connect it to any other network than starbucks. bounce through at least 30 proxies including those located in russia and africa. then brag about it on facebook and go to jail.
Re: (Score:2)
I dunno. If all thousand were skript kiddies, it should be easy.
Fuck... (Score:5, Insightful)
Other than inertia, is there any reason to give these guys a second chance, rather than just drop them from the default trusted CAs list and let the company sell itself for scrap? Generating SSL certs is technologically trivial, anybody can do it at home with commonly available free software. Essentially, the only purpose of a CA is to be competent and trustworthy about who they generate certs for. CAs aren't really software or technology companies, they are much closer to the position of escrow services or trust companies. Generating certs is just the minor 'paperwork'. Generating only the right certs for only the right people is the job. If they can't do that, they are worse than useless.
Re: (Score:2)
Honestly, that WOULD be the correct solution. Its not punishing them, but it does make them responsible for their choices, and thats pretty important to keep people from getting complacent or thinking they dont have to care who they choose.
Re: (Score:1)
Re: (Score:2)
It is, unfortunately, true that nuking them as a trusted CA will have some negative effects on innocent parties. However, there is essentially no form of punishment/consequences, whether leveled against a corporation or a person, that does not affect some innoc
Re: (Score:2)
Simple. Sue comodo for breach of warranty or something.
Re: (Score:3)
Other than inertia, is there any reason to give these guys a second chance
You mean, a third chance [theregister.co.uk]?
Yes, they are too big to fail [eff.org]. Hey, it worked for the banks...
Maybe CaCert [cacert.org] only needs to get 120.000 subscribers on board, and they shouldn't have to bother with that pesky audit either?
Re: (Score:2)
I would have liked to seen your second link, but it appears that EFF uses Comodo for their SSL cert.
EFF, I'd think about suing Comodo for your money back on the Cert, and get one from another company.
Re: (Score:2)
here is a plaintext link [eff.org].
Re: (Score:2)
I thought it was funny as hell. I did remove the s to read the EFF article. I have to agree, they seem to have a vested interest in keeping Comodo alive.
Re: (Score:2)
is there any reason to give these guys a second chance
Actually, a third chance. They had a similar problem a couple of years ago [slashdot.org].
(That's why I've had their certs blacklisted since then. Once a CA loses trust, it can't be restored. And it shouldn't.)
Re: (Score:2)
Once a CA loses trust, it can't be restored. And it shouldn't
How about Verisign?
http://www.microsoft.com/technet/security/bulletin/ms01-017.mspx [microsoft.com]
Verisign owns Thawte, Geotrust (which owns RapidSSL).
Re: (Score:2)
Verisign? You mean Symantec right?
Re: (Score:2)
So there'll soon be no escape from them
Re: (Score:2)
Re: (Score:3)
This isn't just a CA problem. Failure to use proper authentication is everywhere. Here's the rule of thumb you need to know regarding authentication:
If the system or data is at all important, it should be virtually impossible to access it without real two-factor authentication. A CA is important. Financial systems are important. The Administrative interfaces to your company's core systems are important.
Comodo should have required this of its customers, but more importantly, YOUR company should be requiring
Re: (Score:2)
Re: (Score:3)
Ah, but two-factor is also expensive.
That's why banks and other financial institutions have rolled out two factor abortions that are really just more passwords.
Wish it was Two-Factor [thedailywtf.com] shows how pretty much most North American banks have things set up. It's
Re: (Score:2)
Re: (Score:1)
Unfortunately, OCSP has been defeated with the character 3. [thoughtcrime.org]
Two-Factor (Score:3)
Let's just hope they're not rolling out RSA Tokens [schneier.com] :)
Re: (Score:3)
I can't wait till they roll out JRR Tolkien
Re: (Score:2)
Re: (Score:2)
That would be nine factor via eight species authentication. Should be quite effective.
Re: (Score:1)
I wouldn't trust them to quickly roll out a RSA product. With the speed, they are going to leave some holes open, and with the back-end source code probably out in the wild, it may just make the problem worse. (The source code is only going to hurt shoddy implementations of the RSA Server. People do shoddy work under time pressure).
Removed (Score:4, Insightful)
I have now removed Comodo as a trusted CA on my systems, and have advised colleagues of the three known occasions on which they have failed to act as a responsible CA. The game is up.
The Mozilla inclusion policy [mozilla.org] for maintaining CAs in the default list states that:
I hope that Mozilla now review the inclusion of Comodo's cert.
Re: (Score:2)
How about telling us mortals how to do that?
Re: (Score:3)
Well in Firefox/Seamonkey go into the security settings, Manage Certificates, Trusted Authorities and delete everything under Comodo. For IE you need to open the Windows certificate management via MMC and then do the same thing.
Re:Removed (Score:4, Informative)
And the next time Firefox is updated (which happens frequently) the Comodo certificates will be back.
For each Comodo certificate you need to click on Edit and clear all the check boxes so the certificate won't be used for anything. This change survives updates. As I pointed out in a comment the other day (for which I received many flames) this user interface is completely inadequate for managing the hundreds of certificates that ship with Firefox.
Re: (Score:2)
Select all of them and use the "Delete or distrust" button.
Re: (Score:2)
I never checked in FF3 to be honest, but they probably added it in FF4.
Just another reason to upgrade :-)
Re: (Score:2, Funny)
Derp.
Re: (Score:3)
Ah, the "you didn't ask the right question so you're too stupid for me to bother with you" approach.
No. The "you haven't provided information that anyone with half a brain might know could be useful" answer. It is like when our users raise reports along the lines of "I opened a form and got an error" to which we have to reply back with "which form?" (lest we have to test every single form for every record in the DB to see which one(s) report an error) and "what was the error?" (to which the response is almost always "I don't know" or "I didn't read it" which is bloody annoying especially in places where t
Re: (Score:1)
Re: (Score:3)
How about telling us mortals how to do that?
Mortal Mac users: Open Keychain Access, click on "System Roots", type "Comodo" in the search box, Click to unlock the "System Roots" keychain, then delete the "Comodo Certificate Authority" certificate. You'll probably have to enter your login password at some point.
Re:Removed (Score:4, Informative)
Re: (Score:2, Funny)
Mortal Kombat users: Left, left, up, right, open keychain access, right, right, right, down, Comodo, up, down, left, right and "Finish him"...
Re: (Score:2)
Re: (Score:2)
and for the mortals out there I checked this by going to Tools-->Internet Options-->Content-->Certificates--
Re: (Score:2)
Microsoft released an advisory [microsoft.com] about this subject, which also included an update [microsoft.com] to blacklist those Comodo certs (the blacklisted code-signing certs from Microsoft are from a separate incident [microsoft.com] from 2001). It rolled out over Windows Update as a critical update several days ago.
This shouldn't really be necessary, as the certs were also revoked by Comodo, and are available through their CRLs (which aren't queried by default) or by OCSP (which is). Nevertheless, the browser vendors (Microsoft in this case) are
Re: (Score:2)
I have some doubts Mozilla will drop Comodo, I think Comodo is 'to big to fail'.
My guess is they issue 1000s of certs a day, most of them are valid for a year. Those would all stop to work.
Comodo is quite lax on paperwork requirements (Score:2)
Re: (Score:2)
At the end of the day, most certificates can just be considered 'domain validated'. The 'green-bar'-certificates ('Extended Validation') ones are what used to be the what they did. Maybe they even do more with EV, but all the others are just 'domain validated'. Let's not kid ourselfs.
What does that mean ? You upload a certificate request on the site it downloads the whois-information does some automated checking from the addresses in the whois you choose which one to mail it to (or one of these: admin@domai
Re: (Score:2)
There were typically three grades of certificate in the Old Days - personal certificates (which is what you're describing), level 2 (where there were basic background checks) and level 3 (where they made the NSA's Top Secret clearance look trivial).
These days, I'd extend the range but I'd say there should be an absolute minimum level for certain types of activity and that this should be enforceable in some way. (We know damn well that if it was voluntary, every bank and retailer would still go for the perso
Re: (Score:2)
Dirt cheap ? How about free: https://www.startssl.com/ [startssl.com]
Re: (Score:2)
Dunno how expensive dirt is where you live, but it's free here. :)
Ok, yes, personal certs were offered free by Thawte and - I think - even Verisign for a bit.
Re: (Score:2)
You can use the startssl-certs for websites too btw. Not just for mail.
Re: (Score:2)
SecurID wasnt compromised, RSA was. Apparently the breach had no effect on the security of the dongles, according to RSA (and I havent seen any report to the contrary).
Re: (Score:1)
http://en.wikipedia.org/wiki/SecurID#March_2011_system_compromise [wikipedia.org]
In a March 21 email to customers, RSA essentially admitted that the information stolen from their internal network would allow an attacker to compromise a SecurID-protected system without having physical possession of the token:
"7. Have my SecurID token records been taken?
For the security of our customers, we are not releasing any additional information about what was taken. It is more important to understand all the critical components of the RSA SecurID solution.
To compromise any RSA SecurID deployment, the attacker needs to possess multiple pieces of information about the token, the customer, the individual users and their PINs. Some of this information is never held by RSA and is controlled only by the customer. In order to mount a successful attack, someone would need to have possession of all this information."
Barring a fatal weakness in the cryptographic implementation of the tokencode generation algorithm (which is unlikely, since it involves the simple and direct application of the extensively scrutinized AES-128 block cipher), the only circumstance under which an attacker could mount a successful attack having only information about (but not physical possession of) the token, is if the token seed records had been leaked. This is very strong evidence that the token seed records have in fact been stolen.
Let me google that for you (Score:2)
Re: (Score:2)
Maybe Comodo is, but not their 'resellers'
Re: (Score:2)
Yeah, I think they bought dog curtains.
Meaningless (Score:4, Insightful)
The system of "certificate authority" on which SSL security ostensibly relies, has deteriorate to an essentially meaningless state.
This system is based primarily on trust. Trust requires at least a basic level of knowledge or understanding (this is a crucial difference between "trust" and "faith" :) ).
If you have not taken a look at your browser's "trusted certificate authority list" - now may be the time. I am a Firefox user, and I know that the list in Firefox contains numerous organizations with trustworthy names like "QuoVadis Limited", "TÜRKTRUST Elektronik Sertifika Hizmet Salaycs" and "XRamp Global Certification Authority". Do you know any of these companies? Do you personally have any reason to trust in their judgment, honesty or integrity?
For each company Firefox web site holds a document by some accounting firm (like the KPMG which has proven itself untrustworthy and unreliable even in matters of finance where they presumably have a clue) that purports to audit intentions and pracitces of said company wrt. issuance of said certificates. To put it simply that's worth as much as their audit of Lehman Brothers.
Bottom line - your browser essentially allows a random selection of highest bidders or politically connected entities to define what web sites are, in turn, to be trusted. It's pointless and there is little reason to believe that anything that say, sign or claim has any value whatsoever beyond the level of background noise.
Treat SSL the way you treat SSH - save specific certificates for sites, and watch for unexpected changes. Regardless of what the certificate or the "green location bar" say, don't trust them further than you can throw them.
Re: (Score:2)
Re: (Score:2)
They may be more trustworthy than Comodo or Verisign. Problem is, you can't tell.
Re: (Score:1)
Drop them (Score:1)
They are hopeless and should be dropped from the trust lists in browsers. Watching them go out of business will be a useful remainder to the remaining ones that they should work a little not just take the money.
But what does it all mean!?! (Score:2)
Fingers crossed (Score:1)
Defense In Depth (Score:2)
However much you decide to trust the CAs your browser comes with, you can add some checks to the SSL validation process.
1. Check that others are seeing the same cert that you are.
2. Check that the cert for a site has been consistently what you're getting now.
Tools for this: Perspectives [networknotary.org] and Certificate Patrol [mozilla.org].
Example details from Perspectives check of an HTTPS site [networknotary.org]
Brief blog entry on Certificate Patrol [wordpress.com]
Re: (Score:2)