Slashdot Mirror
Microsoft Blacklists Fake Finnish Certificate
jones_supa writes Microsoft has issued a warning that a fraudulent SSL digital certificate has been issued in the name of a Finnish version of its Windows Live service. Although the company says it has revoked the certificate, security experts warn that older software may continue to "trust" the known bad certificate for months or even years, and that attackers could use it to trick users into running malware. "Microsoft is aware of an improperly issued SSL certificate for the domain 'live.fi' that could be used in attempts to spoof content, perform phishing attacks or perform man-in-the-middle attacks," Microsoft says in a March 16 security alert. "It cannot be used to issue other certificates, impersonate other domains or sign code. This issue affects all supported releases of Microsoft Windows. Microsoft is not currently aware of attacks related to this issue."
The man let Microsoft know he got the cert just by asking. JUST BY ASKING! AND LET THEM KNOW ABOUT IT!
Steve Gibson (@SGgrc), of GRC.com fame, has already explained this on his latest "Security Now" podcast. It was sort of a joke/gimmick from someone trying to make a point about the insecurity of certificate authorities. The summary here is absolute flamebait, getting things WAY out of proportion. Weird. Listen to it and you'll see what I mean.
Then you can get a certificate for that domain, even if you only have access to that mail address for a short while. That's how securely the CA hierarchy protects you. That's the level of scrutiny you can expect from CAs that your browser trusts.
he says there is a problem with my windows.
This is the second time this has happened to Microsoft. You'd think after the first time someone was able to register an administrator address @live.com they would have brainstormed all the names that might possibly be considered special, or hell, just checked which ones are being used this way, and then reserved them. How many can there possibly be? 10?
We can argue about whether sending an email is a good way to verify ownership of a domain or not, but really, someone who could register hostmaster@live.fi could play all sorts of social engineering games quite outside of the CA system.
I don't think I'll ever have any need to hit up .fi or .co.uk or .ca or .in or whateverthefuck other third world countries think they deserve to be on the internet.
So I block them all in my hosts file.
It took quite a bit of searching before I could identify the specific root certificate involved. It turns out that root was already marked as "untrusted", which means I would not have been affected by this problem.
Also, the subscriber certificate involved is apparently marked as revoked in OCSP (Online Certificate Status Protocol) messages. Those who set their browsers to always confirm the validity of subscriber certificates via an OCSP server and who also set their browsers to assume a subscriber certificate is invalid if an OCSP response cannot be obtained are well protected from this problem.
Of course, for this solutions to be implemented, users must have browsers that allow root certificates to be marked "untrusted", that have an option to check certificates against OCSP servers, and that have an option to assume that a certificate is invalid if an OCSP response cannot be obtained. Mozilla-based browsers -- Firefox and SeaMonkey -- have all of those capabilities.
Your browser does not require EV certificates.
Let us be clear: SSL hs been demonstrated as vulnerable to top-down attacks, to signature authorities failing to protect or being willing to abuse their signature authorities. The classic example was DigiNotar, but there have certainly been other fake certificates published. If you combine this with the number of hosted web proxies and poorly managed websites with poorly protected wildcard SSL certificates on them, it's not safe to place too much trust in SSL certificates as a form of signature authority. It's too difficult to trace the "path of trust" for a certificate to have full confidence in it, especially with such carelessness in the market place.
So let's be aware that SSL is helpful against casual monitoring. But the certificates should not be considered sufficient for critical data: a separate verification channel, such as GPG signatures or checksum verifications presented on a different information channel, should be used for verification of the content of the most sensitive data, Even modest encryption practices such as "zip" encrypting a file and sending the key _separately_ can help protect data from casual man-in-the-middle attacks: I've found GPG to be more technologically robust with a very useful chain-of-trust model, but it's not well enough integrated for many of my non-technical clients to use well.
Or if you can listen to email traffic sent to hostmaster@somedomain.tld :(
Hooray for default unencrypted email.