Posted on 03/23/2011 7:21:23 PM PDT by SunkenCiv
Officials at Comodo believe an attack on a registration authority (RA) emanated from Iran and may have been an attempt at monitoring users of popular Web sites.
While details of the actual breach are unclear, what is known is that on March 15, an attack hit a Comodo affiliate RA and swiped the username and password of a Comodo Trusted Partner in Southern Europe. With the stolen credentials in tow, the attacker or attackers used the compromised account to request nine digital certificates across seven domains, including: login.yahoo.com, mail.google.com, login.skype.com and addons.mozilla.org.
(Excerpt) Read more at crn.com ...
So what does this mean. Should I change my gmail passwords?
Brian Prince should go back to English 1.
BTW, you could go ahead and change your gmail passwords. If you happened to end up in a bogus imposter web site and it got your password (you probably did not), you’ll need to change it. And never click through if you get a certificate error message.
Iran is attacking Obama shills Yahoo and google? Hard to tell who the bad guy is in that one.
Microsoft also pushes out CRLs (along with updated CA certs) as part of its monthly Windows Update cycle.
Didn’t know that, thanks. Of course, you still need to have CRL checking enabled in the browser for it to do any good.
If on the first time my machine accesses mywonderfulbank.com, the request gets been intercepted by a site which has a bogus certificate, there'd be no way my machine could catch that, but if my machine had previously accessed the real mywonderfulbank.com and received a certificate, there would be no way a phony certificate could pass muster without a warning.
This is probably why Yahoo was having trouble.
bump
The setting in IE is for pull, not push.
Microsoft has already pushed the new CRL to Windows Update (http://www.microsoft.com/technet/security/advisory/2524375.mspx)
Any PC that gets important Windows Updates will get the new CRL immediately regardless of the settings in Internet Explorer.
Nice idea but unfortunately certs don't work that way.
Each cert is independently signed by a higher CA. Many companies can (and do) switch CAs for various business reasons. For example I switched my company's CA from VeriSign to Thawte to save money. Under your system my new certs would not work because the new CA does not match the old one.
In PKI circles various ideas have been kicked around about to increase trustworthyness of a cert, such as co-signing or otherwise having a 3rd party vouch for the CA that signed you. Microsoft already does this to a limited extent with Authenticode-signed device drivers, which requires a Microsoft Cross-Certificate before Windows 7 will load your 64-bit kernel code.
Is there any ability for a cert to contain multiple signatures? Obviously one needs the CA signature, but does it have to be the only one? My thought would be that security could be greatly improved if as a matter of course certificates were signed by older versions in addition to being signed by CA's. What I'd ideally like to see would be a facility by which a certificate for foo.com could contain a notation which would mean: "Foo.com has no intention of issuing, or requesting the issuance of, any certificates before 3/24/2013 which aren't signed by the public key in this certificate. Be very very very suspicious of any certificates that claim to be from foo.com but do not have such a signature. Also [optionally], if the previous certificate from foo.com had a thumbprint other than xxx, yyy, zzz, or qqq, warn the user that the previous certificate was likely bogus."
Even if someone managed to trick a CA into issuing a bogus cert for foo.com, such a bogus cert would raise red flags if someone who had previously used a valid cert tried to use a bogus one. Also, if someone who used an undetected bogus cert subsequently tried to use a valid cert, they'd get a (somewhat belated) warning of security compromise in that situation as well.
Again nice idea, but PKI does not work that way. If my business had a scum employee who ran off with a private key for one of my certs signed by my CA (dated before 3/24/2013) who handed it to hackers it before that date, it would still need some mechanism to be invalidated by a CRL to revoke the cert (even if counter-signed) prior to that date in the event of a defection of a trusted officer, with a way to issue a replacement cert.
Naturally. I don't see much alternative to that. The purpose of the extensions I want to see is to provide at least some protection against untrustworthy certificate authorities. Right now if a honestbank.com uses certificates from a really good CA, but someone figures out how to get a careless CA (who's on the "trusted" list of many browsers) to issue a certificate for honestbank.com, most browsers would accept a new certificate from the careless CA without batting an eye. I would suggest that there should be a way by which an organization should suggest that any future certs from that organization will be signed using keys whose public half is contained in the old certs.
If a hacker steals a copy of the private keys for honestbank.com, it would be necessary to publish a revocation notice. I don't see any reason the entity requesting the revocation of its key shouldn't, in almost all cases, be able to sign with the old key a notice revoking the old key and assigning a new one. Such a notice should also be signed by a CA, of course. If for some reason an organization can't sign its revocation notices or new certs using its old ones, it should be able to provide public notice of this fact, as well as a means of ensuring that a claimed cert is valid.
Depends. If your DNS thinks gmail is over by the Caspian Sea, I'd be worried.
Iran hasn't acted right since it was hit by Stuxnet.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.
