Good point indeed. Once again, another great post.

The whole certificate thing has bothered me for some time as well.

Recently, on a non-commercial site I run, I had a giveaway where people needed to enter some personal information. So, 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...

Shit, all I want to do is encrypt traffic and make it easy for end users to use.

Ooh! Goody. I better hurry up and go register my own "Official CodingHorror Jeff Atwood Edition Donation Page(TM)" and start taking donations for you :) Of course, I'll give you an amazing, outrageous, and above average 2% of all the proceeds!

OT but - congratulations :)
http://www.codesqueeze.com/developer-faceoff-scott-hanselman-vs-phil-haack/

A certificate doesn't make a web site trustworthy. All it does is ensure that someone (a web site) is who (what) it claims to be.

As you have mentionned, verification takes place when issueing a certificate. The value / stength of this verification depends on the issuer / certificate class.

Anybody can get a certificate, sure. But you can bet Verisign isn't going to certify that random joe is Microsoft Corp. Why? Because if they did, Verisign would lose all credibility and all their certificates would be worth nothing. This means no $ for them anymore. So it is in Verisign's best interest to make sure that when they say this is a Microsoft web site, it in fact is. This is where the word "trust" is applicable.

The problem you are raising though, is that what I just describe isn't known to people in general. And even then, who actually check the certificate class and understand what it means. Blindly trusting a site because there is a "lock icon" is certainly wrong.

Kzinti:

I guess you never read the Microsoft bulletin issued a while back about Verisign giving out class 3 certs for signing software that could be spoofed as Microsoft Corp.

http://www.microsoft.com/technet/security/Bulletin/MS01-017.mspx

SSL is broke and there are literally hundreds of trusted roots that you need to do barely anything about to get a cert. They are a very easy target.

The real problem is that everyone tries to make security 'transparent', as in, 'the user shouldn't have to worry about it'.

The marketing/sales pukes have us convinced that pop-ups asking a user if they trust XYZ corp or not is 'bad'.

People choose with whom they do business every day. They trust their bank because they've been around a long time, they have a low chance of losing your money, you TRUST them. You recognize them by their logo, by their location, by their employees, etc.

We need to start treating business web sites (banks, e-commerce, etc) as real institutions that require the same level of identification and recognition as every other institution. It's not just enough that Internet Explorer says "PayPal, Inc." How do I know that some loser didn't fudge that somehow? I need more context and more assurance that this, in fact, the PayPal, Inc. (subsidiary of eBay) that I know and trust (well, at least that I know).

And I don't think pre-installing 'trust' certificates on people's computer really is a good idea. When they hit Amazon.com, they need to be asked if they really trust this guy and what all that trust entails.

Like anything else with security, unless you use pays attention, there is no security. I am reminded of the 10 unbreakable laws of security...You can google that to find them.

However, certificates aren't something designed to be reviewed each time. If you wish you cna audit the list of certificates you are aware of and the ladders and webs of trust you have develeped, but the system is really designed to happen behind the scenes pretty much just lightly alerting the user to the fact that authentication is taking place behind the scenes. The value of certifications and CAs, and the whole PKI infrastructure become apparrent on the day you access a website and are presented the warning that this webiste is not the genuine article.

I don't think certificates are that broken. Sure they contain cryptic text and are missing contact information for the certificate issuer. However, they still work to tell you that a site is who/what is purports to be. Of course you'll still be foolish to give your credit card to a site created by John Doe from some overseas country just because his site has a certificate from Verisign. A certificate tells your that a website is really owned by your bank. It's up to you to decide whether to trust your bank with your SSN.

