Perfect MITM Attacks With No-Check SSL Certs

StartCom writes "In a previous article I reported about Man-In-The-Middle attacks and spotlighted an example showing that they really happen. MITM attacks just got easier. In the attack described previously, untrusted certificates from an unknown issuer were used. Want to make the attack perfect with no error and a fully trusted certificate? No problem, just head over to one of Comodo's resellers. Screenshots and disclosure provided at the link."

Comments

Don't do this at home

[moro_666]

While the link is already being slashdotted ...

I hope the article author understands that unless he's really lucky, he is in deep legal trouble already. It's not the first time that the messenger was slaughtered, although the message was honorable.

Gotta think over the SSL certs one more. I never really liked the mechanism behind it, i like it even less now.

Re:Don't do this at home

[Anonymous Coward]

source of the slashdotted page :

----
In a previous article I reported about Man-In-The-Middle (MITM) attacks and if they really happen. Unfortunately it does happen as some testimonials confirm. Now itâ(TM)s even easier because in the attack described previously, untrusted certificates from an unknown issuer were used. Want to make the attack perfect with no error and fully trusted certificate? No problem, just head over to one of Comodoâ(TM)s resellers.

In an unrelated event which was briefly mentioned at the dev.tech.crypto mailing list of Mozilla, something strange happened. During my attempt to verify and understand who stands behind the sending of fraudulent âoereminderâ email messages tricking our customers, I created a certificate from the source I was following. And my certificate was issued without any further questions.

This prompted me to create another certificate through them, but this time by using a domain name which should never be issued to me. For the purpose of testing, I selected the domain mozilla.com (Iâ(TM)m certain they will forgive me). Five minutes later I was in the possession of a legitimate certificate issued to mozilla.com - no questions asked - no verification checks done - no control validation - no subscriber agreement presented, nothing.

With the understanding about MITM attacks, the severity of this practice is obvious. No encryption is worth anything if an attacker can implant himself between the client and the server. With a completely legitimate and trusted certificate, the attack is perfect. No warning and no error.

--
there you go, have a nice xmas and slashdot less

Re:Don't do this at home

[Timothy Brownawell]

Gotta think over the SSL certs one more. I never really liked the mechanism behind it, i like it even less now.

