Untrusted Certificates


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’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’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 “reminder” 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’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.

And here the disclosure:

Mozilla’s new home page Certificate Details More Certificate Details

Please see update. In order to confirm for yourself, edit the hosts file at your computer and add the following entry:

192.116.242.23    www.mozilla.com
192.116.242.23    mozilla.com

On Linux and Mac that would be in /etc/hosts, for Windows it’s most likely in C:\Windows\System32\drivers\etc\hosts. Navigate with your browser to https://www.mozilla.com/ and enjoy Mozilla’s new home page. Don’t forget to delete the entry in the hosts file once you are done.

Needless to say that I’m deeply disappointed and can only ask myself - how and why is this possible? This proves clearly non-conformance of the Mozilla CA Policy and that of other browser vendors. This isn’t a bug or flaw in their system, this is simply pissing on all of us - browser vendors, subscribers, relying parties and the Internet at large. See the detailed walk-through here.

Information and Links

Join the fray by commenting, tracking what others have to say, or linking to it from your blog.


Other Posts
Full Disclosure
Nightly Signs

Write a Comment

Take a moment to comment and tell us what you think. Some basic HTML is allowed for formatting.

You must be logged in to post a comment. Click here to login.

Reader Comments

To paraphrase Matt Blaze: “A commercial certification authority [except StartSSL] protects you from anyone whose money they refuse to take.”

To get a better price on multiple site certificates, years ago we became agents for a commercial CA that is now a unit of the largest one (in keeping with the culture of inauthenticity in the CA industry they do not publicize that fact.) Absolutely no vetting of our business was required.

Apparently Comodo revoked the certificate after I posted the story to the mozilla.dev.tech.crypto mailing list. Just disable OCSP validation checking of the browser to see all the glory.

Bug 470897 has been filed at Mozilla by Nelson Bolyard (Mr. SSL) to address this issue.

Upon request I’ve taken down the mozilla.com sites. The certificate is still available from here.

I wrote a similiar article back in 2003.

Here it comes:

http://jooray.soup.io/post/10105517/State-of-art-certificates-Whom-do-you

Seems nothing has changed in five years.

I’ve read your article and to all of my knowledge, the case of Comodo now is much more sever since no validation was done at all. In your case some domain control validation was done, e.g. if you control the WHOIS records and mail servers of the domain, you are in control of the domain. Obviously it’s possible to gain control of the domain account at the registrar and this is certainly phishable. Good security at the registrar are important. But that’s another story.

I’ve been following the mozilla.dev.tech.crypto discussion. As I understand it, basically a Mozilla-blessed CA failed to do its fundamental duty of verifying a requester’s identity to any degree.

The fact that they did this by using a third party matters little to me. I have de-configured my trust for The USERTRUST Network, AddTrust, and Comodo CA Limited and have warned friends to do the same.

Why are CAs trying to hide their relationships with agents? I can only imagine it’s an attempt to distance themselves from potentially shoddy work while continuing to receive profits. Any CA I find engaging in this subterfuge will be similarly de-authorized.

Also, Mozilla themselves are on the verge of becoming untrustworthy regarding how they handle misbehaving CAs. I await their response. If they fail to assure the trustworthiness of their CAs, that would be a sign to me of a coming era of truly disruptive change. I wouldn’t abandon Firefox, but I would find a way to abandon Mozilla’s CA list.

Eddy Nigg, thanks for pointing out this incident. I realize your position as a CA competitor makes this a delicate situation. Perhaps within the circles you typically communicate this fact of your role is well known, but as an outsider coming to the matter I had to find out for myself and that didn’t cast you in the best light. I would have preferred that you express that boldly in this blog post.

Still, publicly disclosing the incident was the correct thing to do, so thanks for that.

Thanks do-un-to! Yes, anybody following my blog or other circles where I’m active is fairly familiar with my position. Incidentally I did not want to appear to be advertising for StartCom in this article, hence I refrained from any mentioning, but I realize that for those not knowing me, it could be confusing. Nevertheless, my blog, who I am and what I stand for doesn’t try hide that fact either. I’m convinced that I can work for the good of PKI security in general and for the good of the certification authority I’m responsible for at the same time. Other CAs are active in other circles and forums as well, such as the CA/Browser forum, RSA and other circles. Also for those reading this message, I suggest to read the following statement from me.

And now there’s yet another security hole discovered made possible by the sloppy practices of some CAs. Even though it has been known for a while that MD5 hash can no longer be considered secure, apparently some CAs are still signing certificates using MD5+RSA digital signatures. Here is a recent article from someone who has demonstrated creating a bogus intermediate cert with arbitrary identifying information with a valid signature from a CA, created starting from a legitimately signed specially crafted certificate obtained from that CA.

MD5 considered harmful today:
Creating a rogue CA certificate

http://www.win.tue.nl/hashclash/rogue-ca/

[…] that has now changed as this blogger has discovered.  (Slashdot discussion here.)  I confirmed that the mozilla.com cert that blogger set up does in […]

About how to do post event investigation of an SSL MITM attack:
http://www.netresec.com/?page=Blog&month=2011-03&post=Network-Forensic-Analysis-of-SSL-MITM-Attacks