Yeah, exactly. Who decided these CA's were trust worthy? There's basically the same root cert list in FF 2 that there was in Netscape 2 10 years ago. I remember b/c I had to buy a cert way back then. Those lucky few who got in the list (who decided that?) can now charge us yearly for cert signing that costs them nothing and is totally automated (GoDaddy's $19.95 cert is instant, requires no faxing / emailing them anything).

The only things certs are good for is encrypting traffic. Yes, locks give people warm fuzzies, but the reality is that if someone can poison the DNS system and redirect to their own server, it is even easier to obtain a certificate from the inexpensive providers that is "good enough".

Verisign remains high on the trust list, however, because they actually *do* verification of the information. I know, because every few years something breaks the automatic renewal process of our certs. (Our office changed address on year, the technical contact changed on another).

It's certainly true that web browser developers/packagers are making security decisions on behalf of customers. That said, though, this is at least as secure as most other things in the real world. Sure, the whole system relies on the idea that Verisign won't suddenly decide to cooperate in a scam. Then again, people generally have no choice but to make the assumption that significant companies won't violate public trust in any number of ways. If they do, one hopes (though not always reasonably) that they will lose their credibility and be economically forced out of the picture.

So that lock thing means two things: first (and most significantly) that the web traffic is encrypted; and there's no problem there. Second, that the web site is who it claims to be; but that simply won't work unless users specifically check on it. And personal names -- the kind you can back up with a driver's license -- can't be trusted in that way anyway. I'm sure there are plenty of people named Bill Gates in the world, and some of them don't represent Microsoft. So I don't see a lot of opportunity for improvement in this way.

I agree with an earlier post that the attempt at transparency is risky, but I also question whether a less transparent approach would ever be accepted. In the end, there is a limited extent to which people are willing to be inconvenienced to protect themselves against highly unlikely security threats.

On Phil Zimmerman's ZFone project website ( http://zfoneproject.com/prod_zfone.html ) he has two great links worth reading regarding the PKI infrastructure worth reading:

Ten Risks of PKI: http://www.schneier.com/paper-pki.html
Improvements on conventional PKI Wisdom: http://www.cs.dartmouth.edu/~pki02/Ellison/

His ZRTP solution for VoIP doesn't apply to web applications, but his use of glyphs is helpful and I've seen a number of bank sites starting to use them. It's going to be interesting to see what emerges as the new model for web security (especially in regards to authentication).

I agree with the point that people often put too much faith in what a digital certificate can provide. It definitely does not guarantee that the recipient of the digital certificate is a reputable business person.

I do think it does do a fairly good job at what it promises, which is to prevent eavesdropping and spoofing. I fault Verisign if someone intercepts my conversation or else the owner of the certificate is not really who they say they are, but I assume that it is my fault if I choose to trust a crook. In the best case, I would hope that I have a better chance of tracking down that crook afterwards if Verisign has done their job properly. It is more about providing traceability and accountability than it is about guaranteeing trust in the first place.

All I assume from the lock is an encrypted connection, which is my main concern. I don't need anybody sniffing at my private packets. But as for the guy at the other end, I use my own judgment and common sense about who gets my data. Very few qualify.

But few if any casual users will ever understand the risks and implications of a cert...

I strongly believe that certificates have their place in the security communication over the internet. In order to establish an SSL connection to a server, you firstly need to accept the server's (Amazon) public key and use it to decrypt the communication that comes on the pipe. The communication can come from anyone not only Amazon. In order to bring some structure to this possibly chaotic problem, there are these CAs that compute a hash of the public key, encrypt the hash with the CA's private key and append it to the actual public key. In effect by adding the CA's private key encrypted server public key plus some information about the server you have a certificate. Now the issue boils down to if you trust the CA to have verified the credentials of the server that asked for a certificate for its public key. From my knowledge, VeriSign has three levels of certification: level 1 requires a valid email address and is the less trustworthy, level 2 requires a valid mailing address and a valid email address, and level 3 which is the most expensive and more trustworthy than the first two, requires the requester to show up in person and prove who he/she is and get their certificate.

As I said in the beginning of this post, if you want to establish an encrypted connection with a server, you need to trust that the public key that is offered to decrypt the server traffic comes from the actual server. A better way than trusting VeriSign is to go and get the public key in person from the server. Also, to finish my idea, the entire communication encryption is as good as the usage of the data that reaches the server. Upon arriving at the server, the data stream is decrypted and used in a certain fashion. How are you going to trust that server that it will not missuse your data? Hard to do.

Heck, you don't even need a cert from an iffy CA to make a user feel warm and fuzzy. Use a pretty little lock as your favicon.ico file and most browsers will be happy to put it next to your domain name. I doubt that most users would notice the lack of color behind the address. If they noticed anything, it would be the comforting (but misleading) lock beside the domain name.

You'll always have the problem of authenticating through a third party. The real scam is that if you want to encrypt traffic to and from your site and not annoy users with the popup that says your site's certificate can't be validated, you must buy a cert from one of the major CAs that have their CA public certificates bundled with the browser distribution.

In my mind this was Netscape's screw up when they created the first SSL implementation. Encryption of the channel and authentication of the end point are two distinct things, but Netscape stupidly tied them together.

Real life isn't all that different. Put on a suit and print out the first google hit for "FBI Badge" and see who's going to dare question your "badge".

Authenticity != Trustworthiness

I have to mention my favorite part about digital signatures is spyware/malware that's digitally signed. You can't top that! Digital signature is as meaningful as a candy wrapper. If you find a toffee on the street, but it's still wrapped, do you eat it? I'm not trusting that candy wrapper.

As for SSL, the only thing that SSL really ensures is that the data going between your computer and the remote server can not be spied upon by 3rd party prying eyes. What happens to the communication once it gets to the server is a whole other issue. I'm not going to be trusting sleazy web site with important personal data, no matter who signed their certificate. I'm would not run "love.exe" that comes in my email even if it is digitally signed.

The disgusting thing is that they are making money from this scam. Certificate Authority should really be a non-profit organization. For companies like Verisign, the fact that they're in this for massive profit with their exorbitant prices really undermines their position of authority. In the end they're doing it for their own profit, not my security.

That's my two cents.

As already pointed out, certificates are to verify the site or executable's identity (i.e. you are not being spoofed) and to encrypt traffic. They do not guarantee the reputation of the organization that is offering the site or executable. Certificates do not replace the BBB or your own common sense.

Here's an analogy. Let's say you're in Manhattan at one of those famous discount electronics boutiques. Asking for "Crazy Sam"'s driver license will help you to verify that he is indeed "Crazy Sam" owner of "Crazy Sam's Too Good to Be True Electronics", but it won't guarantee that the "Panasoanic" TV your buying is the Panasonic he's fooled you into believing it is. Should we also be decrying the use of driver's licenses to verify people's identity, just because a crook can also have a legitimate license?

Scott G,

I agree with you 110%. It is stupid that SSL requires certificates. PKI does not require certificates, just an exchange of public keys. Having encryption entangled with identity verification has been a major PITA for anyone wanting to just encrypt traffic.

I'm not quite sure what you are implying with this post. Certificates protect you from accepting something bad from someone who you trust, via the old swithcheroo.

What else do you expect?

It's obviously not feasible for anyone to validate the intentions of every piece of software you choose to install or every single website you visit.

But it gives me a warm feeling to know that when I visit gmail it is in fact gmail or when i install software from microsoft that it is in fact from microsoft. And certificates fill this function perfectly.

Essentially all certicates are really good for is knowing that the channel is encrypted, using it to verify identity as well seems suspect.

What's to stop someone from getting a certificate for "Apple, Inc."? Does the registrar actually do due diligence to verify the business exists under that name and is not in violation of trademark laws? I think not.

All the certificate is saying, is that at the time of issuance, the entity named in the certificate could prove more or less that they had ownership rights for the domain (CN) the certificate was issued for. Nothing more, nothing less. Unless there are new certificate types that are harder to get.

On the subject of trusted SSL certificates, you might be interested in CACert, which uses a community based approach to issuing certificates. Did I mention they are free?

http://www.cacert.org/

Right now they are working towards inclusion in Firefox. However, I doubt Internet Explorer will ever accept them. To Microsoft, certificates are all about money.

In the netherlands the banks joined forces and launched the campaign 3xkloppen.nl (litterally: 3 knocks, but also "check 3 things").
The 3 things to check are: computer security, website, payment.

In the website check, there are 3 items, some with 2 subitems:
1. address (does it start with https and is the name spelt right)
2. login (does the loginprocedure is as you are used to)
3. certificate (is there a padlock visible, is your bank's name in the certificate)

So only a minor part of the security campaign revolves around the certificate. But the danger is in connecting the certificates with trust.

As you said, a certificate certifies that a website is who it claims to be, and that the certificate itself is not fake. However, a phisher could easily set up www.mybank.com (instead of .nl), assign it a tucows certificate and use a looptrough authentication to do a man-in-the-middle-attack and change the account number. The layman who is confronted with a slightly off login procedure will check, miss the off TLD, see the padlock and colored address bar and think "this is ok", and continue. Boom, account compromised.

But then, what should we tell the layman? "trust only sites with a certificate", thus learning the phishers they should use certificates (an easy task to do)? or learn them to trust nothing, in which case they either go paranoid or (more probable) waltz into any phishing trap?

Who can think of a way to certify (using certificates or other ways)that sites are "trusted" in a way the layman can understand?

@alan:
Do you read previous comments before you post? You might be interested in the one by Sumo with the link to a MS security bulletin.

Regards
Peter

Two other things which involve digital certificates: Signed Java applets, and drivers.

On that last note, in 64-bit versions of Vista, Microsoft has ONLY allowed the use of drivers signed by a 'trusted' authority... As far as I'm concerned, such exclusion and isolation is even worse than certificates' use in other regards, as flawed as it might be there as well. I wouldn't mind it as much if they weren't so insistent upon it... http://tiniuri.com/f/0mc

"In my mind this was Netscape's screw up when they created the first SSL implementation. Encryption of the channel and authentication of the end point are two distinct things, but Netscape stupidly tied them together."

No, the two are linked together. http://en.wikipedia.org/wiki/Man-in-the-middle_attack

Also, the guy who said SSL is broken. No, SSL is just fine. It is the key management that has grown up around the web that has issues.

From my point of view, the fundamental problem with digital certificates is its presentation in common software.

Everybody in the comments went away to the discussion of the identity proof of the end entities, but absolutely forgot to clarify the understanding of what does a digital certificate signed by some CA really mean.

A CA signature on the digital certificate does not mean that "VeriSign verified this site". What it actually means, is that the CA did verify the site (or any other end entity) under the specified Certificate Policy and Certificate Practice Statement (CP/CPS). The CP/CPS is a standard document which any respective CA has, and there is even an RFC 3647 which describes what should be in that document.

The CP/CPS has an exact description of the measures taken to "verify the site". Moreover, it contains the description of Audit Procedures for the CA, usually performed by some respective third party. And if you have no particular reason to trust the CA just because it is in the browser or wherever, you can try to contact the audit authority for the CA to decide if you should trust the certificates signed by the CA.

@ Jay Kominek

SSL was designed to use the certificate for two purposes: to set up the encryption channel and to verify identity. I'm saying it didn't have to be that way and it was a stupid decision. SSL could have been designed to set up an encryption channel separately from using a certificate to validate identity. SSH does it all the time.

I'm fairly certain one of SSL's original designers, Berners-Lee I think, said if he could do it over again he would have separated out these two functions. A commenter on slashdot who sounds as if he was at Netscape and may have been involved in the design had this to say:

"We made a mistake back in the day. Certificates are serving two purposes: One is to encrypt the data, one is to verify identity.

This makes it a major pain when you just want to encrypt data without claiming to be anyone in particular, since you have to jump through a lot of hoops both on server and client side to get it working. The browser gets bitchy about a certificate that isn't signed by any of its roots, even though it may very well be the case that nobody cares.

If we clearly thought about these two aspects, and separated them, it would become clear that A: we need a better way to just say "secure the damn connection" without claiming to be anybody and B: When a site is claiming to be somebody, it hardly makes sense to not show the claim clearly to the user. But since the concepts are all mushed up, you get a lock icon that sort of covers half the situation, mostly, and few people really realize there's a problem."

http://slashdot.org/comments.pl?sid=181234&threshold=1&commentsort=0&mode=thread&pid=14992669#14992689

Digital certificates mean as close to nothing as, well, nothing. As you say, a 'trusted authority' as a commercial body? If anything, a trusted body would have to be a not-for-profit organisation with selected security industry representatives being elected to some form of 'Council for Trust Certificates' every couple of years. But that's never going to happen.

Just wait until someone with some ulterior motive decides they fancy buying out VeriSign... say goodbye to what little trust we can actually have in them.

In a round-a-bout way, "digital certificate" is a bit of an oxymoron.

The original idea was something like the D&B, etc. outfits. Look at their history.

It was all about old boy networks and exclusive business relationships of "trust" - along with a few bucks here and there for "membership fees."

http://www.pbs.org/wgbh/theymadeamerica/whomade/tappan_hi.html

Shouldn't HTTPS be worked like this?

If the server has no CA-signed certificates, it automatically generate one and use it to encrypt, and that should be fine because sign-signed cert. proofs noone. The browsers should only warn if the cert. is a revoked one.

The lock (or whatever) icon on the browser should NOT be displayed if the connection is using self-signed certificate. After all you're not going to say this HTTPS connection is NOT ENCRYPTED, right?

If someone ask about URL rewrite, I think we have the popup when we're redirected across the boundary (both "HTTP to HTTPS" and "HTTPS to HTTP" do generate popup on all major browsers I'm using)

I am incredibly surprised by this post from what I usually find to be a very high quality website. I am even more surprised at the amount of people going Yah! the whole PKI things sucks. I know a lot of cryptography concepts are hard for most people, but seriously, have any of you even tried to attack the infrastructure.

I know it sounds really easy, but is actually quite complicated to do. Now that's not to say it's impossible, because there have been issues in the past, but honestly, the number of occurrences is slim compared to other sorts of identity based crime. I definitely feel safer doing my banking online then I ever would receiving my bank statement in the mail.

But let's really take a look at the problem, you are saying that why do you trust the CA when it may issue a certificate that it shouldn't. But hell, why don't you take it one step further, why do you trust the browser that puts its trust by default into the CA's that may not perform proper checks? You may say it's the CA's fault for issuing the certificate, but why do we trust Firefox and internet explorer so much too even accept that CA?

Besides this, the largest issue that exists is signing a signature for a derivative of a domain. google.com vs. gooogle.com (notice the extra o? a lot of people might not). A DNS interception with redirection or even cyber-squatting the typo, and a properly signed certificate, and the browser will not even alert you. This is enough to fool most people, but what absolutely cannot take place *assuming* the CA hasn't given a certificate to the wrong person, is if you go to google.com, it will only be secured by the real google.com.

For those of you who think authentication shouldn't be part of SSL, it absolutely has to be done somewhere, or else you just broke the entire damn thing, do your research people, since your going to need to do some sort of cryptographic challenge for authenticity.

But do you know what really scares me most? What if these Botnet runners and spammers stopped sending spam, and put these massive computational grids against breaking one of the larger CA's encryption keys? It may take awhile, but if accomplished this entire secured infrastructure could be taken down. I work for an ISP in Canada, and could easily modify our customer facing DNS servers to redirect all our major banks web traffic. Combined with Verisign’s private key and even the best professionals will be tricked.

Time to edit my hosts file to statically point to the websites I wish to visit.

One side-effect of the certificate issue is that it creates a significant entry barrier for small startups and shareware authors: you need to certify your software for users to run it, but you need thousands of dollars per annum to pay for the certificates.

Johnathan Nightingale addresses a lot of the UI related issues in his Mozilla24 presentation "Beyond the Padlock".

Slides available here:
http://blog.johnath.com/index.php/2007/07/25/beyond-the-padlock-oscon-talk-slides/

Video available here:
http://www.mozilla24.com/meta/1-16_johnathan.asx

Yes, video is a terrible format to convey this kind of information, but it's worth suffering through. They're looking at how to provide valuable, actionable information on a site's security and trustworthiness. And, yes, they use blacklists to fight phishing. Because blacklists rule.

The other strange thing about certificate authorities is dealing with the inevitable certificate revocations..

http://en.wikipedia.org/wiki/Certificate_revocation_list

So on top of the other problems I've enumerated, devices need totally current 100% accurate lists of every single certificate that has been revoked. This is also known as the "HD-DVD" and "Blu-Ray" problem..

As I understand it, one use for application signing is that you can use it to prove that two applications came from the same place. I think Leopard asks for (or requires) signed applications for this reason: when you download an update, it doesn't have to ask you if you want to allow the new app access to your keychain (Mac list of passwords and things); it checks the signatures and if they match, it does so automatically.

I'm not an expert on this so I might be wrong. But it seems to me like this is a use for certificates that doesn't suffer from the verify-the-CA problem: the certificate doesn't prove that you should trust the application. But _if_ you trusted it before, the certificate does prove that you should trust the new version.

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

@ 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

Here's a list of my "Root X509 Anchor Certificates:

ARGE DATEN - Austrian Society for Data Protection, Vienna Austria
AAA Certificate Services - Salford, Great Britain
AddTrust AB, Sweden
America On Line
AOL Time Warner
Apple
Application CA G2 - LPKGI (Japan)
Arge Daten Oesterreichische Gesellschaft fuer Datenschutz, Vienna Austria
Baltimore CyberTrust Root (Ireland)
beTRUSTed (Country Code is "WW", but now says it's part of Verizon)
CertiNomis - France
CertRSA01 - Korea
Chamber of Commerce Root - Root is EU, but company is Spanish
Common Policy - Federal Bridge Certification Authority - Chief Information Officers Council (US Government)

Okay, I give up, but you get the idea. Anyone who has a certificate "signed" by any of these (plus the hundred plus other certification authorities I have) is trusted by me. Huh? All of these certificates came with my computer. I have no idea who they are. And, I have no idea whether or not I should trust them. Thwate? That's a South African company, but is apparently a leader in certificates. Should I trust them? Ever heard of them? Wait, they're owned by VeriSign. Maybe they're okay...

What about CertRSA01 that is issued by that Korean firm KISA?

The Korea Information Security Agency was established by the Information Facilitation Act No. 14 in April, 1996 with the aim of establishing a safe and reliable information society through the development and support of information security related technology, as well as in-depth policy research on enhancing information security.

So, apparently KISA is run by the Korean government. Where did I find this information? On a Microsoft press release talking about a Memo of Understanding between Microsoft and the KISA. http://www.microsoft.com/presspass/press/2003/nov03/11-04koreainfosecuritypr.mspx.

It seems like sites certified by the KISA have been involved in, spams, phishing scams and DOS attacks. http://news.spamcop.net/pipermail/spamcop-list/2005-October/105864.html

So, should I remove my trust from these guys? And how about GeoTrust who screwed up big time with Mountain America as pointed out by the Washington Post blog back in February of 2006? Wait, GeoTrust was acquired by VeriSign back in September of 2006! http://www.geotrust.com/about/news_events/press/PR_geotrust_vrsn_090606.pdf.

Anyone who doesn't think the system is broken hasn't been paying attention. We have hundreds of root certificate authorities. Each one has various levels of verifications. Some have different verification policies based upon the type of certificate you get and the business you say you're in. Of course, that's the official policy. What about "unofficial" means of obtaining these certificates? How do I know that if you pay employee at one of these companies a few hundred dollars, you don't get a certificate by a backdoor method? Who certifies the certifiers? Who monitors them? Who makes sure they follow their own policy?

Jeff, you've confused _trust_ with _identity_. Identity is a crisp technical question with an unambiguous answer: either the bits are being transmitted to/from the site you think they're going to, or they're not. Trust is a mooshy human concept full of shades of gray.

The CA's job is to verify identity and issue a certificate which, if used correctly by the entity named by the cert and used in concert with a well-designed and well-implemented software and hardware infrastructure, provides reasonably strong evidence that identity can be correctly verified. Again, that's the crisp technical part.

There are then two trust decisions, which are not crisp or techical at all. Rather, they are about _feelings_ that you have in your brain. First, do you trust that the CA has done an adequate job of verifying identity? And second, upon the assumption that identity has been correctly verified, do you trust the identified entity? Obviously, the second depends upon the first -- if you cannot trust the CA to do an adequate job of establishing identity, then you have no reason to trust any identity verified by that CA.

As for your point about revocation lists -- no, the user does not have to have a 100% accurate and up-to-date rev list. No more than you need to garage your car in a bank vault. Rather, they have to have a list which is current enough to protect their assets against attack from a threat that they are likely to encounter.

If your point is merely that users are poorly educated about these issues and user interfaces are terrible, I'll certainly agree with that. But I do not want to conflate trust with identity, and I do not want to fall into the fallacy that security is a binary all-or-nothing phenomenon.

There are also "network appliances" that knowingly break the SSL chain of authority and do man-in-the-middle attacks. They do this under the guise of optimizing SSL traffic but it allows administrators to peak into SSL sessions.

Hope this link isn't too long. (I'd rather not use tinyurl if it's not necessary.)
http://directorblue.blogspot.com/2006/07/think-your-ssl-traffic-is-secure-if.html

Anyway, the basic idea is that the server acts as the endpoint for both SSL sessions and issues a fake cert to the client. The devious part about this it's not too hard for an administrator to push bogus certificate authorities down to computers in the domain. As a result, your browser will happily accept the cert without so much as a warning.

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.

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. AT&T & 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.

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.

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.

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.

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.

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

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.

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 D&B 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.

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.

I think the local government should have a federal policy on issuance and verification of certificates. This way we always have a federal mandated process that can be reviewed and improved on.

Identify verification is always difficult to do because documents can be forged and people can be fooled.

Another problem with certificates is that nobody knows the Certificate Authorities and how to trust them and what to read a certificate.

What happens if I get a cert for GO0GLE.COM from Verisign? I purposely put a ZERO instead of an 'O' in the name, but people won't know!

>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).

You mention the requirement of sending the CA your driver's license, I think that's worth more than you gave it credit for. Sure, for validation purposes it's worth practically nothing, but as a deterrant, it's invaluable.

Now, if someone wants to user their cert for malicious purposes, it's easy to trace that back to a real person, as opposed to with SPAM, where for practical purposes it's impossible to find out the sender. Knowing that there will be repercussions AFTER the act is enough to dissuade almost anyone from misusing the PKI system... IMHO :)