The current mechanism is that the site owner pays a particular CA to identify them, and end-users/browsers trust any CA to identify any site (they can't know which CA the site owner actually paid). Site owners (the ones paying the bills) have no incentive to demand that the CA be competent.

A better system would have the end-user pay someone they trust to identify the site; they are directly paying for the identification service and can take their business elsewhere if they get crap service. This would also mean that the site owners don't have to pay someone who, really, can't actually provide any assurances to the end-users (because all CA-signed certs are treated the same). Better to just have everyone go self-signed, and then let someone (paid by the end-users) keep records of who used what cert when as seen by what network routes.

Mapping to real-world identities is a separate issue (only provided by "extended validation" or whatever certs due to browser UI issues), and is (1) rather expensive because you need people involved to look at paperwork and such and (2) mostly isn't needed, because you'll generally find IRL groups' sites by communication from those groups (eg, my electric bill has the electric company's URL printed on it, I don't need to look them up in google and then verify that I got pointed to the right place).

Re:Don't do this at home

[cp.tar]

Oh, dear. So who certifies the certifiers?

Re:Don't do this at home

[jonbryce]

The suppliers of web browsers - Microsoft, Mozilla, Opera, Apple (Safari), KDE (Konqueror), Google (Chrome).

Re:Don't do this at home

[Anonymous Coward]

Pesronally I'd like VISA and Mastercard to give me Root CA certs to use for purchasing on line - then if they foul up and someone gets a dodgy cert then they pick up the bill.

As it is, I don't think anyone would be liable (except yourself) to pick up the cost of shenanigans

Re:Don't do this at home

[betterunixthanunix]

The problem with the system you described is that it relies on end users to understand what is happening. Most FF or IE users have no understanding of what a certificate even is, how it works, or how a MITM attack works. If you told end users that they would pay for identification services, every scam artist on earth would be setting up their own CA and charging users for the root signing certificate, which would then be used for MITM attacks. Worse, the idea that end users could try and verify self-signed certificates is preposterous also, and again, scam artists would be all over it.

From a security standpoint, the current system is pretty much the best you can hope for. People who presumably know what they are doing select your CA roots for you; a mistake there is equivalent to a buffer overflow that allows an attacker to install a key logger. The CAs, wishing to remain in business, have an incentive to do some level of checking on who they issue certificates to: if it became known that a CA was just signing any CSR, with no checks whatsoever, software makers would stop shipping their public key, and legitimate users would not pay for a signature. This, by the way, is the incentive for site owners to buy signatures from competent CAs: an incompetent CA is likely to not have their public key shipped with popular software, so their signatures are worthless.

It's not common for a CA public key to be removed from a software package, because of the ruckus it would create (potentially thousands of websites suddenly having untrusted certificates), but if a CA has truly incompetent practices, then yes, their public key will be removed. In general, software makers try to hold CAs to high standards to get their public key shipped with the software in the first place, so unless the CA itself allows its practices to worsen, it is unlikely that they would find themselves in that position.

Trusting a third party for security is tough, but if you are smart enough to be aware of that, then you should also be aware that you can personally add or remove CA public keys from any software that you use. If you feel that Comodo is untrustworthy, remove their public key, and every time you get a warning, report it to the owner of the website you were trying to visit.

Re:Don't do this at home

[Anonymous Coward]

I have a much bigger concern. Who certifies those who certify the certifiers?

Re:Don't do this at home

[iammani]

Folks who are surprised should definitely check out the list of Certificate Authorities. In Firefox Prefences -> Advanced -> Encryption -> View Certificates -> Authorities Tab

The first one is TÃoeRKTRUST Elektronik Sertifika HizmetSaÄYlayıcısı.

And its much worse in IE -- Internet Option-> Certificates -> Trusted Root Cert. Autho. I have not heard of 25% of the Authorities.

As the wise put it, security is only as strong as the weakest link.

Re:Don't do this at home

[Nursie]

Unless you've already decided that you don't trust Comodo, for this reason, and have struck them from your list of trusted authorities.

Re:Don't do this at home

[TheLink]

And they don't care about security (nor do the users).

That's why self-signed certs aren't really more risky than CA signed certs in practice.

http://it.slashdot.org/comments.pl?sid=1041927&cid=25890305

http://ask.slashdot.org/comments.pl?sid=534356&cid=23199022

I've probably posted others, but I bet "everyone" is still going to leave the dozens of CA certs in their browsers, and Mozilla and friends aren't going to do the SSH style thing - warn user if the cert changes for whatever reason- even if it's a valid cert.

I'd like to know if my bank's cert suddenly changed from the old cert to some cert signed by some CA in Elbonia. :)

Re:Don't do this at home

[Ed Avis]

if a CA has truly incompetent practices, then yes, their public key will be removed.

Clearly not the case, since Comodo is still trusted.

The browser maker (or someone else - the government security agency?) would need a team of people constantly testing the certificate issuers, trying every ruse possible to get bogus certificates issued. If any issuer fell for it then they would be struck off the list of trusted issuers (and the updated list would be pushed out as a security update). I don't see this happening.

Re:Don't do this at home

[gomiam]

...your local psychiatrist?

Re:Don't do this at home

[ScreamingCactus]

Simple. We give the MITM attackers the power to certify the certifiers. That way we have a system of checks and balances.

Re:Don't do this at home

[mpe]

I've probably posted others, but I bet "everyone" is still going to leave the dozens of CA certs in their browsers, and Mozilla and friends aren't going to do the SSH style thing - warn user if the cert changes for whatever reason

Which would be the most sensible thing. Especially if the old certificate was nowhere near due to expire and the details on the new one are very different.

even if it's a valid cert.

