Weblog
News flash: Cheap certificates are cheap!
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.