> 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.

Absolutely 100% agree with this. A few of the comments along the wires here have been to the tune of "if you don't have the CA, then MITM attacks are way too easy." Which makes me wonder: are those same MITM attacks an issue for SSH connections? What protects SSH to the point which it is considered *the* secure connection protocol these days? It too is PKI, no?

Add my voice to the pile of angry server admins who think certs are a waste and that encryption should stand on its own.

And since end users are probably not even aware of the details, what's to keep nefarious writers of software from making fake screens that show up at install time mimicking the truly signed applications?

As some previous posters have mentioned, on the internet, I think identity and encryption need to be intertwined to be effective. Who cares if your data is encrypted if you are sending it to the wrong person. I've written some other comments about this article here:

http://www.sslshopper.com/article-digital-certificates-do-they-work.html

Certs are just like any other anti-crime measure. They'll never stop anything, they will just deter.

Oh, that was interesting.

I am an end user and I don't know what any of the stuff that comes up in the boxes means. I knew about the lock meaning it's supposed to be secure, but I didn't realize how easy it was get that. Also, I hadn't realized that the address bar changing color has to do with secure sites.

Thanks.

Well, it can be simplified like this:

Imagine that you are a user and you are about to buy from amazon.com. The fact that you see a lock means that your browser has authenticated amazon.com thanks to some cryptography and that its certificate was valid and trusted by an almighty authority (verisign). Verisign took some steps to:
a) make sure their root certificate is in your OS/browser
b) make sure they don't provide an amazon.com certificate to anyone else than amazon.com

