More than a year after the Internet Engineering Task Force (IETF) issued a security extension to the Secure Sockets Layer (SSL) protocol for a flaw that affects servers, browsers, smart cards, and VPN products, as well as many lower-profile devices such as Webcams, more than one-fourth of SSL websites haven't deployed the patch--leaving them vulnerable to a form of man-in-the-middle attack.

Of the 1.2 million SSL-enabled website servers recently surveyed by Ivan Ristic, director of engineering at Qualys, more than 25 percent were not running so-called secure renegotiation. Ristic also found that among 300,000 of the top one million Alexa websites, 35 percent were vulnerable to this type of attack, which basically takes advantage of a gap in the SSL authentication process and lets an attacker wage a MITM attack and inject his own text into the encrypted SSL session. The gap occurs in the renegotiation process, when some applications require that the encryption process be refreshed.

The IETF teamed up with the Industry Consortium for the Advancement of Security on the Internet, and several vendors, including Google, Microsoft, and PhoneFactor, and came up with a fix for SSL, known as Transport Layer Security (TLS) in the IETF standard. The fix -- Transport Layer Security (TLS) Renegotiation Indication Extension -- was issued in January of 2010 by the IETF.

"It's a paradoxical that the security of the top sites is worse than the average," Ristic says of the findings, which he presented for the first time today at InfoSec Europe in London.

Ristic says these vulnerable sites basically didn't patch for the flaw. "Secure renegotiation is automatically available after patching," he says. "The vulnerable systems could have also implemented a workaround--typically by disabling client-initiated renegotiation--but they didn't do that, either."

PhoneFactor's Marsh Ray, who discovered the flaw, says the data unfortunately shows a typical security pattern when it comes to deploying fixes. "A certain number of sites fix it right away, and then [adoption] trails off after that," Ray says.

"We did everything we could. We got the vendors in a position where they could offer patches. You can lead a horse to water," but you can't make him drink it, Ray says.

SSL security has been in the spotlight for some time, first with the MITM hack by researcher Moxie Marlinspike that dupes a user into thinking he's in an HTTPS session when he has actually been redirected by the attacker elsewhere. Then came researcher Dan Kaminsky's research, which exposed critical bugs in the X.509 digital certificate technology used in SSL.

"I think there's no chance of getting individual users to substantially improve SSL deployment. There's too many and virtually no one cares. My take is that we should focus on library developers [such as] OpenSSL to get them to remove obsolete features and software vendors to ship with properly secure defaults," Ristic says.

He says longer term, other efforts will help secure SSL deployment. "Long term, the approach used by Google will, I am sure, turn out very well. They are using performance improvements to sneak in security improvements. For example, their SPDY protocol is 100 percent encrypted by default. So all those people moving to SPDY for performance will also get extra security," Ristic notes. "Overall, our combined efforts, SPDY, DNSSEC, HSTS, and similar smaller protocol improvements will in time provide results."

Ristic and his SSL Labs team surveyed some 1.2 million servers with valid SSL certificates.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.