Digital Certificates: Do They Work?

blog
21

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.

22

@ 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=181234threshold=1commentsort=0mode=threadpid=14992669#14992689

23

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.

24

The original idea was something like the DB, 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

25

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)

26

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.

27

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.

28

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…

29

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.

30

Good point indeed. Once again, another great post.

31

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.

32

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

33

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

34

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.

35

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.

36

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.

37

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.

38

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?

39

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.

40

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.