So for a non-technical user, it means that they are looking at the right site and they are not going to give their credit card info to a hacker site.

Now, let's imagine than a hacker would like to create a web-site certificate for a site that is www.amezon.com (note the "e"), they could easily create their own web site certificate for this URL (no need of Verisign for this), but when your browser would visit the site, it would tell you "hey, you are looking at a valid certificate, but you don't trust it. Do you want to continue?" It would discourage some people at this point, right?

Now, the hacker could want to have verisign issue them a certificate for their web site. They would ask Verisign to issue a certificate on behalf of www.amezon.com and, at this point, Verisign is supposed to say no. I am pretty sure that the majour Certificate Authorities trusted by our browsers/OS would not provide a cert for doubtful companies.

So, that makes it easier for you to know that you are dealing with the right web site and ot an impersonification of it.

Also, there is a difference between an email certificate (designed to prove your identity in an email) and a web site certificate (designed to enable business to consumers models). The web site certificates are much harder to get from Authorities like Verisign.

Overall, i think it is a pretty good and reliable system. There is room for improvement, education, simplification, but the cryptography behind it (public and private key) is pretty robust and well thought.

Lanceloz

Here's the above as a user reads it:

-- Snip --

Imagine that you are a user and you are about to buy from amazon.com. The fact that you see a lock means that techspeak amazon.com thanks to techspeak. Some-brand-name took some steps to:

