Digital Certificates: Do They Work?

That Certificate Revocation Check can cause lots of problems. The problems that it caused me were totally masked by the fact that nothing that was happening triggered any notion to look at code signing as the root cause of my problem. I just blogged about it here.

http://www.brianhaas.com/2007/12/21/WhenDoingTheRightThingBites.aspx

A website that has a verification certificate might be hacked. The hack could occur before or after the site obtains the certificate. Your Credit card number could go straight to the hacker, despite the cert. A well-meaning website with a certificate is not promising they are unhacked, and may be clueless.

@ Kevin Nisbet

The original point of this article is well-founded: that your browser can validate the site’s certificate by the CA’s public certificate only means that the site certificate was signed by the CA. It does not mean that the site is really who they say they are, as that is a function of how much effort the Certificate Authority puts into its investigation. Given the nature of being a commercial CA, profit will be equal to revenues - costs, with the goal of maximizing profit. Investigations will suffer if necessary to keep profit up. Whether that’s good or bad doesn’t matter – it is what it is. At DoD we used both server and client certificates to perform identity verification of both parties, and since we were our own CA the trust level was pretty high, and we had the ability to preload the CA certs on all client systems.

Though I can’t speak for others here, I personally don’t think PKI sucks, but SSL/TLS does. I don’t think I should have to pay someone for a certificate just to encrypt my site’s traffic if I don’t care about identity. I could use a self-signed CA, but then the end user gets that damn popup saying the site certificate didn’t pass muster because their browser doesn’t have my CA cert loaded. None of the users I’ve ever worked with understood what that popup meant and all of them just pressed “accept” when they got it, which essentially thwarts the purpose of the certificate: to verify the identity of the site.

Thank you! SSL is meaningless for identification! Most SSL certificates are “domain control verification” as if criminals, phishing sites can’t control a domain.

The continued promotion of SSL by the security community and browsing vendors as a way for ordinary consumers to distinguish legitimate sites from criminal sites is itself criminal.

Consumer should evaluate the entire website for clues to legitimacy, including the URL, the professionalism of the design, if they found the site by email or in google, if the prices are plausible, if there are spelling errors and many, many other factors that even PKI morons could understand.

God damn, a lot of these comments are just saying the same thing over and over again.

@IIVQ:
Good system, but it would fail in this case if the user didn’t notice the incorrect (but correctly spelled, legitimate looking) URL:
http://blog.washingtonpost.com/securityfix/2006/02/the_new_face_of_phishing_1.html

And as Sumo pointed out, Verisign issued two Microsoft certs to fraudsters. So that’s two large CAs who have made very public mistakes. Since CAs have every incentive to bury these types of stories, god knows what massive screwups we haven’t heard about.

Dugg:
http://digg.com/security/Digital_Certificates_Do_They_Work

Why don’t you go back to writing useful code samples for all sort of things in this blog.

This blog isn’t worth reading anymore and I’m removing the shortcuts I’ve had for years from my favorites now, it was a long time since you wrote anything remotely interesting.

Digital certificates are such a rip-off. How much does it cost to check an ID and multiply 2 prime numbers together? But the companies with root certicates recognised by Windows have us over a barrel. One of the cheapest vendors, Comodo, recently did a huge price hike.

Scott-- did you read the entire post?


And even if we enhance that with (more expensive, naturally) “extended validation”, I fail to see how this would prevent a determined, resourceful criminal from getting whatever certificate they need.

SSL and the “lock icon” indicate a secured communication channel, but nothing else

That’s an interesting belief, because the UI for both IE7 and Firefox 2 certainly tells me otherwise, and quite explicitly, too. I saw no change in the PayPal cert UI with FireFox 3 Beta 2, but maybe they haven’t gotten those changes in yet.

I will agree that the #1 problem, as pointed out by @powerlord and many others in the comments, is that identity and encryption are so intertwined here. They really shouldn’t be.

With all due respect Jeff, I think the basic idea behind this post is flawed. SSL and the “lock icon” indicate a secured communication channel, but nothing else. You can trust the wire protocol but there is no guarantee that you trust the identity of the remote endpoint.

Additionally, you confuse the address bar color change. The bar turns green in IE7 and PayPal because they use a High Assurance SSL Certificate that DOES imply an identity trust relationship, assuming you trust the issuing authority. High Assurance certificates are much hard to get than the $5 GoDaddy certs because your data center and company will be audited, and your company’s identity confirmed.

Firefox2 doesn’t support this without an AddIn from Verisign, but FireFox3 does. Either way, the difference is VERY significant.

Digital Certificates guarantee that you will scammed by “Big” scammers how are willing to spend $300-$2,500!