"Valid" in this context meaning somehow connected to a CA trusted by the browser. Which in this kind of case may be less trustworthy than a self signed certificate. But guess which one Firefox 3 is going to make a song and dance about...

Re:Don't do this at home

[Actually, I do RTFA]

As it is, I don't think anyone would be liable (except yourself) to pick up the cost of shenanigans

It depends on the country. Two friends of mine were mugged, and their wallets stolen. The one with a US credit card made a call, got the charges reversed, and a new card in the mail. No pain. My other friend from South America was on the hook for the thousands of USD that the crooks rang up, and couldn't even cancel it until the next morning.

Re:Don't do this at home

[Rich0]

I've been following the mozilla cacert bug for years. They've held off on including them as a trusted root because they haven't passed an expensive audit. However, their automated checks at least ensure that you have control of the domain that you're requesting a certificate for.

I've always thought that this would be a good approach for issuing free or dirt cheap certificates: When somebody applies for a certificate they are given some file to serve up from their webroot. Every week for three weeks a new file is provided. The domain is randomly checked over that period of three weeks to ensure that all the provided files are being served. After this, the certificate is issued. Renewals would follow a similar process (but with a reminder sent out well in advance so that the checks could take place well before expiry).

It is unlikely that somebody could exercise this level of control for an extended period of time simply via DNS spoofing or advertising bad routes. However, the issued certificate would only include the domain, and would not certify owner details (name/address/phone/etc). To obtain a cert with these credentials I think that a more intensive check would be prudent.

The current system basically amounts to a tax on SSL, and little more. If you pay some money to some auditor you can get into the SSL certificate business.

Also - SSL should allow certificate-less operation. Sure, that is vulnerable to MITM, but at least it is better than unencrypted http. Perhaps we should have more than two tiers of security (completely insecure, and "completely" secure).

Re:Don't do this at home

[kabloom]

Nobody. They don't have an HTTPS site.

Re:Don't do this at home

[starfishsystems]

That's why self-signed certs aren't really more risky than CA signed certs in practice.

I made a variation of this point to management where I worked a couple of years ago. My purpose was to promote the idea of building a corporate PKI rooted in our own Certificate Authority. You can think of this as a self-signed cert with structure.

The initiative had particular value for us because we deploy and remotely manage a large population of network appliances at customer sites. It's far more efficient for a web client to install a single CA cert than to request trust for each of the hundreds of server certs individually. Moreover, if a rogue cert ever does pop up, the chain will not silently resolve to our CA cert. (It might, as the article points out, resolve to some careless CA, whose reputation, I hope, will diminish accordingly. But I wasn't trying to improve certificate practices worldwide.)

Anyway, management was fine with the part about server authentication for our internal operations. Management was much more hesitant about giving out our CA cert to customers and partners in order to connect to our portals.

Why? The answer, as best I could understand, was the risk of a perception by customers that installing our CA cert would somehow weaken the security of their browsers. And so, because of this perception, we instead sent cert requests to a commercial CA, which as far as I can tell performed no verification whatever on the requests, apart from billing for whatever that may be worth. This was for the "industrial grade" certs, no less, the ones which were supposed to trigger identity checks on the requestor.

So it seems that perception trumps reality just as commercial CAs would wish in their wildest dreams. A CA cert explicitly given to you out of band by a known entity is perceived as less strong than a preinstalled CA cert from a completely unknown entity with questionable practices. Hmm. We have a way to go.

Re:Don't do this at home

[profplump]

Or just make users choose their card type before you present an input box for the number and redirect to the appropriate domain.

Alternatively you could take a PayPal approach, where the retailer directs me to visa.com and I input secret data there, authorizing payment back to the retailer without giving the retailer any secret information or trusting their certificate at all (other than to hide my purchasing/browsing history from snooping).

I know Visa et. al don't want to be in that business, but it's a significantly more secure approach -- I can trust the CA issued by Visa for purchases I make with Visa and I can avoid giving my secret data to anyone that doesn't already have a copy.

Re:Don't do this at home

[Kadin2048]

