Jump to navigation

Poupou's Corner of the Web

Looking for perfect security? Try a wireless brick.
Otherwise you may find some unperfect stuff here...

Weblog

News flash: Cheap certificates are cheap!

In case you missed the news or update (as many other things have been happening lately) some CA has, not for the first time, issued bad certificates. E.g. issuing some SSL certificates to somebody (or some country) that is not the owner of the domain. If you trust that CA root (and it has many), then everything that it signed is, by default and until revoked/updated, trusted.

How does this affects Mono ?

Framework

Mono, by default, does not trust any CA root - this is not the job of a framework (it provides the plumbing, not the water).

There are several reasons for that (see the FAQ) but honestly there are very few people that needs to trust all 139 (as of today) CA roots (that mozroots could install). In fact the probability of having false certificates issued grows with the number of CA and the more of them you trust, the more likely you'll be affected.

Applications

For applications the main challenge is that they cannot (or at least should not) totally depend on the state of the user/machine certificate store(s).

Why ? It could be empty (e.g. Mono's default), it could have a lot of junk (e.g. old self-signed, test certificates) or it could include every CA known to this (and likely other) world(s).

OTOH (and unlike frameworks) applications generally knows what they want/need in order to execute properly. E.g. if you're using SSL to check for new mail on GMail then you can (and should) easily add a few check and refuse certificates that are not related to the job.

Now since I just told you not to (totally) depend on the certificate store(s) then you might feel you have something to do wrt the above issue. Have a look at this wiki page for some approaches. But if you're already dealing (and checking) for specific hosts then you're likely ok - unless your host(s) match of the fraudulent certificates.

If your code is more general (e.g. it can connect to anything) then you can resort to the browser solution: a blacklist. Here's some sample code that will refuse the known-to-be fraudulent certificates.

// to be used as the RemoteCertificateValidationCallback of an SslStream public static bool ValidateServerCertificate (object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors) { if (sslPolicyErrors != SslPolicyErrors.None) return false; // blacklist of known-to-be fraudulent certificates switch (certificate.GetSerialNumberString ()) { case "009239D5348F40D1695A745470E1F23F43": // addons.mozilla.org case "00D8F35F4EB7872B2DAB0692E315382FB0": // Global Trustee case "00B0B7133ED096F9B56FAE91C874BD3AC0": // login.live.com case "00E9028B9578E415DC1A710A2B88154447": // login.skype.com case "392A434F0E07DF1F8AA305DE34E0C229": // login.yahoo.com_2 case "3E75CED46B693021218830AE86A82A71": // login.yahoo.com_3 case "00D7558FDAF5F1105BB213282B707729A3": // login.yahoo.com case "047ECBE9FCA55F7BD09EAE36E10CAE1E": // mail.google.com case "00F5C86AF36162F13A64F54F6DC9587C06": // www.google.com return false; default: return true; // or your own existing logic } }

Users

How many people have the keys to your home ? Scrap that - no matter the number, the fewer the better. Now curious about how many CA you're currently trusting ?

~ @ certmgr -m -list -c Trust | grep "Unique Hash" | wc -l
0
~ @ certmgr -list -c Trust | grep "Unique Hash" | wc -l
140

Yep, I executed mozroots to see how many certificates would be added but it won't stay that high very long ;-). More details in certmgr documentation to remove (all/some) of them.

Update: Instructions for using certmgr to remove the CA root that signed the bad certificates.


3/24/2011 09:43:17 | Comments

The views expressed on this website/weblog are mine alone and do not necessarily reflect the views of my employer.