A cryptographic certificate Microsoft generated three weeks ago to authenticate the servers used to deliver updates to hundreds of millions of Windows users has received a failing grade from a widely used automated analysis tool. While the SSL Labs report card is prompting plenty of discussion in security circles, it's too early to conclude the credentials certifying the legitimacy of update.microsoft.com aren't safe, one of the engineers who designed the grading service said.

Microsoft generated the certificate on May 30, around the same time it learned that the Flame espionage malware hijacked the Windows Update process so it could spread from PC to PC inside a targeted network. It was later revealed that the hijacking technique required world-class mathematicians and scientists to execute a cryptographic collision attack in the underlying MD5 hashing algorithm. The precise variant had never been seen before in the research community.

The new certificate came as Microsoft revamped Windows Update to prevent such attacks from working in the future. But because the credential isn't used to encrypt or authenticate an actual website, the grade of "F" returned by SSL Labs probably sounds more serious than it really is. At least that's what Ivan Ristic, Qualys's director of engineering and an architect of the automated analysis tool, believes.

"The SSL Labs report card alone is not enough because the update server does not run a website," he wrote in an e-mail to Ars Technica. "It may be insecure, but the report card is not conclusive. You'd need to perform an analysis of the communication and maybe attack it in order to determine if it has weaknesses."

Update.microsoft.com servers are intended to be consumed only by special Windows update software, not Web browsers such as Mozilla Firefox or Google Chrome. The crux of the failing grade seems to be that SSL Labs is unable to validate the ultimate legitimacy of the update certificate. But because SSL Labs uses Mozilla SSL libraries to test the certificates it grades, that inability may be immaterial for end users who connect using the dedicated Windows software.

Other critiques contained in the report card included the use of the deprecated SSL 2.0 protocol and the availability of weaker cipher suites. The certificate is also susceptible to an advanced attack unveiled last year that allows hackers to silently decrypt or tamper with encrypted traffic. But once again, there may be little reason for alarm since the certificate isn't being used to protect an actual website. Attackers successfully wielding BEAST—short for "browser exploit against SSL/TLS"—must have the means to influence traffic directed to a targeted site. Since Windows Update doesn't work like a normal website, it's unlikely the update service could fall victim to such an exploit, Ristic said.

"If you want to focus on the strength of the Windows update service, you might want to intercept all traffic going to this website from the Windows update tool, and observe the protocols used," Ristic said. "The tool may be smart enough to avoid using anything weak."

1) The cert doesn't chain to a root SSL labs can verify (that alone can account for the fail grade). But the update software can (otherwise there would be no point in it) via hard coded Microsoft root keys in Windows.
2) The beast attack is the already known (from 2001) adaptive plaintext injection attack against TLS CBC, to do this an attacker must use some form of cross site scripting attack WITHIN THE SAME BROWSER SESSION to inject plaintext. If the client isn't a browser and therefore doesn't run scripts from banner ads etc BEAST is totally non applicable so there is no need to mitigate it. In any case it is the CLIENT that must do this the server can simply avoid using CBC suits. Offering CBC mode ciphers in TLS1.0 is basically what marks site down in this test. Which is stupid anyway since a patched browser can use them quite safely. Also BEAST allows you to decrypt data not modify it (it doesn't defeat HMAC) and windows update is only using certificate technologies to prevent spoofing and not really for encryption, the patches are public after all...
3) SSL2.0 is not an issue for newer versions of windows as it is disabled by default, the server setting is then rather silly but benign as the client will not negotiate it.

I could go on but the take home message is crypto is not black or white, broken or not. e.g. MD5 signing is dead as a duck. But MD5 signatures that predate the MD5 collision attacks are still secure due to its pre-image resistance being essentially unbroken (of course you have to know when the attacks were first secretly determined with 100% confidence). So is signing your OWN stuff, after all you are not going to evil twin yourself :/ its only 3rd party signing that's effected. MD5 based PRFs, HMAC, Key derivations etc are also still secure (for now).