Comodo Group Issues Bogus SSL Certificates

This isn’t good:

The hacker, whose March 15 attack was traced to an IP address in Iran, compromised a partner account at the respected certificate authority Comodo Group, which he used to request eight SSL certificates for six domains: mail.google.com, www.google.com, login.yahoo.com, login.skype.com, addons.mozilla.org and login.live.com.

The certificates would have allowed the attacker to craft fake pages that would have been accepted by browsers as the legitimate websites. The certificates would have been most useful as part of an attack that redirected traffic intended for Skype, Google and Yahoo to a machine under the attacker’s control. Such an attack can range from small-scale Wi-Fi spoofing at a coffee shop all the way to global hijacking of internet routes.

At a minimum, the attacker would then be able to steal login credentials from anyone who entered a username and password into the fake page, or perform a “man in the middle” attack to eavesdrop on the user’s session.

More news articles. Comodo announcement.

Fake certs for Google, Yahoo, and Skype? Wow.

This isn’t the first time Comodo has screwed up with certificates. The safest thing for us users to do would be to remove the Comodo root certificate from our browsers so that none of their certificates work, but we don’t have the capability to do that. The browser companies—Microsoft, Mozilla, Opera, etc.—could do that, but my guess is they won’t. The economic incentives don’t work properly. Comodo is likely to sue any browser company that takes this sort of action, and Comodo’s customers might as well. So it’s smarter for the browser companies to just ignore the issue and pass the problem to us users.

Tags: , , , , , , , , , , , , ,

Posted on March 31, 2011 at 7:00 AM • 93 Comments

Comments

Chris • March 31, 2011 7:09 AM

How is removing the Comodo CA from your browser the safest thing to do?
Looking at the steps in your book “Beyond Fear”, this introduces new vulnerabilities. If you don’t have the Comodo CA in your browser, you will not be able to verify other certificates of sites which are legitimately using Comodo. Thus, an attacker will be able to MITM your connections to those sites.
Removing the CA would only work if all it’s customers migrate to a different CA…

Chris • March 31, 2011 7:14 AM

“The safest thing for us users to do would be to remove the Comodo root certificate from our browsers so that none of their certificates work, but we don’t have the capability to do that.”

Oh yes we do. It’s not a terribly intuitive or easy process, but it is doable. Instructions below for Windows, and Firefox on any platform. If someone else can contribute alternate OSes that would be great.

Windows for IE (possibly Safari & Chrome too?):
Run certmgr.msc, find the ones you don’t trust, and drop them in Untrusted Certificates/Certificates

Firefox:
Preferences, Advanced, Encryption, View Certificates.
Expand the listing and find each “Builtin Object Token” you don’t want to trust, highlight and hit Edit.
Uncheck all the settings for “This certificate can identify …”

Chris • March 31, 2011 7:15 AM

Apparently certificates are a magnet for Chrises. I may need to start posting with an email address.

Chris (from post #2)

leuk_he • March 31, 2011 7:19 AM

If you remove the certificate (very simple in firefox: options->advanced->encryption-> sho CA) from your browser you will see how bad the interface is in a browser to manage certificates yourself.

Besides that, the ONLY thing a certificate does is protect you from mitm. A certificate does not declare a site safe and does not make a site traceable. Nobody said it would, but sometimes people think that a lock would make things really safe.

barbie • March 31, 2011 7:32 AM

@leuk_he: err… “only” thing ? That’s a pretty fundamental only, if you ask me. That’s about the only reason you can put any trust in anything you look at on the web. I would not bank online if I did not know for sure I was talking to the bank’s server, even if it has security holes in. Nor would the bank even allow customers to bank online for fear of fraud.

rpetre • March 31, 2011 7:34 AM

Has any browser (or other major SSL root certs distributor, like an OS vendor) ever removed a CA from their default bundle? It seems to me that the list grows forever and once some CA gets in the “trust club”, no one dares to reevaluate its ability to be trusted for fear of backlash (try telling all the furious certificate owners that they should ask for their money back).

As a curiosity, CAcert (a non-profit CA) has been complaining for years that the only way to get recognized by default by major browsers would be to pass a very expensive Webtrust audit (with anual renewal). Did anyone ever failed to renew their audit? Did anything happen to them? This “known CA” sham starts to look more and more like a racketeering scheme rather than the trust extension mechanism it’s supposed to be.

authority • March 31, 2011 7:36 AM

Perhaps it would be wise to have one authority at the top of the chain such as the UN which only issues certificates to CA, with legally sound rules on when to revoke a certificate.

Ben • March 31, 2011 7:43 AM

Chrome: Tools (Customize and control Google Chrome) -> Options -> Under the Hood -> Security -> Manage Certificates

Find the one you don’t want (COMODO is probably under Intermediate Certification Authorities), click Remove

Internet Explorer 8: Tools -> Internet Options -> Content -> Certificates

Find the one you don’t want and click remove.

Snarki, child of Loki • March 31, 2011 7:43 AM

Opera: Tools/Preferences, Advanced Tab/Security link, “manage certificates” button, Authoriteis Tab.

Select “COMODO”, click the “delete” button. Done.

Will • March 31, 2011 7:50 AM

1) From reading the various articles, it says that removed CAs get reinstated every time the browser updates…

2) seeing as how most CAs are in under the influence of state actors; Iran would only need to steal certificates rather than issuing its own for the domains in order to hide blame for such hacks…

Steven • March 31, 2011 7:50 AM

“Has any browser (or other major SSL root certs distributor, like an OS vendor) ever removed a CA from their default bundle?”

Yes, there were a couple of certs in the past that snuck in. They were discovered and removed.

To me, the entire concept of PKI has been broken for years. We’re now starting to see real consequences for the state it’s been in. Scary…

KerrekSB • March 31, 2011 7:51 AM

Removing one, or all, CAs from your browser may not be such a bad idea. Someone else suggested this, but I forget where:

If you delete all browser-default certificates, you’re essentially in an authentication model similar to that used by SSH: Upon first contact you have to verify the correctness by other means, but ever after you know that you’re talking to the same person. A MITM attack is very unlikely to be in progress exactly at that first time, and even if it is, you would notice that something is wrong the second time, unless the attack was constantly going on.

The entire idea of having someone else take care of the trust issues on your behalf is a dangerously unsound one. Since the burden of making the right choice is already in the hands of the user, we might as well make it explicit and as straight-forward as possible. Like introductions in real life – the first time you meet someone you simply will have to go through a little more hassle. Nothing is free.

poinfdc • March 31, 2011 7:53 AM

In OSX you can simply delete the root certificate you don’t trust from the Keychain…

leuk_he • March 31, 2011 7:55 AM

@barbie. you do not know that you are talking the the server of the bank, only that the certificate is issued to someone who got the domain “yourbank.tld”. that is a fine line, but that is all the CA is declaring.

e.g.
Someone could register “yourbank_online.tld” and it might get a valid certificate.

The CA does not help here.

Getting the UN in charge does not help here. It is the business model that would need to change. No CA should get so bit that it is impossible to withdraw the certificate and people need to be able to switch CA quickly in such a case.

