MS soft-pedals SSL hole

Hardly a problem, the way they tell it

A Microsoft security PR bulletin dealing with the recent SSL (Secure Sockets Layer) certificate hole reported by Mike Benham goes out of its way to assure Windows users that there's little to be concerned about. The recent negative talk about it hasn't been properly 'balanced' (i.e., approved by the Marketing Department), apparently.

"We regret any anxiety that customers may have experienced regarding this issue. Clearly, it would have been best if a balanced assessment of the issue and its risk had been available from the start," the company's PR bunnies want you to know.

Attacking the flaw, MS says, would be well-nigh impossible for three reasons.

First, there's no easy way for an attacker to lure a victim to a malicious knock-off Web site, which MS flacks insist is a precondition for exploitation. Actually, what they say is, the attack scenario "provides no way to make the user actually arrive at the attacker's site."

Well, that's true in a sense. Luring the victim is a problem which needs to be solved or sidestepped for an attack to work. But is it strictly necessary? The short answer is no. Benham's attack tool, sslsniff, uses ARP (Address Resolution Protocol) spoofing rather than social engineering, and just grabs data from other people's SSL sessions using ARPspoof to get between client and host as a proxy, and his certificate chaining attack to defeat Windows' certificate verification mechanism. Thus an attacker can easily place himself between you and your bank and log your business using a bogus SSL certificate which IE will not warn you of.

We publish this because there's a simple, free workaround. Just install Mozilla for Windows if you need to rely on SSL while MS comes up with a fix.

Second, MS claims that the attacker's identity would be 'easy to determine' because there are fairly strict ID requirements for people to obtain digital certs, and Benham's approach requires the attacker to use one in signing an intermediate cert.

Reader Andrew Gray of Icons, Inc. doesn't buy that for a minute, and sent us an email disputing the claim.

"Most likely, the identity of the fool that had his Web server rooted and keys stolen could easily be established," he writes. "Many SSL Web site operators remove the 'key-protecting key' that protects the Web server's private key so that the SSL component of httpd will start at reboot without manual intervention. Will the first person to post a valid signed certificate and its associated unprotected private key to USENET bring down the E-Commerce infrastructure of the world? Does IE even check to see if the certificate has been revoked?"

"Unfortunately, what this issue means is that we need to not only trust VeriSign and all the other root CAs [Certificate Authorities] in their ability to protect their keys (as we have historically done), we now have to trust every Web server and its associated people, policies, and procedures for maintaining the integrity and confidentiality of their keys."

Well of course we always did have to; it's just since Benham showed us how easy it is to forge an SSL cert with any valid key that we've appreciated it fully.

Finally, Redmond's PR bunnies tell us that "the user would always have the ability to determine the truth," if he were confronted by a dodgy SSL cert from somewhere outside the site he's trusting. He would not be warned, mind you; but he'd have every opportunity to look into it on his own.

"Anytime an SSL session has been established, an icon shaped like a lock is present in the lower right corner of the screen. By double-clicking on the icon, the user can see information about the site's digital certificate, including the identity of the issuer. This would clearly show that, in contrast to the norm, this one hadn't been directly issued by a commercial Certificate Authority," MS cheerfully notes.

Gray has a colorful comeback: "You can tell the average user that they need to start validating certificate chains manually. End users have trouble keeping food off their keyboard and sorting messages in Outlook. Try explaining this problem to them."

We sense a period of bitter helpdesk experience somewhere in that CV. But the point is fair. The fact that a certificate is signed by an intermediary may not ring alarms for many users, assuming they ever bother to check what their little padlock icon has to say. They've been told in a million ways that incomprehensible and virtually infallible technology is always invisibly at work on their behalf. A naive user may well assume that if there were anything wrong with a certificate being signed by an outside entity, surely a company that promises nothing but Great Experiences from Great Software would have taken steps to prevent it from happening. ®

Sponsored: Designing and building an open ITOA architecture