Slashdot Mirror


Is It Time For an Open Source Certificate Authority?

cagnol writes "So far there are three free ways to get a free certificate to sign your email and receive encrypted communications: Thawte, Comodo and CAcert. Thawte's root certificate is in mainstream browsers. Thawte's interface is good and the web of trust allows for increased security by verifying people's identity. However Thawte is not open-source; worse: it is owned by VeriSign. Comodo's root certificate is in mainstream browsers too but there is no web of trust and their forms are not always working. CAcert is the closest to an open-source certificate authority but is not open-source and it seems that parts of the system are shaky. CAcert provides a web of trust. Unfortunately, CAcert's root certificate is not in mainstream browsers. Don't you think it is time for a true open-source certificate authority? Should this community be related to the Mozilla Foundation and comply, since day one, with the requirements to get a root certificate in Firefox?"

15 of 219 comments (clear)

  1. Zimmerman has it right . by Ckwop · · Score: 5, Insightful

    I've fell out of love with public-key signature schemes as a means of proving authenticity. There are a few problems with the idea in general:

    1. Nobody actually reads the certificates.
    2. Even if they did, they don't really mean anything anyway. How difficult is it to get a real certificate with fake credentials?
    3. Moreover, if the URL is similar enough to the target of your phish then your SSL certifcate may well be legitmate in every sense of the word but you trick people because the URL is close enough to a big brand's main domain.

    I think Zimmerman, with his ZPhone program, has got it right. Really, all you're interested in for E-mail or VoIP is not whether the person really is Simon Johnson, of Widnes, based in the United Kingdom who is 23 years old with a pet dog called Thornton. You're actually interested in whether this Ckwop guy I'm speaking to now is the same guy as I spoke to last-time.

    When you weaken your security requirement to this position, you can remove a staggering amount of complexity. You can cut out all the CAs, all the X.509 certificates and ASN.1 implementations etc. What you're left with is Diffie-Helman and AES in CCM mode. You can implement this in a couple of thousand lines of provably correct code and your done.

    The real way to solve the "identification problem" with web-sites is to change the way credit-cards work. You have a secure token that outputs a different string every thirty seconds. RSA have made these but they're very expensive for no explicable reason, the banks would develop an open-standard in my model to drive down prices. When you pay for something, you submit your credit-card along with the token's value. The transaction will only be authorised if the token's value matches what the bank thinks that value should be.

    That way, phishers only have one shot to take your money. Sure, they could make a mock payment page but the auth-code is only going to work once. I think this would destroy the cost effectiveness of phishing for credit-card numbers. That said, identity theft would still be an issue.

    Simon

    1. Re:Zimmerman has it right . by Workaphobia · · Score: 4, Insightful

      Credit cards simply should not work based on knowledge of a stupid number. Change the system so that every transaction is authorized through a direct communication between the cardholder and credit card company, and you've eliminated the danger of not knowing which merchants to trust with a common number.

      --
      Evidently, the key to understanding recursion is to begin by understanding recursion. The rest is easy.
    2. Re:Zimmerman has it right . by kestasjk · · Score: 2, Insightful

      Nobody actually reads the certificates.

      Nobody has to if you trust the certificate authority. What use is reading it anyway, if it hasn't been signed by a CA/friend and can be tampered with?

      Even if they did, they don't really mean anything anyway. How difficult is it to get a real certificate with fake credentials?

      If a CA is worth its salt, nigh on impossible; that's what you pay those ridiculous prices for (at least, that's where the money should go). This is the main problem with an open CA; there are presumably fewer security checks that the person requesting the certificate is who he says he is.

      Moreover, if the URL is similar enough to the target of your phish then your SSL certifcate may well be legitmate in every sense of the word but you trick people because the URL is close enough to a big brand's main domain.

      That's a phishing problem, not a crypto problem.

      I think Zimmerman, with his ZPhone program, has got it right. Really, all you're interested in for E-mail or VoIP is not whether the person really is Simon Johnson, of Widnes, based in the United Kingdom who is 23 years old with a pet dog called Thornton. You're actually interested in whether this Ckwop guy I'm speaking to now is the same guy as I spoke to last-time.

      This is exactly what happens when you cache a certificate which hasn't been signed. If you go to, say, https://hackinthebox.org/ you will get a certificate warning because it hasn't been signed. You don't know if anyone has replaced the certificate along the way, but once you have cached the certificate you can be sure that you are securely communicating with whoever sent you the first certificate. Using a certificate authority means that you can also be confident that the person who sent the first certificate are who they say they are.
      So whatever the ZPhone is, it sounds like plain old certificate-less public key encryption.

      When you weaken your security requirement to this position, you can remove a staggering amount of complexity. You can cut out all the CAs, all the X.509 certificates and ASN.1 implementations etc. What you're left with is Diffie-Helman and AES in CCM mode. You can implement this in a couple of thousand lines of provably correct code and your done.

      Ensuring secure code doesn't bother me, I'm much more interested in having secure protocols. There's no point of having "provable code" if all the protocols are vulnerable to man-in-the-middle attacks (the attack which certificate authorities are designed to prevent).

      The real way to solve the "identification problem" with web-sites is to change the way credit-cards work. You have a secure token that outputs a different string every thirty seconds. RSA have made these but they're very expensive for no explicable reason, the banks would develop an open-standard in my model to drive down prices. When you pay for something, you submit your credit-card along with the token's value. The transaction will only be authorised if the token's value matches what the bank thinks that value should be.

      Credit cards? 30 seconds windows during which my money is accessible? We already have things that are better than this.

      As regards the Certificate Authority issue here is the rundown as I see it:

      • The current way things are: CAs are very expensive, which means sites often don't use any encryption at all.
      • Having an open certificate authority: Who pays for properly checking that a person is who they say they are?
      • A key signing network: This is the idealistic approach, done at the moment in GPG keyservers; Everyone signs their friends' keys, who sign their friends' keys, and a web of trust is built up. It takes effort though, and there are still trust issues.
      • A government CA: The government assigns public/private keys to individuals and bus
      --
      // MD_Update(&m,buf,j);
    3. Re:Zimmerman has it right . by iabervon · · Score: 2, Insightful

      Public-key crypto is still useful so that people can have a certificate that they keep really secure which signs certificates that they carry around and use. Furthermore, it's useful for cases where you want to know what somebody else thinks: this really is "that site that my friend recommended" or "a company known to the state of California". The problem isn't PKI, it's the notion that (1) signatures without assertions mean something, (2) "authenticated" without a user-meaningful identity means something, and (3) there are authorities who know globally useful information.

      The way is should work is that the browser remembers certificates it's seen before, and allows the user to make statements about certificates which are then used to inform future interaction with the certificate. E.g., when I go to my bank's secure web site the first time, I get a little note that says "this site has a certificate that can be used to identify it in the future". If I click on the note, I get a window that lets me say, "Recognize this site as: My Bank". Then it asks me how I know. I compare the fingerprint on the screen with the fingerprint on my latest bank statement, and they match, so I check off "I verified the fingerprint" (the default was: "I don't really care if the wrong site is identified as 'My Bank'"). From then on, I expect to see a little bar in the browser when connected to my bank that says: "This site is recognized as 'My Bank'" with decorations to see that the recognition is good. If I didn't check off anything for how I knew, there would be a bunch of question mark decorations.

      Other options would include: "I trust the chain: US Government recognizes Massachusetts Government as A State Government, and Massachusetts Government recognizes this site as A Massachusetts Bank." This would get the site a decoration with some little flags and some question marks, indicating that I'm at a verifiable business, but I could be at entirely the wrong legitimate Massachusetts bank site, because nothing in the chain of trust says it's actually my bank. (This is the chain that you'd usually use for e-commerce; you don't know anything about the site other than that it's a business that the FBI could find, but that's all you need to know to buy a lamp from it. But if you got here expecting it to be the place you got the matching table from, and your browser doesn't recognize it, you're probably at some other store.)

  2. In reality... by tomstdenis · · Score: 4, Insightful

    They shouldn't be issued by private corporations but instead by the man who issues the business licenses. Otherwise, it's meaningless. So I setup p4ypal.com, buy a cert and trick people to go there. Whoopy.

    What do certs really mean anyways? Just because company.com has a legit cert from verisign doesn't mean they're a good company. It means that I'm talking with company.com. Big deal.

    Tom

    --
    Someday, I'll have a real sig.
  3. What is the question? by smallpaul · · Score: 4, Insightful

    The question posed is "Is it Time for an Open Source Certificate Authority?" But the description does not address the question. Rather it addresses the question of whether there is an open source certificate authority. First: someone needs to define what it means for a service to be "open source". Second, they need to describe why anyone should care whether a service is open source. That would be a better start to the dicussion than a laundry list of certificate providers.

  4. Certificates are a scam by Anonymous Coward · · Score: 3, Insightful

    I've been saying for years that security certificates are a scam. Everybody knows it's a meaningless number. You can write your own security certificates. With the choice between paying $100s to some shady "security company" or generating your own for free what would you choose? Face it, certificates are another barrier to trade and security compaies are greedy mafia and nothing more. How can Thwarte or Verisign or whatever be at the root of a "web of trust"? Trust from whom. Not from me. And if I'm writing the system who gets to say what is and isn't trust? From the uend users perspective, the only person that matters, they never heard of Twarte or Verisign. How would they know a certificate from those companies from another you made up with an impressive sounding company name like UltraSecure or SafeClick? It's a meaningless game. And it's not like this "trust" gives any party some legal recourse or adds accountability to the operator. Yep, Open source certificates all the way. Anyone can set up a verification system selling zero cost numbers to strangers if they sign a form or show their driving licence or something, but it wont make anybody or anything more secure.

    1. Re:Certificates are a scam by tepples · · Score: 2, Insightful

      You can write your own security certificates. With the choice between paying $100s to some shady "security company" or generating your own for free what would you choose? If you generate your own certificate, how do you 1. convince end users to install your certificate and 2. teach end users how to install your certificate?
    2. Re:Certificates are a scam by mollymoo · · Score: 2, Insightful

      I've been saying for years that security certificates are a scam. Everybody knows it's a meaningless number. You can write your own security certificates. With the choice between paying $100s to some shady "security company" or generating your own for free what would you choose?

      Everybody knows it's a meaningless number? Your grandma knows that, does she? Very few people know anything about certificates at all. All they know is that if they go to Amazon's secure pages, a little padlock appears and they've previously been told that this means it's secure. If they go to your site with your self-signed cert, it asks them whether they want to trust you. If this is for e-commerce, you've just lost most of your customers. Normal people trust their computer, they trust their web browser. If Microsoft or Mozilla say they trust Thwaite and Thwaite say they trust Amazon, the user trusts Amazon. If Microsoft or Mozilla don't trust you, the user is much less likely to trust you.

      So, if you want anybody but the most technically knowledgeable to trust your certificate, you pay a couple of hundred bucks to the "shady" security company. I trust Thwaite a whole lot more than I trust an Anonymous Coward on Slashdot.

      --
      Chernobyl 'not a wildlife haven' - BBC News
  5. We already have by Watson+Ladd · · Score: 4, Insightful

    It's called GPG. It can be used with TLS as GNU TLS demonstrates. The one issue is making sure that GPG/TLS is implemented more widely.

    --
    Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD
  6. PGP? by Anonymous Coward · · Score: 1, Insightful

    "So far there are three free ways to get a free certificate to sign your e-mail and receive encrypted communications: Thawte, Comodo and CAcert."

    I must be missing something, because the first thing I thought of was PGP that we've had for 16 years.

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

  7. Encryption and authentication are conflated by Alain+Williams · · Score: 3, Insightful
    It is useful to have the communication between the server and web browser encrypted, this is what https (port 443) is all about. It would be useful to be able to ensure that you are surfing the web site that you think you are ... https purports to do this, but does not do it well - as others have said.

    The problem is that if you want encryption, you either buy a certificate or you have the user presented with a misleading dialogue box that suggests that you are not trustworthy ... or rather the reverse is not true: just because you have a certificate does not mean that you are trustworthy.

    Joe Sixpack does not understand the difference - which is only good for the profits of Versign and friends.

    It would be nice if the two could be somehow unlinked.

  8. Re:Great idea by fyngyrz · · Score: 4, Insightful

    The idea is sound enough, it just doesn't go far enough.

    Certificates and the technology surrounding them provides two things, one of them useful, one of them harmful. The useful thing is encryption. This means that as your data goes from point A to point B, it is very, very difficult to make any sense of. This is useful because often, as in the case of when we share our credit card data with some other entity, that is as far as we meant to share it and the encryption erases one of the situations where it is highly vulnerable to interception by others. We definitely want encryption.

    The harmful thing is the illusion of "identity." This is 100% harmful, and on several fronts. First, the idea that you "know" who, or where, you are "locking certificates" with is illusory. No mechanism within the process positively or reliably identifies where, or which, computer you are connecting with, only that the certificate at hand has, at some point in the last year or more, been issued by a "certificate authority" that was convinced to some degree that at the time the certificate was issued there was somebody at a phone number and an address, possibly with a business, possibly not. They could have moved 20 minutes after the certificate was issued, and they'd have [certificate expiration time] to fraud up a storm if they so chose. In no way does the actions of the certificate "authority" serve to determine if that entity had nefarious intentions, or if the transaction you are entering into at any one time is legitimate. So you don't know who, or where, you are "locking certificates" with, and nothing the "certificate authority" does even begins to help you out in this manner. Despite very expensive marketing campaigns claiming precisely the opposite, gaining the consumer's trust with glossy, high end advertising.

    But things are even worse, because with that illusion of "trust", the impression that the consumer no longer has any reason to check out the business is quite strong; this is partially a consequence of the method, but it is also a marketing lie told to consumers, and there the responsibility rests upon the promulgators of the scam, the "certificate authorities" themselves.

    The fact is, as a consumer, you have to determine the legitimacy of the business yourself, and if you don't do that, there isn't a single thing that the "certificate authorities" have done, or can do, that will reduce your risks.

    Now we come to the idea that to be useful, certificates have to be issued by a certificate authority. This is entirely false in terms of service, but entirely true because there is a huge scam going on.

    Service-wise, a vendor can produce their own certificate, 100% as effective at encryption as anything they can get from the "certificate authorities." That certificate is 100% capable of working with any browser and protecting data during transfer to the connected party as well as anything they might get from a "certificate authority." So effective encryption 100% identical to what everyone uses now doesn't require a "certificate authority." Period.

    Scam-wise, not the certificate authorities, but the browser vendors (though certainly encouraged by the "certificate authorities"), have created a situation where if the certificate you have cannot be traced in origin to one of the "certificate authorities", then the browser will pop up a warning and scare the dickens out of the consumer, thereby eroding your ability to do business. Consumers don't understand what is going on, all they know is they got a WARNING OMG WTF.

    Therefore, to do e-commerce, a vendor must use a certificate from a "certificate authority" or they will have shot themselves in the foot. It would be the work of only a few moments for each of the browsers to remove these untrue, scam warnings; at that point, any properly generated certificate would work to provide encryption, consumers would stop getting these baseless warnings about "identity" t

    --
    I've fallen off your lawn, and I can't get up.
  9. Re:Very Large Prime Numbers by Zeinfeld · · Score: 2, Insightful
    Better yet, generate the keys on a smart card so that the private key can't be extracted or exported by code on your computer. Do you really trust your OS? With a smart card, the signing occurs on the card and not in your computer. This improves the system security at a much lower cost than doing the signing in a special crypto hardware module.

    Exactly, and if you want to be a CA you should be looking at very high security hardware such as the Chysalis or n-Cipher products which are FIPS 140-4 certified.

    I think that the premise of this whole article is wrong. What people need is an open source mechanism for communicating securely. The most practical model is almost certainly not going to be a CA. Unless you are going to be serious about the authentication criteria you might as well use self signed certs.

    The whole point of the CA model is to concentrate trust in one link of the chain and to lock it down with really tight security. Thats not the sort of project that fits the open source model well. Anyone want to try open source heart surgey? How about open source tax accounting?

    People might have fun setting up a CA but running one is about as interesting as watching paint dry. Particularly if nobody is going to be paying you to do it.

    If you want to go this route get rid of the CA entirely, just make sure that you also get rid of any security indicators that might give the user a misleading indication of the level of security being achieved.

    And don't just fixate on Phil Zimmermann, look at the ideas of people who made the web of trust model work, like Brian LaMachia. Look at ideas like SDSI/SPKI that Rivest and Lampson worked on. Take a look at XKMS and DNSSEC.

    Above all start by deciding the use cases you are going to be serving. If you want to support online commerce the level of trust you have to achieve is going to be very high. if on the other hand you want to allow people to read their email or post to their blog over SSL encryption the barrier is much lower.

    --
    Looking for an Information Security student project suggestion?
    Try http://dotcrimeManifesto.com/
  10. Re:Great idea by fyngyrz · · Score: 2, Insightful
    but on the Internet the work you did to determine whether a business is acceptably safe is wasted if you end up at a typo squatter's site.

    As I said, it is up to us to take responsibility for what we are doing. Who typed the address in wrong? And since the answer is the user - us - then whose fault would that be? Not the legitimate businesses, and not even the CAs; No, it is the ours. And my precise point is that we should be careful with what we do, the certs don't help in any way to ensure we are where we meant to be. For that, we need our eyes, our memories, and our wits.

    limited by the relatively weak checking and the fact that virtually no customers understand it

    It isn't limited by it, it never existed in the first place. Customers - IOW your average netizen today - look for the lock indicating encryption is on. If they look for that. There never was any value here, it is entirely illusory, the product of a very powerful marketing campaign. It's a scam, one that will only evaporate if the browser manufacturers wake up and realize they are the fools in this chain of fraud - they get no income, they screw the vendors, and they enable the scammers - the "certificate authorities" - to rake in huge amounts of money for no service, unless you call deceiving Internet e-commerce customers a "service."

    if you see a cert then you can look at the DN and know where to send a process server if something goes wrong

    Again, no. Reputable people will be right where they said they would be. Which doesn't help, because you're not looking for them. Scammers will not. You can send the process server to the address on the certificate, but they won't be there. Cert authorities only check (if they do check at all) that you are where you say you are when they issue the certificate. The same day you get it, it can be installed on your laptop, and the very next day you can be taking orders a thousand miles from there. The cert authorities don't have any idea of your post-purchase whereabouts, nor does the address on the certificate help even a little bit.

    In principle, certs from CAs provide the mapping from a public key to meatspace identity

    That's my precise point. They don't do any such thing. They can't. Where the scammer was the day the cert was issued is in no way tied to where they are when you try to go after them.

    --
    I've fallen off your lawn, and I can't get up.