Well, I have to admit I was surprised. I hadn't looked at the list of CAs in a while; it seems like the last time I went in there, it only had a handful of entries in it. (Verisign, Thawte, maybe a couple of others.)

I'm giving some very serious thought right now to just deleting every company on that list that I haven't heard of, or that I don't think has enough of a profile to be seriously harmed by allegations of sloppy issuing. Although from some other comments in the thread it sounds like even the big-name CAs have been lazy for years and haven't gotten called on it.

Having a bunch of Turkish CAs in my trusted root doesn't seem like it adds much in the way of security; the chances of me accessing a site that's legitimately using a cert from them -- near zero -- seems significantly lower than someone taking advantage of them to create a fake cert for my bank. (Not necessarily because their security is worse than a US-based CA, but just because while there's a chance someone at the US CA might have heard of my bank and think that it's funny someone's requesting a CA from their domain, I doubt anyone at the Turkish CA would have heard of it. If I were going to get a forged cert, I'd definitely go to a CA where they'd be unfamiliar with the target, just to stack the odds that much more in my favor. So it would seem that only having "local" CAs, ones you're likely to encounter legitimate certs from, in your trust chain is probably a good idea. Someone in Turkey might want to get rid of the minor US certifiers if they don't use them, too.)

Perhaps at some point during the browser-installation process, users should be prompted to select what countries, regions, or jurisdictions they're interested in installing CA certs for. The question could be phrased as "in what countries do you regularly do e-business or use secure web sites?" or something similar. Sure, this would eliminate much of the international market for CAs -- US-based ebusiness sites couldn't shop around for certificates quite as much as they perhaps do now, and vice versa -- but I think that would be significantly better than allowing the whole idea of certificates to be undermined into uselessness.

Of course, maybe that's just rearranging the deck chairs on the Titanic, and the safest thing to do is just throw away the whole paid Certificate Authority concept, blow away all the preinstalled CAs, and then have users build up trust on a per-site basis. This assumes users won't be stupid about what they accept, though, so it's probably doomed from the start.

Re:Don't do this at home

[u38cg]

The problem is the economic incentives. Do the roots have an economic incentive to verify all the parties it certifies? No, they have an incentive to sell as many certificates as possible. Browsers should not include certificates and users should pay for a subscription to a certificate authority *they* choose to trust. That would put the incentive boot on the other foot.

Really now.

[cp.tar]

The example cited is "RESOLVED INVALID". The link to the "perfect attack" seems to be slashdotted. And at the time I started writing this comment, there have been no comments whatsoever.

Does this mean that Slashdotters have all swarmed the link trying to find out how to execute the perfect attack? Are we seeing a new trend here, with people actually reading TFAs?

Or is it that too many people have Greasemonkey scripts filtering out kdawson's posts?

Re:Really now.

[ghmh]

Apparently the perfect attack is actually 'Slashdot in the Middle'

Re:Really now.

[daveewart]

The example cited is "RESOLVED INVALID"

That's because the behaviour reported in the bug (the actual MITM attack) is *not* a problem with Firefox as suspected by the reporter: Firefox was behaving correctly by identifying the SSL certificates as invalid. It is however an interesting report of a MITM attack.

Looks like DDOS beats all

[00_NOP]

It had "0" comments when I started and I still could not RTFA

Re:nothing new

[neumayr]

The author's point was that he could get a signed cert the says mozilla.org.
Should have tried paypal.com, but I guess he didn't want too much legal trouble.

OK, which CA must leave the trusted list?

[Anonymous Coward]

There's only one way the CA system can work: Responsibility and repercussions. If a certificate authority signs forged certificates, then it can no longer be trusted and must be removed from the list of trusted CAs. To trust an untrustworthy CA is a security bug and should trigger updates from all browser developers which remove the offending CA. Make the CAs work for their money.

Re:OK, which CA must leave the trusted list?

[bunratty]

Telling them to do a better job now does no good if they've been issuing valid certificates to bad guys already. If they were not doing the proper validation of individuals who were requesting certificates, we need to consider all certificates issued by that CA to be untrusted.

Re:OK, which CA must leave the trusted list?

[bunratty]

Microsoft maintains the list for IE. Mozilla maintains the list for Firefox. And so on. Use a browser from a company you can trust, or you may just regret it one day.

Re:OK, which CA must leave the trusted list?

[timeOday]

How can we trust that the list of trusted CAs is valid and up to date? Who maintains this list? Me? You? The Scam Artists? A central trust agency? The Government?

Go ahead and accuse me of not being libertarian, but yes, I think making and enforcing standards for CAs is a good role for the government. I would never put my money in an unregulated bank, or send premiums to an unregulated insurer, or go to a back-alley doctor.

Re:OK, which CA must leave the trusted list?

[Kent Recal]

So, who will step forward and remove such authorities from the CA list? Mozilla? Opera? Microsoft even?

Something tells me that no one will and nothing will happen. The dust will settle, the offending CA will, at best, adjust their practices slightly but not effectively - and within 6 months we'll see more CAs pop up left and right using the same broken procedures.

There's just too much money involved in this game. Owning a CA authority is effectively a license to print money and the beancounters everywhere will just keep on repeating their mistakes over and over in order to "streamline" the process for "optimized revenues". I would even go as far to suspect that this *might* be a PR stunt to drive more people into the horridly expensive "green addressbar" certs (and wait for it, we'll see more colors in the future, for even more security!).