psychohh • March 31, 2011 8:02 AM

@leuk_he: unfortunately PKI like CA structures don’t protect us very well from mitm attacks. In reality the user has no chance in deciding to trust or not to trust a certificate. So it works like this: user trusts his browser vendor that he in turn trusts the CA that he in turn trusts the one who sent in the csr (perhaps it’s more complicated in detail). If you count in all different interests each involved party has, there will be not much left …

Peter A. • March 31, 2011 8:11 AM

Deleting CA certificates from your browser is easy – but they’ll probably come back at the next browser update. So one has to keep checking the list of installed CA certs all the time and disable/remove unwanted ones. Or maybe there’s already a plugin for removing unwanted certs? The question remains what would be the trusted source of the list of untrustworthy certs?

@KerrekSB: removing all certs is impractical – you may try to keep the SSH model of establishing initial trust somehow and manually adding individual site’s certs to your keyring – but you have to repeat this every year or so for every site you frequent, as CAs get their money by forcing their clients to renew them. It is unlike SSH, in which the server key does not expire; it changes only when server’s owner explicitly decides to change it or reinstalls the SSH subsystem (or the whole system).

Clive Robinson • March 31, 2011 8:17 AM

OFF Topic,

Speaking of Microsoft and being sued…

Has anybody else heard the news about Microsoft going “cap in hand” to Europe alledging Google has been carrying out “anti competative” action against microsoft?

(my first thoughts “Hahahah aghh didums has through the toys out the pram because Bing is not getting the hits” 8)

