Welcome Guest. | Log In | Register | Membership Benefits

One-Fourth Of SSL Websites At Risk

Many sites haven't applied patches for well-known 'renegotiation' flaw

Apr 21, 2011 | 04:37 PM | 

By Kelly Jackson Higgins
Dark Reading
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.



Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dark Reading encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dark Reading moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. Dark Reading further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
Subscribe to RSS



Authentication Reports

report What's Next for Certificate Technology
A recent rash of certificate authority breaches has left a bad taste in many people's mouths. There is no one reason for the breaches. The compromises were the result of a breakdown in people, processes and technology, but not necessarily the certificates themselves. We take a look at what?s wrong with certificate technology, what can be done to fix it, and what's down the road for certificates and CAs.

report Will Smartcards Live Up to Their Name?
Recent compromises of smartcard data have exacerbated concerns about the technology?s privacy, security and standards (or lack thereof). Yet the promise of smartcards is too compelling to ignore. New technologies and applications prompt us to take a fresh look.

report Get The Best Of Biometrics
As data volume and sensitivity grow, companies cannot rely on password- and token-based authentication. Biometrics can be used to provide strong access control, but you must weigh added complexity and costs against assurance that users are who they say they are.

Other reports from the Authentication Tech Center:




Featured Webcasts
Featured Whitepapers
Featured Reports