Powerload writes: “Recently, on a non-commercial site I run […] I set up a SSL service on the site’s webserver. Which throws nasty messages in web browsers because my self-signed certificate isn’t signed by a known certificate authority.”

This is as it should be. If you look at the two advantages of SSL that Jeff gives at the top of his post (authenticity, secrecy) you’ll see that neither apply when you are using a self-signed certificate. The reason the second point fails is that self-signed certificates allow for trivial man-in-the-middle attacks (similar to attacks to unencrypted TCP or HTTP protocols).

So a self-signed certificate barely provides any security at all (although there is some resistance against packet sniffing). It’s a good thing that the security implications of the lock icon (which are already limited) are not eroded even further to allow this.

I don’t like the certificate selling business either (which seems to benefit mostly large companies which already have root certificates shipping with major operating systems) but eliminating the trusted third party from the equation entirely is even worse than what we have now.

Several people in this thread have committed the politician’s fallacy:

  1. Something must be done.
  2. This is something.
  3. This must be done.

Read the article linked above (the “exhaustive coverage” one), which cites numerous real-world user studies on the effectiveness of SSL certs. The phrase “indistinguishable from placebo” occurs numerous times.

Something certainly must be done, but it’s not SSL certs. They’re the reason why we’re in the mess we’re in now: all the effort is going into something that doesn’t work, and little to no effort is going into exploring alternative solutions.

Nice analysis! For people wanting even more, there’s exhaustive (and possibly exhausting) coverage in http://www.cs.auckland.ac.nz/~pgut001/pubs/usability.pdf. Reading through that it’s not surprising that phishing is the problem it currently is.

The concept of certificates broke the minute big business got involved with them. Take an example I just recently had to deal with:

  • I use Thawte certificates on domains which require SSL
  • Verisign owns Thawte (same level of trust, surely?)
  • Some mobile phone carriers explicitly remove root certificates of commonly “trusted” CAs from their phones (eg. ATT Thawte), despite the phone manufacturers shipping the phone with that cert.
  • J2ME will not allow SSL connections to self-signed or CA-signed certs. which aren’t on the trusted list of root certificates

Where does that leave me? I’m forced to purchase an expensive Verisign certificate to handle certificate exceptions thrown by phones which don’t accept a different certificate from the same company!

In the netherlands the banks joined forces and launched the campaign
3xkloppen.nl (litterally: 3 knocks, but also “check 3 things”).

That site is only accessible via Flash. You know, that thing that just had a bucketload of vulnerabilities posted.

Haven’t read all the comments, but I know from past experience, some Certificate Authorities make it harder to get an SSL cert than others. With VeriSign, I think you have to have a DB number. Thawte required articles of incorporation or other legal documents to prove your identity as a business. But the driver’s license thing is really scary. Maybe Clark Howard ought to do some research on who’s certifying the certifiers and bring it up on his radio show.

So if I try to connect to www.amazon.com, and some malware
redirects me to a fake Amazon-lookalike, the browser will
notify me.

Of course since the phisher is sending victims to www.amazon-verify.com, which has its own nice SSL certificate, the victim never even notices this.

some malware redirects

Oh, and if you’ve got malware on your machine doing this, you’re hosed anyway. Any malware worth its salt bypasses SSL entirely, whether you’re on the real Amazon.com or not.

This provides something useful to the end-user, some
protection against one possible attack.

It protects you against phishers and malware too stupid to bypass it. It’s net value is close to zero in terms of actually preventing fraud, since all it does is tell fraudsters “If you want to be successful, step around this minor barrier”. They all do, and the result is the curent multibillion-dollar phishing industry.

(This is always the ultimate argument against “But SSL certificates work, really, they do! Mom, tell them they work!”: If they worked, we wouldn’t have a multibillion dollar phishing indistry).

There’s an important point that I’m not sure has been made clearly enough. What the ordinary end-user gets from the certificate in an SSL connection is that the browser checks to make sure that the host name in the URL matches the host name embedded in the “distinguished name” in the certificate. So if I try to connect to www.amazon.com, and some malware redirects me to a fake Amazon-lookalike, the browser will notify me. This provides something useful to the end-user, some protection against one possible attack. The user doesn’t have to understand certificates or PKI at all.

A certificate represents trust between YOUR BROWSER and the RECIPIENT.

However it is worthless if you cannot trust that YOUR BROWSER will act correctly on your behalf to communicate information to the recipient.

In other words, if your browser becomes comprised the whole system fails. I would like to see technologies verifying the integrity of the browser. How to accomplish, I don’t know but I would like to know.