From the news item ( http://www.bbc.co.uk/news/technology-12918059 )

“The software maker [Microsoft] claims that Google used its dominant position in the search market to restrict the growth of Microsoft services.

It [Microsoft] cites a number of practices, including Google imiting the ability of Microsoft Bing to index web content”

Daniel • March 31, 2011 8:18 AM

What would other CA response to these attack? What if they just remain silent?

The PKI/CA model need some rethink.

tz • March 31, 2011 8:20 AM

I disabled all CAs in Firefox – it isn’t hard but takes a while manually, it is in the Preferences-> Advanced-> Encryption-> View Certificates, and you can edit what you find. I think other browsers have similar ways of editing, but some may be harder to get to. There is a tool which they don’t give the binary that can do CLI mass editing of the cert8.db file, but I just manually went through it on one and copied it over.

I use the Perspectives http://www.networknotary.org/firefox.html to fill in. The only problem is often sites use varying certificates, or even Firefox itself uses https:// to various places in the background where no window is open so perspectives can’t see it and it fails cryptically (like for extension updates – I had to use wireshark to figure out where it was going and manually open a window there to override the cert). If Firefox gave popups for any invalid cert for javascript or media it would be much easier, but for now I should be safe from malicious certs.

But that is another problem – Firefox fails silently about bad certs for embedded media. It simply won’t load the image or the javascript without any indication that something failed.

Otherwise, you must trust GeoTrust CA if you want to use Firefox since they sign all the mozilla certs.

KerrekSB • March 31, 2011 8:25 AM

Peter A.: I like to call this the “No Santa” Clause: You do not get anything for free.

If you really want good trust and security, then you will just have to do this. Once a year if it need be. Tough. Just think about what you DO get in return for your efforts — is it really asking that much to check a certificate once a year? That’s assuming that the certificate expires that quickly.

Also, consider that you don’t have to do this for EVERY site, only the ones where it really matters to you. If some random web forum has SSL and you’re not terribly concerned about MITM, you can always relegate that to a “always trust that site” policy. But if you don’t want to spend that extra minute for your bank and Facebook and your email and your important documents, just consider the alternative: Walking to your bank branch in person, keeping hardcopy documents in your locked briefcase, writing to your friends in enveloped letters…

The biggest attitude problem we have I think is that people leap from “the internet makes things easier” to the entitled assumption that “the internet should make everything absolutely effortless and free”. Santa hopes you’ve been good.

Clive Robinson • March 31, 2011 9:01 AM

Irrespective of the issues of removing certificates from browsers this raises a more serious issue.

From the leader above,

“The hacker, whose March 15 attack was traced to an IP address in Iran compromised a partner account at the respected certificate authority Comodo Group”

This does not sound like an overly bright hacker (that is if the “claim” they got traced back to Iran is actualy true).

So the question is,

‘What sort of security setup does Comodo Group have (or in this case have not)?’

and,

‘Is this near miss a one off, or have they already been compromised by other more skilled hackers?’

But to be fair it’s not just Comodo Group you should be asking the question of… It’s all security organizations who are at a point above you in the train / chain of trust.

I raised the point the other day over RSA and noted that attackers are moving towards the top of these trust chains because the ROI was considerably better than attacking further down.

The real question boils down to this,

‘If we cannot “trust” these root or other “top of the hierarchical tree” central entities to maintain reliable security, why should we use any of them?’

It is perhaps long overdue that we should activly investigate and implement non hierarchical trust systems.

Put simply I don’t trust any of the PKI or other heirarchical authN/Z systems and the entities that run them, and I see no reason why I should. In by far the majority of cases their business model is wrong and they don’t take responsabiltiy for their own failings, usually caused by trying to do either security or business “on the cheap”.

Richard Schwartz • March 31, 2011 9:25 AM

Seems to me that a model where sites present mulitple certificates to the browser would be best, where you can set it to require that N trusted certs are presented, but if any of the presented certs are non-trusted certs (or revoked) the browser presents a warning dialog.

Mel • March 31, 2011 9:31 AM

Back when PGP was a hot issue, there were people who were dismayed that the public “Web of Trust” was nearly non-existent; one or two even argued that being lax on verification would be a good idea for a short time for the sake of getting something in place.

For my part, I didn’t even want a Web of Trust. What I wanted would have been to go to a bank branch and get an official CD with a public key for the bank. This could authenticate any further dealing with the bank. Thanks to the Department of Commerce and general security obtuseness in those early days, that was never implemented. We got PKI instead.

Pete Krawczyk • March 31, 2011 9:31 AM

What we truly need is SSL certificate tracking on the client side, like we have with SSH. Certificate changed? Show the differences in the certificate and ask the user what to do. If the certificate simply expired, then it’s good enough to click “Yeah, this seems legit”. If more than that changed, then things need to be investigated.

SSH warns me when the host certificate changed. Why can’t my browser?

Paul • March 31, 2011 10:15 AM

I’m not sure why people think it is acceptable to sign their posts with just a first name.

I’m talking about you, Chris.

Peter • March 31, 2011 10:24 AM

Paul, I’m tired of people robbing me just to pay you. What kind of business are you running that drives your customers to crime?

(tongue planted firmly in cheek)

yet another chris • March 31, 2011 11:27 AM

re: deleting Comodo from CA list:

are the others any better?

reminds me of Ambrose Bierce (but then, so many things do)

THE members of the School Board in Doosnoswair being suspected of
appointing female teachers for an improper consideration, the
people elected a Board composed wholly of women. In a few years
the scandal was at an end; there were no female teachers in the
Department.

Shane • March 31, 2011 11:30 AM

“So it’s smarter for the browser companies to just ignore issue and pass the problem to us users.”

Sigh, like so many other facets of US corporate policy…

Peter Pearson • March 31, 2011 11:47 AM

The Chrome browser, running under Linux, uses root certs in a database that can be managed with the certutil utility. The command

certutil -d sql:$HOME/.pki/nssdb -L -h all >adjust.tmp

will create a text file with one line per root cert. The -M, -n, and -t options of certutil can be used to modify the powers of any given authority (I just downcase them from C,C,C to c,c,c), and a shell script can easily modify the whole set en masse.

I disabled the whole set, and re-enabled the few that turned out to be necessary for my usage patterns. This way, if my bank’s login page is certified by a Bulgarian authority, I’ll be notified — which is what I want.

Justin • March 31, 2011 11:52 AM

+1 to “foo” for the DNSSEC mention. This is the real method of validating a site is who they say they are. Of course a DNS server could be rooted and DNS records changed but that is veering quite off track with regards to SSL and CA’s.

Jered Floyd • March 31, 2011 1:28 PM

The SSL public trust model is unfortunately fundamentally flawed and unfixable. SSL protects against the casual eavesdropper and the broad-spectrum phisher, but is completely ineffective against a targeted attack against an individual or group.

I fully believe that the only reason countries like China aren’t doing a MITM attack on all SSL sessions is just because they haven’t gotten to it yet. Getting spoofed certificates will not be a problem. Similarly, if the US government wants to eavesdrop on your communications, you can bet your ass that Versign will turn over any certificate they want to a LEA without so much as a warrant.

SSL is better than nothing — it’s good defense against a passive eavesdropper. I don’t believe it offers meaningful security against an active attack.

Nick P • March 31, 2011 2:08 PM

@ Mel

“What I wanted would have been to go to a bank branch and get an official CD with a public key for the bank. This could authenticate any further dealing with the bank.”

You said it first. The customer should get the bank’s CA credentials, in paper and digital form, from the bank itself. Then, that CA would be used to certify all of the banks content. When necessary, new certificates could be communicated to customers using multiple communication channels. The reason I mention a hard-copy version is that it allows the use of custom or COTS secure hardware for various authentication or transaction protocols yet to be developed. Call it future proofing. 😉

I don’t think we should arbitrarily dismiss the web of trust concept. The reason is that a similar concept, friend-to-friend, has worked quite well to minimize security and privacy issues. Just look at schemes like Freenet: I know of no users being compromised without an inside attack. A well-thought combination of the web-of-trust and F2F models might produce something pretty reliable, so long as we stick to local, knowledgeable “friends.”

Ideally, though, I’d prefer each organization to just keep its own CA server running with public key posted in a number of PGP-style public directories. The companies running these directories could provide a significant form of verification to prove the company’s CA belongs to them. Browsers would keep a database of public keys that could be added or removed by users.

An optional extension in the form of web-of-trust model could be implemented whereby verified companies and users of each service could sign the public keys PGP style and the user’s browser would indicate the site’s key is in their web of trust. The indicator would be visibly different from one that indicates a public key is in the user’s own trusted database.

Mark Atwood • March 31, 2011 2:28 PM

That any CA can sign any cert for any domain or org was broken from the beginning, and it’s broken in such a way that is hard to believe it was an “accident” or a “mistake”.

Flado • March 31, 2011 3:31 PM

@Peter Pearson: As a Bulgarian, I must take offence. There’s a reason why Elbonia exists (or rather doesn’t)

Seiran • March 31, 2011 4:18 PM

“Comodo is likely to sue any browser company that takes this sort of action”

I don’t believe there is any contractual obligation for browser vendors to include any certificate. Microsoft and Apple might have financial agreements with CAs for shipping a root certificate as “trusted” with their products, and I would think that any well written agreement to that effect would be predicated upon having, implementing and abiding by their own CPS (Certification Practice Statement).

Which unfortunately these days, together along with RPAs (Relying Party Agreements) is often no more than a subtle way to say that “we’re not responsible for anything”.

Mozilla, through community concensus, could very well decide to drop Comodo or any other CA from its trusted roots.

What really keeps browser/OS vendors from dropping Comodo is the impact it would have on end users and legitimate site operators which make us the vast majority of a CA’s customer base.

Fraud is known to be a weak link in centralized PKI. VeriSign caught two bogus code signing certificates for “Microsoft Corporation” going out the door, the serial numbers of which are included in the Windows CRL to this day. Key theft is another less common problem, Stuxnet was released with the help of stolen Realtek and JMicron certificates as well. Also, many roots will allow you to chain your own CA certificate to theirs and effectively become a 2nd level CA if you can prove that you are a registered company with enough capital and liability insurance.

It’s not like they didn’t see this coming.

Oh, if that wasn’t enough, if you’re tired of having to sign your kernel level drivers on Vista, someone wrote a loader stub, signed it, and released it publicly. Microsoft had to get that revoked too. Though, any signed application that takes unvalidated input and runs it could be exploited similarly. I rely heavily on Authenticode to assure the integrity of software downloaded from Internet sites and filesharing, though I am wary of the possibility that a signed installer application (InstallShield, WISE, et al.) with a separate payload (.CAB, .MSI files) will trust those files and install them with no more than a cursory file size check, or maybe a CRC.

http://www.schneier.com/blog/archives/2011/01/the_legality_of.html
http://www.amug.org/~glguerin/opinion/revocation.html
http://blog.eset.com/2010/07/19/win32stuxnet-signed-binariesl
http://www.schneier.com/blog/archives/2010/09/uae_man-in-the-.html

Seiran • March 31, 2011 4:54 PM

Out of the sites mentioned, only two – login.live.com and addons.mozilla.org – use EV SSL.

I’ve used many of the other sites and honestly I’m quite surprised why Gmail and Yahoo still don’t turn on the green address bar.

I don’t know if it would have mattered here, whether Comodo RAs can vouch for EV SSL signing requests or not. However, EV SSL can reduce fraudulent-issuance problems where the most lenient CA becomes the weakest link, as there is a much more limited number of trusted EV roots.

EV SSL, as well as specific high risk targets (*.google.com, *.yahoo.com, known banks, etc.) should be set up for two-party or three-party control before fulfilling of the certificate request.

David D • March 31, 2011 5:01 PM

I’ve been following this closely and I have not yet heard what I’d expect in response from Comodo.

When any signing intermediate CA certificate is stolen or it’s control compromised, it should be revoked. Then a new Comodo intermediate CA certificate should be created (signed by the non-compromised Comodo root) and all it’s managed PKI customer’s SSL server certificates re-issued.

The revoked CA certificate (and whatever fraudulently issued server certs you can identify) should go in Comodo’s OCSP database and in globally distributed CRLs.

What happened is that Comodo used an API that used username/password (OMG!) to secure RA signing approval access to a 3rd Party company that had poor host security. Then worst of all, that RA had the right to sign certificates for any Domain name (FQDN / CN).

This includes FQDNs for non-customers of Comodo like those that use Verisign’s CA services, such as Google, Yahoo, Mozilla, etc.

Frankly i’m shocked that certs for Paypal, BofA, Well Fargo and other financially important sites were not created by the hacker. I’m not sure i can trust Comodo to tell me about them either.

Every browser’s pool of “globally trusted root” CA certs will now cryptographically falsely authenticate the SSL sessions of any site or function using any of these fraudulent certificates. Using another CA vendor with better security is absolutely no protection, since FQDNs are not associated with a particular CA vendor.

Comodo is the #3 CA in the world (behind Verisign and godaddy), removing it from your pool of trusted root certificates actually isn’t the right answer either – it should be revoked. It should get a “denied” error, not a “unknown signer” error.

Comodo has a long way to go, and a lot to prove, before I could trust them with “trusted root” status for my browsers again and i’m not seeing them going down the right path.

nobody • March 31, 2011 5:31 PM

re Mel:
In Germany and France, with the new EBICS-online banking standard, they do exactly this. The user prints out his public RSA-keys, signs them (by hand) and submits them to the bank. Before he is allowed to do online banking, he has to verify the banks public keys (i.e. compare the hashes) from several sources. EBICS also mandates TLS for transport of its protocol, which is based on the thus exchanged keys; however, the SSL-connection with browser-shipped certs is only used for privacy protection (e.g. in order to make traffic analysis harder). An SSL-MiTM is therefore not capable of comitting fraud.

Re DNSSEC:
Dnssec actually is far better than the current PKI-X.509-cert model:

Firstly, revocations actually work. If a key gets compromised of successful social engineering occurs, the corresponding “certs” (i.e. signatures on DNSKEY and DS-records) simply do not get renewed. In order to exclude rogue cert, you just chop the chain-of-trust anywhere between the root and the affected cert (and kill all the keys in the chain below the cut). In the worst case you have seven days until the rogue cert is removed from the system (the root key only signs 7-day certs for its siblings, so you can kill one cert for ., the cert for the TLD and then the affected one).

Secondly, delegations actually work, in the sense that the recipicient of the delegation is less powerful than the delegator. Root can delegate the power over any TLD; when the e.g. the .cn TLD operator gets powned (by the chinese government), other TLDs are not affected.

Thirdly, the whole process is much more public: When you get your broken DNSSEC-cert via social engineering, anybody will be able to see it (at the worst via NSEC-zone-enumeration). If you social-engineer yourself an SSL-cert, only the victim of your targeted attack will ever see and scrutinize the cert. This does of course not apply if you pown a zone-operator.

Gweihir • March 31, 2011 5:37 PM

Just removed the Comodo certificates (root and intermediate) from Opera. Really easy and fast to do.

tommy • March 31, 2011 6:27 PM

In Firefox, CAs deleted through the GUI do regenerate – at the next browser start, not the next update — unless you modify the underlying dll and database files. I long ago did as Chris The Movie (Chris #2) said, and removed powers from Turktrust, etc. But would rather delete them. So:

Re: @ tz: Yes, there is a tool that must be compiled yourself to edit the files. Reprinting my reply to Nick P.’s justified complaint about the difficulty of removing certs through the Firefox GUI, from “Federated Authentication”, 29 March 2011:

schneier.com/blog/archives/2011/03/federated_authe.html

@ Nick P.:
Supposedly, there’s some dev toolkit with which you can modify the nss.dll’s (in ProgFiles\Mozilla) and the cert.db’s in your profiles at will. Not for moi, thanks. Would you care to do us all a great service and create a set of files with the proper CAs (Versign, etc., and not Turktrust, etc.), that we could just swap in?
Or a simple GUI that enables the user to delete CAs at will, by modifying the involved files appropriately?
We’d all love you forever, and I, for one, would buy you a cup of non-Star$-coffee (i. e., donate a couple of bucks.)

@ DaveCh, I too have used CertPatrol and strongly recommend it. No cure-all, but every little bit helps …

@ ALL: Yahoo is a high-value target? If your email is that sensitive, it should be sent with PGP, GPG, Hushmail, etc. The non-sensitive stuff — annoying if someone starts using my account to send bulk spam, so it’s hardly a non-issue, but I’d be much more worried if my online banking certs were compromised. Most are signed by Verisign – now, there’s a high-value target! — although I’m a bit peeved at one who self-signed. Anyway, keep your high-value stuff out of Google and Yahoo, which was always good advice even before this announcement.

The redirection issue is scary, but NoScript, along with the usual AV and other defense-in-depth, would block most of what redirectors try to achieve: Installing malware, typically to botnet you. We have already seen one such redirection attack against non-secure search engines Google, Yahoo, Ask, Bing, and AOL. The evil site tried to run JavaScript to install stuff, but NoScript’s default-deny blocked that.

With some experience in business legal matters, but not a lawyer, thank goodness, I see no grounds for Comodo to sue browser manufacturers, especially after a breach like this. If anything, the browser people could be sued for not revoking the certs, assuming that there was this mythical thing called “software liability”….

Spoofing addons.mozilla.org is a little scary, although AMO does little to verify the 6.000+ independent addons already. Fortunately, NS dev Giorgio Maone already has his own secure server for NS d/l:

noscript.net/getit which redirects to the secure site, (for the present version)

https://secure.informaction.com/download/releases/noscript-2.1.0.1.xpi

Uses AES-256, although GoDaddy isn’t exactly my fave CA, either. But freeware devs maybe can’t afford Verisign.

Richard Steven Hack • March 31, 2011 8:45 PM

Seems to me that back in the day when the Web was new and we didn’t have Facebook with X millions of users and all this security stuff was being designed, the concept was like PGP: you generate a private key, publish a public key to a public keyring, and you don’t do any business without using those keys.

But because the Web was new, that process was outside the conception of your average user. Too complicated.

So now, though, we have many users doing Webby stuff all over the place. Maybe we should make Facebook (or Twitter) the repository for your public keys. 🙂 Then everyone would use public keys. Work something like TrueCrypt or something even easier for the private keys.

Then do the same for the banks, commercial Web sites, etc. Everything done via the browser.

Then it would seem we wouldn’t need all this hierarchical trust stuff. Cut out the middleman and everyone handles his own security.

Of course, the minute Facebook (or Twitter or whoever) lost all the keys – which they would, of course – or someone had their private key keylogged – or a bank did – it would all come crashing down again.

So we’re back to my usual mantra: there is no security – suck it up.

Except for ninety five percent of us, there really is. How often have you been mugged in your life?

The fact that a huge percentage of people have had their identities stolen still doesn’t bring down the whole commercial credit card infrastructure (although some think it should).So it’s not clear to me that a broken PKI system is really any more important than, say, 9/11 proves that the world is being destroyed by terrorists.

In short, life goes on, security or no security.

Daniel Speyer • March 31, 2011 10:29 PM

Does anyone know what legitimate sites use Comodo? What am I losing by removing it?

Nick P • March 31, 2011 11:08 PM

@ tommy

Nice tip. Don’t code in their language much: I mainly design, review and deploy. But I think I found what you’re talking about and it is more cryptic than need be (like, I’d expect a GUI).

Mozilla Certificate Database Utility (old site)
http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html

Manpage of certutil (modern; fedora)
http://elladeon.fedorapeople.org/nss/certutil.html

So, a coder should either use the code in the tool to build a GUI app or build a GUI front-end to the command line tool, like the FSUM Front End. If all this complexity is intentional on Mozilla’s part, then there would also need to be a maintenance team in case Mozilla messes up the compatibility during updates.

tommy • April 1, 2011 12:24 AM

@ Nick P:

Yes, your first link is what I was referring to. There was a second one with a complete suite that would also modify nspr4.dll, nssckbi.dll, and I think also nss3.dll – or the later equivalents in newer releases — in ProgFiles\Mozilla, as said. It wasn’t clear whether you had to do both just to delete a cert. Unfortunately, I didn’t bookmark or copy that link (facepalm). I can try to find it if you’re interested.

Of course it’s more cryptic than need be. Having left IE in the dust, they’re now trying desperately to catch up with MS by complicating stuff that worked fine when it was simple. E. g., bookmarks in F2 were bookmarks.html, but in F3+, an sqlite db. Why, I don’t know.

If you know anyone who could make that user-friendly GUI, please invite her/him/it to do so. Even a tool that would run from cmd.exe would be of benefit, because most users lower than that on the tech scale won’t even be aware that there’s an issue (or if Comodo users, they’ll accept bland reassurances, and not know that the North Korean Ministry of Defense is a CA in their browser, ha).

Something like:

certutil del “TÜRKTRUST Bilgi İletişim ve Bilişim Güvenliği Hizmetleri A.Ş.”

would probably do just fine.

I expect that the complexity is indeed intentional on Mozilla’s part. Gotta show off one’s knowledge while preventing the illiterati from treading on the arcane territory of the cognoscenti, no?

Clive Robinson • April 1, 2011 1:34 AM

Ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo@ Nick P,

“If all this complexity is intentional on Mozilla’s part, then there would also need to be a maintenance team in case Mozilla messes up the compatibility during updates.”

Tsk tsk tsk, this is Open Source, they are not going to “messes up the compatibility”… which of course does not rule out “userbility / security enhancments” of which no doubt there will be many 😉

@ Richard Steven Hack

“Except for ninety five percent of us, there really is. How often have you been mugged in your life?”

Err depending on how you classify “being mugged” two or four times. The odd two were,

1, Surprising a burgler getting into my house around 15years ago and on chasing and catching him and pinning him to a wall, his accomplice stabed me from behind in the head and back.

2, On my way to work one day just over ten years ago I was attacked by a gang of students from Richmond College in Twickenham London and had my head “karate kicked” into a metal pole from behind (quite a feet seeing as I’m 2M high) resulting in a full fracture on the point of the lower jaw (the toughest part of your body).

As I had to go to hospital on both these occasions the Met Police unfortunatly got involved (at best a compleate waste of time in the first case, and in the second incompetantly covering up the fact it was one of their informants who had attacked me).

The first real case of attepted “in your face” street robbery that happened to me was thirty odd years ago in South Wimbeldon where three “West Indian / Afro Caribbean” late age teenagers tried to shake me down and I was not playing their way. The one who tried to stick his “afro comb” in my neck ended up with it in his stomach before I threw him over a wall, the second was knocked unconcious when he landed very hard on his head on the pavment, and the third who had a reasonable head start, managed to run fast enough that he stayed that little bit infront of me, and I gave up chasing him after a mile or so when he headed into the Phipps Bridge Estate.

The second occasion happened a couple of years after the first an idiot pulled a knife on me when I was jogging in Richmond park near the Golf course on a sunday morning and I ended up kicking him hard in the side of the knee and throwing him in the river, I left him where he “fell in” to cool off. The last I heard as I jogged off a bit faster was him screaming that I’d broken his leg.

Oh there was another occasion about twelve years ago when an idiot “traveler” tried to steal my push bike whilst I was getting a burger one evening, he ran off but I chased him down and cornered him in a blind alley behind some shops. Although I did not hit or kick him except when he bit me he was scared out of his witts when the Met Police arrived and took him away. They charged him but predictably (I had warned them) he gave a false name and address and they let him go and unsurprisingly like most criminal “travelers” he was not seen again…

I guess the moral is you slow down as you get older and forget to “watch your six” in civiy street, oh and don’t get the Met Police involved they are effectivly useless and just make things a lot lot worse.

I guess I’ve seen more “street trouble” than most as I used to prefere to walk and use “public transport” rather than sit in a smog box on wheels.

Any way with regard to your comment,

“Seems to me that back in the day when the Web was new and we didn’t have Facebook with X millions of users and all this security stuff was being designed…”

The real problem is the “security stuff” was not “being designed”, it was very much an after thought by a couple of bods who thought at the time that “Desktop PC’s” were not realy up to doing Public Key Crypto so actually put the load intensive end on the server…

Maybe I’m one of the few who remember what was to become the Internet (Arpanet later Darpa-net) and the minicomputers you used to use to connect to it.

Unlike the ISO OSI model (that gave us the X-standards) the BBN IP model was designed to run on the then available hardware some of which used 8bit CMOS microprocessors like the Rockwell 1801 chip and just a few KByte (yup that’s K not M) of memory over serial comms lines. There was barely the overhead to get IP working let alone UDP or TCP (sometimes done on second processors). Thus unlike OSI which was designed for globe spanning networks (but no hardware could then support it) BBN’s TCP/IP was a pragmatic engineering solution designed to run on what was available. Security using crypto was very much an after thought, you had a choice of DES in hardware or…. Nope that was it DES in chips that you required a special licence for to say you were not going to export them or the resulting equipment behind the iron curtain etc.

Believe it or not many “secure instalations” used either IBM’s 2Mbit network running on “twinax” or the original Ethernet on RG50 coax running in steel nitrogen purged and preasurised conduit with preasure drop alarms. And the security personnel had to quite literally “walk the line” every day looking for signs of tampering…

It was only with the advent of the 486 based IBM PC-AT with atleast one Megabyte of memory that people got the RSA PK to work on a desktop and do söooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

Clive Robinson • April 1, 2011 1:44 AM

Sorry for the strange state of my above post.

The keyboard driver on this darn LG Smart phone took a walk in the park as I was posting (I’ve had to hard reboot it again to my annoyance).

Please ignore the strings of “oooo”, and the last words should have been “something else.”

Daniel Wijk • April 1, 2011 2:42 AM

Clive Robinson: At least you managed to get an ‘ö’ in there. Feels somewhat comfy for some of us from Europe 😉

Richard Steven Hack • April 1, 2011 3:37 AM

Clive: Tough luck on those muggings. I’ve been mugged once at knife point and wisely gave up the wallet with a lousy $25 in it – but convinced him to give back the wallet with my ID.

Of course, had I a gun at the time, I’d have shot him in the head somewhere further down the street away from where I live and got my money back, legal or no legal. His lucky day. And yes, to me getting $25 back from a thief is worth his life. Assuming I could get away with it, of course – it’s not worth MY life in prison.

Anyway, my point is that identity theft -or breakdowns in security in general – is like being mugged – it doesn’t happen to everyone and even if it does, it doesn’t ALWAYS ruin your life like they try to portray it as doing. Sure, you can get killed during a mugging, but it doesn’t happen that often statistically.

Had you taken proper precautions against a burglary (i.e., a safe room, easily accessible weapon, martial arts training, etc. ad nauseum) you could have come out on top in either case.

But most people don’t take such precautions – they rely on the state to protect them, just like computer users rely on the security infrastructure to protect them. Except that in both cases, the crimes occur because neither party can protect against all such occurrences – by design.

So we’re back to: “There is no security – suck it up.”

“The real problem is the “security stuff” was not “being designed”, it was very much an after thought…”

That’s what I meant by “being designed” – that’s how most design is done in this industry. That’s the core problem. The IT industry is a joke at “designing” anything. The entire industry concentrates on just getting something – anything – to work at the basic task it’s intended to do. EVERYTHING else – security, reliability, usability, cost – is an after thought. Everything.

Until that problem is solved – and given human nature, the nature of management and the present economic structure, that’s highly unlikely – this will continue on.

So AGAIN we’re back to: “There is no security – suck it up.”

GordonS • April 1, 2011 6:49 AM

@ Richard Steven Hack

“Had you taken proper precautions against a burglary (i.e., a safe room, easily accessible weapon, martial arts training, etc. ad nauseum) you could have come out on top in either case.”

Probably because for most people these are complete overkill, given the costs involved, and the small chance of ever actually having to use them, and the chance that they could even make things worse for yourself.

Ondrej • April 1, 2011 7:04 AM

Please note that there is an ongoing effort at IETF to create new DNS RR type which would allow your site to lock down to specific CA or EE-certificate (one part) and/or use your self-signed CA/EE certificate (second part).

Ondrej

Adam • April 1, 2011 8:05 AM

Why do websites need a cert (costing a lot of money) which has been signed by a CA anyway? Surely it must be possible to extend the protocol in a manner that a cert could be signed by a PGP key instead. If you drilled in the cert info it could present you with the PGP signatories instead of a CA.

Surely Mozilla and possibly a few other browser makers would recognize the merit of doing this if for no other reason than to further the adoption of secure communication.

Sure, banks and the like probably still want a cast iron cert from a CA, but for individuals and small businesses it’s a huge bind.

stevek • April 1, 2011 8:11 AM

I just looked at Certmgr and found the new, fradulent Comodo certs in the untrusted certificates list. (Win7-64).

That’s good news, but not good enough. I moved Comodo to Untrusted status and will live with the inevitable false positives.

Also, we’re talking here about browsers on PCs. Keep in mind that it is not possible for users to update trusted CA lists on other devices, such as smart phones.

omb • April 1, 2011 8:48 AM

For god sake no_one encourage the involvement of the UN else you will have a massive corrupt beaurocracy run by crooks, in no time. Vide UNHCR

No One • April 1, 2011 9:48 AM

+1 @omb.

The US government makes a mess of things and they have 50 states that, in the end, have a singular goal of bettering the US.

Now you want to add another order of complexity to that, creating the UN, which has something like 180 member states, each with their own constituent states and try to get them all to work out how to do something which has to do with technology in the end?

The internet succeeded because the guys who built it and administered it originally weren’t very far removed, technically, from it. I mean, you don’t hire an Amish guy to design your rail system.

Ondrej • April 1, 2011 1:08 PM

The CAA proposal won’t help in this case or in any other case where there is a rogue, malicious (governmental) or hacked CA involved.

The CAA is a way how to say: “If you comply with the CAA and you are nice then please don’t issue the certificate for my domain.”

Any system which is not enforced by a client policy will fail in case the CA is not “nice enough” to comply.

O.

bob (the original bob) • April 1, 2011 2:26 PM

What I find particularly annoying is that MS by default trusts many hundreds of Root CAs, some of which are exotic (risky?) enough that they cant be displayed in ASCII; however despite selling god only knows how many copies of windows to the DoD, they do not trust the DoD root CA 2 which signs (as near as I can tell) ALL DoD emails and websites.

Nick P • April 1, 2011 3:21 PM

@ bob (the original bob)

Thank you! Bout time someone else mentions this! I remember I had to get on to get some important information and got warnings out the ass. For safety, I had to dig around quite a few trusted .mil domains to find the DOD root CA certs and keys to verify it was legit. Then, I was like, “Why isn’t one of the most used and authentic CA’s in the browser again?”

I mean, I surely don’t trust them that much, but I do trust the identification aspect of their processes. For subversion of that CA, one would mainly have to worry about high level government activity. For subversion of say a Turkish CA, how much would it cost to pay one of the workers to install some malware or get a bogus signature? So, why again do they trust a Turkish CA more than DOD PKI?

tommy • April 1, 2011 3:30 PM

@ Richard Steven Hack:

I have a gun. And I’ve never been mugged. Correlation doesn’t imply causality, of course, but it does imply – for yours truly — a lawful “citizens’ arrest” of the robber. Given that he has already used a deadly weapon, killing in self-defense or defense of others whom he might also threaten, stab, take hostage, is allowed in my jurisdiction, if he doesn’t succumb to said arrest. If it isn’t in yours, you’re living in the wrong place. Sympathies on both the event and the locale.

Nick P • April 1, 2011 3:55 PM

@ tommy

Good points, Tommy. Richard also mentioned that, statistically speaking, most muggings don’t end in murder. I’d like to point out another statistic: states that enacted concealed carry or areas where people are often packing heat tend to have much less robbery and violent crime. (Ghetto’s excluded, obviously). Crooks make a risk decision and decide it’s not worth getting shot over. These areas often saw a rise in crimes like auto theft and burglaries of empty houses. I’d say that’s a good excuse to live in a jurisdiction that let’s people kill a violent crook in self-defence.

Richard Steven Hack • April 1, 2011 5:49 PM

Tommy: I live in San Francisco – not exactly a gun-friendly town. Plus now that I’m an ex-felon, it’s worth twenty years for me to own one (or even a blowgun in California, a VERY anti-weapon state). I can’t even own body armor to protect myself. Not that it would stop me if I have to.

GordonS: Well, martial arts aren’t overkill for most citizens. There are so many additional benefits to that activity that it’s worth doing even if you never use it and the cost at most schools is minimal. One needs to exercise anyway. A “panic room” is just some solid doors and a cell phone, not necessarily a bunker. Really, the precautions are minor expenses. “Better to have it and not need it than need it and not have it.”

tommy • April 1, 2011 7:41 PM

STOPPING FIREFOX SILENT FAILURE ON BAD CERTS

@ tz:

“Firefox fails silently about bad certs for embedded media.”

I found the following files that might be modified to prevent the silent failure “feature”. Your humble servant doesn’t feel like messing with changing them and fixing whatever breaks etc., so if anyone else does, please feel free, and let us know if it works and what you did.

This was Fx 3.6.x on a flash drive, from portableapps.com. File paths on a HD install will undoubtedly be different. Or just search your machine for the following files.

For simplicity, each path starts with (DRIVE)(FirefoxPortable folder name, usually just FirefoxPortable)\

\App\Firefox\modules\CertUtils.jsm”

  • This class implements nsIBadCertListener. Its job is to prevent “bad cert”
  • security dialogs from being shown to the user. It is better to simply fail
  • if the certificate is bad. See bug 304286.

\App\Firefox\components\nsBadCertHandler.js”

same

\FirefoxPortable\App\Firefox\components\nsBadCertHandler.js”

(yes, the folder name is repeated. As in F:\FirefoxPortable\FirefoxPortable etc., for this and the next.)

  • This component’s job is to prevent “bad cert” security dialogs from
  • being shown to the user when in XHR backgroundRequest mode. This
  • causes the request to simply fail if the certificate is bad.

\FirefoxPortable\App\Firefox\modules\CertUtils.jsm”

same comments as the first CertUtils.jsm

A quick glance at F4 Portable, and a brief search, did not find these files. Also, there is no subfolder called \FirefoxPortable inside the folder of the same name. The portable went from 80 MB in 3.6 to 49 in 4, and from 710 files to 143, so either Fx itself, or the Portable Apps people have simplified things. Good. Don’t know what effect this has on the “silent-fail” behavior, as haven’t played around with F4 much yet.

@ Richard Steven Hack: I’m afraid that the ex-felon status is probably a lifetime bar to gun ownership anywhere in the US, but in more gun-friendly states, you could apply to have your civil rights restored, depending on the nature of the conviction, how many years since released or paroled or whatever, evidence of good behavior since, etc. You could even try it in CA — you could at least wear body armor. (No, I don’t do that.)

I don’t know the SF laws on guns, but could I leave the one point that the 9/11 perpetrators pulled off a huge coup without any firearms, just box-cutters?
__

@ Nick P.:

Well said, Sir.

Would just like to add a specific example: About 20 yrs ago, a fairly large city in my state had a serial rapist on the loose, with many attacks reported. The Police Chief went on TV, newspapers (they used to have those back then ;), etc., and urged all qualified women to obtain a concealed-carry permit, and that his department was providing the training courses required to obtain the permit (safe handling, laws on legal use, etc.)

Don’t know how many actually armed themselves, but for some strange reason, the attacks stopped. Don’t think the perp was ever found — probably ran off somewhere else.

Once again, correlation does not equal causality, but after all that publicity, perhaps the mere thought of the increased probability of a potential victim being armed was enough of a deterrent.

svyr • April 1, 2011 10:06 PM

Opera’s CA related things are broken.

If you remove, say, the GoDaddy or Comodo CAs, when you visit godaddy or comodo sites, the CA ‘magically come back’ (maybe you need to restart opera?). When you instead of removing them tick ‘warn before using’ in properties it works as expected and you get a warning.

steeve • April 2, 2011 11:49 AM

There is also a problem with update. When there is an upate to the browser the browser put back the CA that we have deleted. So removing a CA is a job to begin again the next time. There is also no central place to maintain them so for a computer with many browser to test web application we have to maintain a long list of CA for each of them.

With many device accessing the web from the computer to the cell phone, the gaming devices and the tv this is a lot of device that need to be maintained. For most people this is too much work.

Babak Memari • April 2, 2011 1:02 PM

I am an Iranian. I have read that Comodo is in Italy. It seems that Iranian Government has bought some information from Comodo. As you know Italy is like Iran and Government-related-Gangs control everything. I strongly ask you to consider this possibility.

deepcover • April 2, 2011 10:41 PM

Why all this ragging on the CA’s? They do wonderful things with their meager profits… like Bob Parsons, GoDaddy CEO, going on a safari in Africa to kill an elephant!

Mian khurrum • April 2, 2011 11:03 PM

I am totally bewildered by the omission of Certificate Revocation Lists (CRL) from this discussion. I find it hard to believe that even Bruce forgot to mention that. Please calm down. The designerns of the CA system always accounted for this possibility and the actual risk is actually almost non-existent from this compromise. Bruce really needs to modify his post to reflect that.

Read this if you don’t undersand what I mean.
http://infosentry.org/archives/39

Clive Robinson • April 3, 2011 4:24 AM

@ Mian Khurrun,

“The designerns of the CA system always accounted for this possibility and the actual risk is actually almost non-existent from this compromise.”

Oh dear you don’t appear to realise the issues with CRL’s.

To be effective there are a whole chain of events that have to take place,

The first thing to note is it is the CA who holds the root certificate or has access to it that issues the CRL.

However two things immediatly effect this,

1, The CA is aware that the certificates need to be revoked.

2, The CA actually does put a revocation in the CRL

Neither of which addresses the issues of “unkonown to the CA false certificates” issued by those who have broken the CA’s security, or those “known to the CA false certificates” issued by the CA for surreptitious use, either by insiders or outsiders with the partial or full knowledge of the CA.

But the problems with CRL’s don’t stop there, there are further issues with it getting to and working correctly in the user agent (browser),

3, The user agent has to try to get the CRL.

4, The user agent has to be able to get the CRL.

5, The user agent has to know it has the full CRL.

6, The user agent has to correctly apply the CRL.

7, The user agent has to not ever delete the CRL.

All of which means that those certificates are actually still dangerous if anybody can get control of the comms channel up stream of the user agent, or can make small or marginal changes to the user agent machine/PC (such as the date).

Due to earlier issues with KeyMat systems all of these failings were known before RSA let alone CA’s where even thought of. That is similar issues with trust in other encryption systems are well known.

The issue some people here are anoyed about is the “Business model” that Comodo appear to have adopted which is so lax in security that it enabled the false certificates to be issued in the first place.

P.S. There appears to be problems with the certificate for the site you point to via your name link (ie the cert has not been issued to the site name).

As your first name matches the name under which the article you point to was written perhaps you should ask the site administrator to put their house in order…

Clive Robinson • April 3, 2011 9:11 PM

There appears to be a bit more news on this.

There is a person calling themselves “Ich Sun” who claims to be the person behind the attack on Comodo Italian partner.

Apparently they also have successfuly attacked not just the known Italian Comodo partner but another unnamed CA, and two further Comodo partners.

http://m.computerworld.com/s/article/9215360/Comodo_hacker_claims_another_certificate_authority?taxonomyId=17&pageNumber=1

If Ich Sun’s claims are true then some other CA’s “are living in interesting times” right now.

Although Ich Sun’s other claims have not been verified (infact some are denied by a Comodo representative), Robert Graham at Errata Security has apparently had communications with Ich Sun and been provided with the Private Key of the false certificates and has verified that it matches,

http://erratasec.blogspot.com/2011/03/verifying-comodo-hackers-key.html

Other Ich Sun messages describe the way the Comodo Italian partner was compromised (SQL Injection attack and the password embeded in a script file…). Apparently this particular attack nolonger works as either Comodo or their Italian Partner have taken (unspecified) steps to prevent it.

What is not clear is if other Comodo partners were attacked the same way or not, nor if other CA’s have similar lax arangments with their partners.

Ultimately the issue behind the attack is the “CA Partner” Business model and how it works in practice at “minimum cost”. As Bruce has pointed out a number of times when it comes to security the “weakest link” is where the chain often gets broken.

Now I would agree that having a “readable embeded password” is not quite the same as having it written ROT13 on the wall in 1ft high letters behind the reception desk visable from the street, but it’s not far off of it. It’s one of those “no no’s” they assume you know about before you go to “Security 101” in much the same way they assume you know how to add 2 to 2 in “Maths 101”. When you have not got the foundations in place it makes you wonder what other “short cuts” there are in this “House of Cards on Shifting Sands”.

Mian Khurrum • April 3, 2011 11:38 PM

@Clive Robinson
Some of your points are valid. My point is that getting angry is not the right response. I just updated my blog with steps to import the Comodo CRL, which is a more sensible thing to do in my opinon than trying to delete the Comodo root certs from your browser. You can get the details with screen shots here.

http://www.infosentry.org/archives/39

PS: My regular site is not enabled for SSL. I appreciate your curiosity but I don’t want to pay a CA for cert 😉 I recognize the cert of my website host and that is good enough for me. 🙂 When I have more spare cash, I will consider hosting everything on SSL on a dedicated server.

Jonathan Wilson • April 4, 2011 9:30 AM

What is needed is to get rid of certificate issuers altogether and start storing certificates (or their hashes/fingerprints) in DNS (secured with DNSSEC)

If you store the certificates in DNS then you dont need to worry about bogus certificates since the bogus certificates wont match the fingerprint/hash stored in DNS.

Also, identification information should be removed from certificates. All that the browser and user should care about is that A.The computer they are talking to is the correct one for the domain (and not one owned by a bad guy) and that B.The public key they are using to secure the transaction matches a private key held on the correct computer and not one held by someone in the middle messing with traffic.

Browsers/end users shouldn’t need to care that http://www.paypal.com and its certificate are registered to “PayPal, Inc.”
or that some company has been paid big dollars to verify who “PayPal, Inc.” is, whether they are legit or not and whether they do in fact own the http://www.paypal.com domain (since we are assuming that whoever can change the secure DNSSEC records for that domain is acting on behalf of the legitimate owner of that domain)

It wont stop a bad guy from obtaining a certificate for http://www.paypal.ru and sending gigabytes of fake paypal emails claiming you need to log in using this http://www.paypal.ru url to safeguard your money. But neither does SSL as it stands now.

Elegie • April 4, 2011 10:38 PM

Dominic White has mentioned possible measures to reduce the chance of compromised CAs (or possibly even rogue CAs) causing security vulnerabilities. Among the measures that are mentioned are reducing the number of trusted root CA certificates and configuring a Web browser to require the use of OCSP (Online Certificate Status Check Protocol) validation for certificates that support OCSP.

http://singe.za.net/blog/archives/1026-Improving-Certificate-Security-in-Firefox4.html

At Freedom to Tinker, Dan Wallach has written about the issue of how to improve the security of the CA infrastructure (including the issues of “solutions” that are likely to be ineffective and how a Web browser should respond if a connection seems to be compromised):

http://www.freedom-to-tinker.com/blog/dwallach/building-better-ca-infrastructure

Dirk Praet • April 5, 2011 1:38 AM

When you are in the military, you accept the risk that you can get shot. If you’re a thief, chances are that sooner or later you will get caught and sent to prison. When you are in the trust business and you’re compromised, it is not entirely unlikely that your customers will lose trust and drop you. Since there was already little reason to trust CA’s anyway and the entire system has been argued to be broken for quite a while, Comodo has been added to my blacklist of entities to avoid or be very careful with, hoping DNSSEC and/or DANE will get more track in some not so distant future.

Ken M • April 5, 2011 2:15 AM

I seems like the only way to combat this incompetence and carelessness on the part of Comodo is with our pocketbooks.

If you encounter a retail site with a Comodo-signed certificate, don’t spend your money there. Or contact their customer support/sales and explain your concern that their site uses a certificate signed by an untrustworthy CA. Retailers go with Comodo for only one reason–they’re cheap. Make that poor decision cost them.

The browsers won’t make Comodo do anything but lip-service about putting in “safe guards,” but maybe we can make a difference.

Czerno • April 5, 2011 5:36 AM

@Ken M: I wouldn’t put all the blame on Comodo, in this occurrence it appears they discovered the compromise of their agent quicly and chose to do the right thing, noticing interested parties within /minutes/ rather than sweep the problem under the rug – who says other CAs don’t suffer similar or worse compromise but don’t go public about it ?

I think the problem is systemic and blaming one actor is not a step towards a solution. (I have no connection to Comodo whatsoever)

—
Cz.

Jonadab • April 5, 2011 7:34 AM

The correct solution is what OpenSSH does: forget about which company signed the stupid thing, and check whether it’s the SAME cert as when you visited the site previously. If it were handled that way, an MITM attack would only work if you’ve never visited the site before (in which case the attacker would have a pretty hard time predicting that you’re going to visit it and setting up a suitable MITM attack). In order to masquerade as Google or Yahoo (and get at the accounts of their users), the attacker would have to compromise servers at Google or Yahoo and get the cert from there.

Unfortunately, HTTPS isn’t set up that way. HTTPS is broken.

Paeniteo • April 5, 2011 8:37 AM

@Jonadab: “Unfortunately, HTTPS isn’t set up that way.”

The ‘poor man’s solution’ for oneself would be to use Firefox, optionally delete/disable all preinstalled CAs and work with the Certpatrol extension.

Certpatrol implements this “notify me if the cert changes” behaviour and additionally provides clues whether the change is likely to be legit (e.g., the certificate was about to expire and had to be replaced).

Paul • April 5, 2011 10:25 AM

All the modern browsers I have tried have support for 3rd party revocation lists. It seems to me that you could create an ssl watchdog group that could list various things like the comodo ca/ra cert.

Secure128 • April 6, 2011 2:16 PM

Bruce Schneier is on point here. There is absolutely no excuse for what Comodo did by allowing issuing access of it’s root system to resellers. Realistically Comodo’s root CA should be removed from browsers trusted list, requiring Comodo users to migrate to some other Certificate Authority that has it’s act together. Again Bruce is right here that financial reasons will likely prevent browser makers from doing what is right.

This is the key issue that has kept us at secure128.com from adding Comodo to our line up of discount SSL offerings. Even though we know we could sell them, there has to be a professional/ethical line drawn in the sand at some point.

J. Willson • September 20, 2011 10:15 AM

Bruce, could you please shine your light on TLS 1.0 proof of concept (BEAST cookie decrypting)
Thank you

Clive Robinson • September 20, 2011 3:20 PM

@ J.Willson,

“Bruce, could you please shine your light on TLS 1.0 proof of co cookie decrypting”

There are a couple of posts including some links over on the current Friday Squid page, if you’ve got any more links can you pop them there so we can all have a look, Thanks.

Johnanness • June 6, 2012 2:54 PM

At least on one US Govt computer, its appears that Comodo root CA was removed (and cannot be installed by a mere user) in IE and Chrome, but not Firefox.

Thomas Scharrer • December 4, 2013 4:42 PM

ICSWorld.com hacked me for over two years and they use fake COMODO certificates. I am going to sue them.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.