The only technically correct way out of this would be to abandon this broken and tainted system altogether.
But it's not gonna happen, VeriSign and friends will make sure of that with all their weight.

Re:OK, which CA must leave the trusted list?

[maxume]

As a user of Firefox, that's fine with me (the entire point of the certificate system is to provide security; in that context, features and convenience are lower priorities than actually providing security).

Basically, my neighbor's paper house is not a good reason for me to leave my doors unlocked.

Re:OK, which CA must leave the trusted list?

[Vellmont]

but yes, I think making and enforcing standards for CAs is a good role for the government.

Which "the government" are you talking about here? You might have noticed the internet is worldwide, and there's no single authority to control it. Browser makers are also free to put whatever CA's root certificates in their browsers that they wish (along with all anyone else who distributes software that uses an x509 certificate).

Re:OK, which CA must leave the trusted list?

[Wonko the Sane]

Silly americans and their megalomaniatic view of the world, (mod me flamebait) you guys are not the center of the world, nor the policemen of the nations.

I really don't think that the evidence supports your assertions. There is a difference between "are not" and "shouldn't be".

Re:OK, which CA must leave the trusted list?

[timeOday]

I guess this is my fault for mentioning libertariansm in the first place. For the record, I think it's a great idea in an imaginary perfect world where everybody has complete access to all information, dishonesty is abolished, natural resources are infinite (so each of us can breathe our own air, etc), and everybody starts life on equal footing (access to education, proclivity to illness, etc). Which is to say, it's exactly as practical as Communism and every other idealization that never seems to get fully proven or disproven because it can never actually exist.

Re:OK, which CA must leave the trusted list?

[dubbreak]

but yes, I think making and enforcing standards for CAs is a good role for the government.

Which "the government" are you talking about here? ...

I nominate Canada. They seem to be a respected world power. Everyone will be willing to listen to them.

Another reference

[Slite01]

While the original blog is slashdotted, please enjoy this link to Google Groups: http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/9c0cc829204487bf?pli=1

Sensationalist - reroute & self signed certs

[owlstead]

What's so perfect about the attack listed? It clearly shows up that the certificate is not trusted. With the new and improved, (and for me, irritating) screens of Firefox, where you are clearly warned, this should not be such a big problem.

What I don't get is that they do not try and locate the idiot trying to do this. Because that is one of the problems with these kind of man in the middle attacks - a single person that does actively goes after you can do some damage. This makes such attacks harder to perform, even if they are technically feasible.

Maybe they should make it even clearer that you should not use self signed certificates for banks and such, but this is far away from the IE bug that let leaf certificates (with some missing key usages) sign other certificates with any URL.