a) make sure techspeak
b) make sure they don't provide an amazon.com techspeak to anyone else than amazon.com

<The rest is blank because the user has stopped reading about now>

-- Snip --

And then software developers wonder why users have problems with security...

Sorry, some of the above got deleted, possibly because an angle bracket slipped in somewhere. After the "(b)" part there should have been:

"At this point the transcript stops because the user has stopped reading, since they can't make any sense of the material".

Hi,

I couldn't read through all comments in the post but I'd like just to say that the problem is not "bad" guy who buys the certificate from a "trusted" source, obviously the point of the certificate it is to confirm the person that says who is, is actually that person. It works.

The problem is the "trusted" source. Tell me if I am mistaken but I would guess a provider of "trustworthiness" like VeriSign should not only accept payments from whoever wants a certificate and throw them away but check on the solicitor in order to confirm its authenticity and claims. Isn't it like that? If it is, then we only face a matter of: Do we trust enough in VeriSign?

Jorge

>Tell me if I am mistaken but I would guess a provider of "trustworthiness"
>like VeriSign should not only accept payments from whoever wants a
>certificate and throw them away but check on the solicitor in order to
>confirm its authenticity and claims. Isn't it like that? If it is, then we
>only face a matter of: Do we trust enough in VeriSign?

There's a famous (well, among security geeks) comment by security guru Matt Blaze, "A commercial CA will protect you from fraud by anyone whose money it refuses to take", which pretty well sums up this situation.

