Welcome Guest. | Log In | Register | Membership Benefits

Is SSL Cert Holder ID Verification A Joke?

Some complain that certificate authorities don't do enough to verify identities for 'domain-validated' certificates

Jan 24, 2012 | 12:55 AM | 

By Ericka Chickowski, Contributing Editor
Dark Reading


With the release of the BEAST exploit and subsequent scrambling by browser vendors to close up vulnerabilities against SSL authentication, many Web authentication discussions have been focused on the SSL/TLS protocol’s weaknesses in recent months. As some IT professionals explain, though, some of the biggest problems with SSL have nothing to do with the technology. Instead, the woes are attributed to poor practices.

According to some, one finger should be pointed at certificate authorities (CAs), which they say need to do a better job confirming the identity of certificate holders in order to bolster the trust placed in SSL certificates.

“SSL has been burdened with procedural failures, not technical ones. The issue is simple in concept, and complicated in execution: Verifying a user's identity can't be done reliably by a machine,” says Bill Horne, who runs William Warren Consulting. “At some point, anyone who is trying to convince Web users that their PKI certificate is valid must venture into meatspace and show up before a neutral third party to prove that they -- or their company -- are entitled to use the name that's on their X.509 PKI certificate.”

Chet Wisniewski, senior security adviser at Sophos, echoes Horne’s sentiments, stating that he doesn’t think the SSL protocol is broken aside from the fact it relies on the antiquated model of relying on central CAs.

“The methods they use to verify your identity are a bit of a joke. You can get an SSL certificate for just about anything. For $19, which is what these certs cost, they're domain-validated, which just doesn't mean a lot,” he says. “As far as I'm concerned, having those certs there is better than nothing because it protects you against things like Firesheep. But they should be free, and the fact that they say they validate who [the certificate holders] say they are -- it’s just horse manure.”

According to Horne, he believes many CAs have chosen to pretend that it’s possible to automate the critical step of verifying a certificate holder’s identity.

“It isn't, but it's a lot more profitable to pretend that it is,” he says. “That's the economic problem in a nutshell: Paying humans to verify certificate-holder identities is expensive, but there's no other way to reliably verify an identity.”

And, in fact, CAs realized the time and resources it takes to more painstakingly verify certificate holder identities: That’s where the whole idea of extended validation SSL certificates came from. When they were rolled out several years ago, the thought was to charge more for a more extensive check-up on the certificate holder and offer a color-coded "green bar" in the browser address bar to indicate the site is protected with an EV SSL certificate.

“Granted, when you do the extended validation, you get that fantastic green badge in your browser, and in that case they do want some documentation proving that in some way you're affiliated with this business and you've got some papers to show it. And it's a little more rigorous process -- which is the way it used to be just to get a domain,” Wisniewski says. “But even that isn’t foolproof.”

For example, the cost of these EV-SSL certificates may still be seen as prohibitive and can lead to issues of "mixed content," where some pages of a site may be protected with EV-SSL certificates, some with plain-vanilla certificates and some not encrypted at all. This is an all-too-common problem that frequently leads to vulnerabilities within sites and shows that both the CAs and site owners bear responsibility in the complicated SSL ecosystem.

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