I've created one of those attacks on a corporate LAN (just for show, using a proxy) ages ago. Guess that made me a script kiddie :)

Re:Sensationalist - reroute & self signed cert

[bunratty]

In the perfect attack, the certificate is issued by a trusted certificate authority, so no warning is shown. It truly is a perfect MITM attack. We do know exactly who is issuing certificates without verifying the identify of the individuals requesting them. It's time for browser makers to remove some trusted CAs from their lists so users can be secure.

Use your OWN certs... or use CACert.org's

[fibrewire]

CAcert certificates are pretty nice because they are FREE!!! even if they need to become a little more responsible in the near future. The cool thing about "Free" is the value is in innovation, because it's the only way to survive being free in the first place. Maybe tie CAcerts to an OpenID??? Honestly, you get what you pay for... friends... hookers... etc.

Who trusts the trusters?

[Gothmolly]

If a CA doesn't properly validate who you are and cuts you a cert for anyone else, its a problem with CA, not the underlying codebase(s).

So, what's the big deal

[guruevi]

The dude found out that you can have self-signed certificates or certificates signed with whatever CA you want. Here's another MITM angle: you can set up your own root CA (http://www.onlamp.com/pub/a/onlamp/2003/02/06/linuxhacks.html) and you can even become an intermediary (Secondary) CA authority by paying Verisign, Equifax or Thawte. Heck, if you pay enough money to Microsoft, Mozilla or Opera and adhere to certain standards they will include your servers in their set of root certificates.

SSL is not supposed to be preventing MITM nor is it supposed to be for identifying purposes. We have other technologies for that like PGP but the internet relies on anonymity so you're never 100% sure that you're going to talk to the correct persons. Even with PGP, your initial communications will have to be trusted (eg. you personally hand over or get a key) or any subsequent communications will be compromised. SSL doesn't even go that far because every communication is viewed as an initial communication. If the certificate is re-signed or changed to another CA the next day, your browser will not complain as long as that CA is in it's trusted root certificates.

I personally think it's the government's fault that PGP didn't break through as a good authentication scheme because of their export limitations on firearms and it took a while before it was circumvented by opening up the standard. It's the browsers fault and the CA's as well (with VeriSign the biggest) by asserting that SSL certificates can be used to authenticate an entity rather than a communications. Lately there came to be the SSL-extensions but it's a) too little too late b) bolted on c) not a solution since that information can also be falsified using the exact same methods as described in the article since all it takes is a 'rogue' SSL signer that doesn't do it's job (or somebody impersonating the entity)

Re:So, what's the big deal

[agwadude]

SSL is not supposed to be preventing MITM nor is it supposed to be for identifying purposes.

I disagree. Why else does SSL have certificate signing capabilities? SSL even has client-side certificates for client identification, though it isn't widely used in HTTPS. In order for any asymmetric cryptosystem to work you need to exchange public keys, and you always have to establish some kind of trust system for those keys.

We have other technologies for that like PGP but the internet relies on anonymity so you're never 100% sure that you're going to talk to the correct persons.

Hence the need for SSL.

Even with PGP, your initial communications will have to be trusted (eg. you personally hand over or get a key) or any subsequent communications will be compromised. SSL doesn't even go that far because every communication is viewed as an initial communication. If the certificate is re-signed or changed to another CA the next day, your browser will not complain as long as that CA is in it's trusted root certificates.

This is a fault of how the key management in SSL has been implemented in web browsers, but says nothing about the technology itself. Two examples of systems using SSL with better (but less convenient) key management systems are OpenSSH and OpenVPN.

It's the browsers fault and the CA's as well (with VeriSign the biggest) by asserting that SSL certificates can be used to authenticate an entity rather than a communications.

There's a middle ground between "entity" and "communications." Yes, it is very difficult to verify that a certificate is being issued to the entity "Bank of America," but it should not be hard to verify that you're issuing a certificate to the domain name www.bankofamerica.com. And the latter is all you need to protect against MITM.