Very timely. For all of our necessary-to-be-secured sites we've just gone with Verisign for the last 8 years without questioning.

When some domains came up for renewal recently, I priced Network Solutions on the digital certificates side and was absolutely shocked in the disparity. We're paying for the name and marketing rights to it - that's all it can be. And chances are even when I present the price differential to management, after I mention this blog post and my personal thoughts, we'll stick with Verisign.

hln

Great post! Dave, love the Matt Blaze quote.

I don't think anyone's trying to provide security here, anymore than mandatory driver signing in Vista x64 is meant to provide security. The only desired effect is the perception of security - the lock icon that will keep people shopping on Amazon.com and eBay. Seriously, how many of us actually double-click on the padlock before typing our credit card numbers (and maybe even asking the site to save them for the future)? Sorry for stating the obvious, but even foolproof authenticity verification and encryption does not rule out eventual theft of data, so the the certification system doesn't need to be safe - it needs to look safe. And when push comes to shove, the few who know better are more than willing to suspend their disbelief.

Really Awsome post!

I totally agree with you on this.

https is to provide encryption (and that’s it) - of course its going to have some kinda indentification to it - doesn't mean that that is the way to indentify something though
- the browsers are another issue of trust as mentioned before - I may just want encryption for my browsing only though and maybe all web surfing could be encrypted you can use proxies also -
- I own a small business and I have to pay $150 a year for corp. taxes - $800 every 8 years for trademark – a lot in taxes - I need to have my website super scanned every quarter for security by a third party to accept Visa/Mastercard which costs another $150 and also may another $50 dollars a month for the Merchant Acct (which required a background & credit check) and on and on and on I only make about $500 a week right now, I use a shared cert through my hosting company now because I really cant afford to pay another $500 for another cert - I also give people an option to mail in a money order and print out an order form or call a number to do business over the phone - you know there is also the better bus bureau etc etc (which costs like another $500 which I cannot afford at this time) and a general reputation to provide ones indentity - you can look up corporations by state register and call em if you want it seems you maybe are too lazy to do that - I swear if I am ever forced to have a retna scan or my finger print I am just going to close my business its just not worth it its a strangle hold – there’re fees coming out my ass – I have small business selling golf clubs and rebuilding them and have happy customers and I enjoy what I do from my perspective also as a careful shopper I understand the concern
- if any one really wants to do fraud they can but hopefully if they do and are proven guilty they will be prosecuted but it seems like you are trying to exaggerate the problem to bring regulations that will ruin the free internet -
- The internet is a place to share information and do business and both may want encryption – from the business end, like I mentioned above, there are many other ways to be a smart consumer - I have decided to call in sometimes or to review a few sites before they got my business or even not did business because I didn't like their shopping cart etc. I also use a CC with a small limit for internet orders and some websites I go to like Ebay and Amazon (I make sure to type the address myself and not go from a link) and I am sure to me they have good standards, over time I have seen that and other sites I have read that they've been compromised in the past so I may see what they have done to improve before shopping there if I even would - I would never buy something from spam I get in my email lol – don’t buy it if you don’t want to, no one is forcing you to purchase anything just use some Common Sense and if you say you don’t really understand it and you are a programmer maybe you could research it more before you write about it, it seems like your blog is more of a question/ whine than an article