Big trouble at PositiveSSL.

[Animats]

The article is confusing, and the author declines to name the certificate issuer that's the problem. But the screenshot gives the details. It's PositiveSSL. He really did get PositiveSSL to issue him a Comodo-authorized cert in the name of "www.mozilla.com". Try this link and look at the certificate details.

It looks like certificates with this issuer information need to be rejected:

• CN = PositiveSSL CA
• O = Comodo CA Limited
• L = Salford
• ST = Greater Manchester
• C = GB

I loaded all current Comodo certificate revocation lists, and this bogus certificate has not been revoked.

Some Comodo CA root certificate needs to be removed from the approved list.

Re:Certificate revoked already

[c_g_hills]

Update: a bug has been opened to handle this incident. It seems the offending company was spamming, and nowhere did they state that they were a reseller for Comodo, nor were there any ownership checks done before issuing the certificate.

Addtrust, and Comodo.

[Animats]

Looking at this cert further, it's a very wierd certificate. "Issuer" of ""www.mozilla.com" has "O=Comodo CA Limited". That's descended from "Positive SSL CA", for which "Issuer" has "O = The USERTRUST Network". That's descended from "UTN-USERFirst-Hardware", for which Issuer has "O = AddTrust AB". That's descended from "AddTrust External CA Root". Why is a Comodo cert being issued under AddTrust? Comodo is a root CA itself, with its own root certs in major browsers. Something is not right here.

So who's AddTrust? Their web site says "Under Reconstruction". This does not look good. Checking the Internet Archive, we find "JOIN THE ADDTRUST FAMILY Gain an edge over your competitors by providing co-branded PKI services"

AddTrust went beyond using resellers. They apparently allowed subordinate CAs to issue certs in AddTrust's name: AddTrust's rapid Trust Service Provider (Licensee) start-up package allows you to deliver cutting-edge public key infrastructure (PKI) services cost-effectively and in a way that best complements your business model. Literally within months you can start selling pre-packaged outsourced PKI services allowing your customers ... AddTrust's globally recognized PKI brand is designed for co-branding with companies recognized for high-quality IT services and products. ... Rather than relying on external certification authorities, you can easily provide high-end certificates yourself by becoming an AddTrust-licensed Trust Service Provider. This allows you to decide how much of the underlying secure infrastructure you want to run and invest in yourself.

The relationship between Comodo and AddTrust is mentioned in this email. Robin Aldin of Comodo wrote: There is no ongoing relationship with AddTrust AB, Sweden. I'm not even sure if AddTrust AB still exists as a company. I think AddTrust may exist now only as a brand of ScandTrust AB. Sweden - although Comodo does have the right to continue using the root CA certificates which we purchased from them and which bear the AddTrust name.

So the party ultimately responsible for this certificate is out of business?

Efforts underway to resolve problem.

[Animats]

This subject is being discussed by Firefox developers, Comodo CA people, the person who reported the problem, and somebody named "Patricia" from CertStar, the issuer, here.

Robert Alden of Comodo says they "have suspended Certstar's reseller activities until our investigation has been completed." The CertStar site now says "Due to technical issues we are unable to process orders at this time. We are working hard to resolve the issue and apologize for any convenience caused. Please check back later."

The Mozilla team is discussing revoking some root CA keys.

Firefox is right to warn.

[tjstork]

The company that I worked at used a MITM attack with self signed certificates to read everyone's HTTPS stuff during the financial crisis. I was quite surprised to find that my bank and my broker's certificates were rejected by my Firefox, and that, upon inspection, the issuer was actually my company. IE, company issued, didn't warn me, and neither did Chrome, and I have to confess that when Firefox complained, I would often switch to Chrome, because it didn't. Then, one day I looked at the certificate in Firefox, and I discovered just what that warning meant. My company was spying on me.

Re:Firefox is right to warn.

[StartCom]

That's because your company distributed their root or server certificate with the active directory or domain controller. Chrome currently relies on the windows cert store so does IE obviously. Not so Mozilla Firefox and hence the error.