Slashdot Mirror
Self-Regulating SSL Certificate Authority?
bcg asks: "It has come that time again to renew some of my SSL certificates and part with substantial amounts of cash. This has got me thinking - why should we pay large amounts of cash for authorized certs when so little is done by the companies issuing them? Sure they get you to send them a copy of a business certificate but how does this prove the character of those running the SSL server? What ideas can we come up with for a self-regulating certification authority? Could we set something up along the lines of the many free DNS servers around but use it to authenticate SSL certs?"
We last touched on this subject in October, when someone was searching for cheap
SSL certs. We've also discussed why certs are so expensive. Why not take it one step further and discuss ways of making and authenticating our own certs for free...or as close to free as possible?
>Sure they get you to send them a copy of a >business certificate but how does this prove the >character of those running the SSL server?
They aren't supposed to be verifying your character, they verify your identity.
Just self-sign a certificate. Truly, if it's not signed by some big name registrar, most internet users (IE of course) will get messages notifying them that it's not a "trusted" certificate anyways.
Personally I see very few reasons why these should not be obtainable openly.
All that a Trusted CA issued certificate says to me is that the potential scammer had the money to buy an SSL certificate.
Want them cheap? Let the GOVERNMENT handle SSL certs! After all, they're already handling drivers licenses, social security numbers, and ten kazillion other things that are supposed to prove that you are you, why not just give you a cert, too? For a small government fee, of course.
You call this a signature?
Hell, even Microsoft says that on their windows update site for the active X download it throws onto your computer during your first visit!
Someone should do a study on this, sounds like a great high school science fair project! I can see the display in the gym now, pasted on the cardboard display case "Are people idiots?" and have nice pie charts and tabular data from your research. It beats boiling something in a test tube to see how long it takes at different temperatures or testing the growth rates of different molds...
A certificate lets the client know that the server belongs to an organisation and that that organisation was verified by somebody else.
In a network like the Internet there's no God in a security sense - so we choose to trust people who Verisign trust (and issue certificates to).
It's a pain in the ass to get the certs issued because you have to get you organisations legal certificates and get authorisation from a senior staff member - but thats a Good Thing because they make sure that you are who you say you are (and are authorised to get a certificate on behalf of your organsation, yadda yadda).
If you have a private network, or have an existing relationship with the end users, who cares? Go to wwww.openssl.org download the toolkit and play around with the certs! You'll get a secure channel and not have to pay loads to establish something you already know.
Julian.
My standard rant about why I use my own certs:
Digital certificates are available, for a fee, from a commercial certificate authority (aka CA) such as Verisign. For about $15 a year Verisign will claim to know who you are though you provide no proof other than the grand American Dollar. If your credit card clears, then Verisign says email from you is from you. Why is this worth $15? If I send a signed email to someone and they verify that signature based on the cert I send them, then the only reason to trust that the cert is based on the trusting the signing CA. Verisign says that if I have a credit card with a name on it, then I am the person with that name. Unfortunately due to identy fraud, this is often not the case. In our family we have been victims both of simple credit card fraud (where are card number was stolen and the card duplicated) and full on identity fraud where our social security number was used to open credit accounts by people other than us. So merely the possession of a credit card number does not imply identity. By trusting Verisign you are trusting the US credit industry, which is corrupt and insecure.
Assume that you do trust that credit cards are valid identifications. Why would you trust the CA who took that as ID? How do you know who the CA is? CA's are identified by certificates just as users are. How did you get a certificate for the CA? Usually it is because Microsoft and Netscape include a set of certificates from trusted CA's in their products. If the cert comes from one of those CA's then Microsoft and Netscape say it's valid. Therefore you must trust that Microsoft and Netscape included authentic certs, and you assume that those certs have not been compromised since you installed the software. Maybe you think I'm paranoid. Really I just object to paying money for something I can do better myself.
I have created the Greenbaum.Org Certificate Authority to create digital certificates which are free and trusted. If you get an email from me, signed by a certificate issued by me, verified by the CA certificate you download from this site, then the email was from me. If you get an email from me, signed by a Verisign certificate, then it could have come from the gangsters who stole my credit card to buy Nikes and chinese food.
I see several difficulties with a free SSL-CA (as I see with free DNS/TLDs/whatever):
:-)
It's a great idea, but... who will use them? To be more specific: Verisigns capital is that it's root-certificate is in every browser on this planet. I don't want to know how much cash they had to throw at M$ to get their cert. into IE, but I doubt that a free CA can come up with that amount. Sure, we can probably get the certs into mozilla etc. and joe-schmoe IE-user can add the root-cert to his known certificates, but question is: what impression will your trustworthy buissiness give him, if he gets lots of warnings when on accessing your gimme-your-visa page. 'It's the value of trust(tm)'
just my two cents...
You could perhaps add the idea of a threshold -- once a cert is signed by enough well-trusted individuals, the cert becomes "good enough" to go public.
Of course, there might be an issue of startup time -- a requestor of a new cert wouldn't get one until it has had time to make the rounds and get signed by many trusted individuals.
There is also a bit of a seeding problem. How do you establish a large enough trusted community in the beginning, so that sufficient signings can be made on new certs.
Also, I would guess that one of the things that current commercial cert corporations provide is a source of culpability, should something go wrong with the cert they issued. With a public signing group, you might not have this same level of responsibiliy. This could be good or bad, depending on your perspective.
The only reason the big companies charge so much (their claim, not mine) is the insurance they provide, and the fact that they are "trusted" by the various vendors.
Any new group wanting to be a trusted CA will face the liability issue -- if one of your customers sues you, even if you try to disclaim all liability up front, you will still face massive court fees. Even if you won in court, you would lose financially if not insured.
There is no technical or logistical problem with setting up a Free (and free) common-geek's CA, the problems are entirely legal ones. I know because I looked into it right after SSL came out. It looks like a good business plan, right up until someone takes you to court.
frob.
//TODO: Think of witty sig statement
Basically the security behind SSL certificates (and all certification technologies) is that you trust the CA (the root of the certificate path).
Commercial companies are trusted because they would go out-of-business if they lost your trust. So basically you trust in the fact that they want to make money.
So here is my point, besides financing and all the other issues, how do we establish a chain of trust?
Why not have a self-regulating authority? Well, let me submit a request to sign my certificate saying I'm Amazon.com, hijack the domain and steal credit cards. The point of CA's is to do some background checking to verify you are who you say you are. Debatable, agreed, but is you're average script kiddie, cracker, etc. gonna shell out bucks to get a fake cert? Probably not. Not to mention once money is involved, there is an audit trail of some sort.
As for whether the prices are gouged a bit, I won't argue with you there. Seems that it shouldn't cost as much as it does, but at the same time I'd think most companies rack it up as a cost of doing business (just like rent, equipment leases, etc)
-- A computer without COBOL and Fortran is like a piece of chocolate cake without ketchup and mustard
Ladies and gentleman, a round of applause for the only Slashdot editor who reads Slashdot!
Reply or e-mail; don't vaguely moderate. Ex-O'Reilly/MIT employee, now a full-time Google employee.
Just create your own CA certificate and then write an html page for Netscape and another one for IE so that it loads your CA certificate into the browser's certificate database.
Then use your CA certificate to issue as many certificates as you like. As long as the DN matches the hostname or IP of your HTTPS server, your users' browser will play along happily.
http://sourceforge.net/projects/xca/ http://sourceforge.net/projects/php-ca/ http://sourceforge.net/projects/stealthisca/ http://sourceforge.net/projects/mkcert/ Alas - most of these are in alpha....
It's Christmas everyday with BitTorrent.
Most of us just want the encryption features of SSL; most of us don't want it for authentication.
If you are a bank or something, then by all means authenticate your identity. If you just want to keep packet sniffing from being effective, self sign it.
GPG/PGP keys are always self-signed, yet no one complains about authentication of identity. Maybe we should all carry a compact flash card of our SSL keys!
You can't judge a book by the way it wears its hair.
And how would I know that the content of some online store that sends me a self-signed or home-brewed-CA certificate is not entirely faked by man-in-the-middle credit card # collector ?
And while you are 'thinking web, not hierarcy' also set aside some time to think how you would be building that web in first place. In particular - how you would be establishing trust with comletely foreign parties.
3.243F6A8885A308D313
The best way I can think of to do this is setup an infrastructure similar in principle to Google's PageRank. So, anyone can be granted a certificate, but the strength of that cert is based upon an index of reputation. Which to me personally, is somewhat more meaningful than any given company(TM) buying a certificate. What method you'd use to create such an index would require more investigation, with considerations for security and spoofing prevention.
At it's base though, I like the concept. And would like to hear some ideas on what we could use as "karma" *cough*... Realistically though, (and this is where I need help from those more familiar with SSL certificates than I...) is there a facility in the signing process which allows for extra certificate information at the time of request? To my memory, I think there is. For instance:
With the infrastructure already there, methinks the implementation is somewhat trivial. Can anyone help me refine the method?
Remember: umount it before you fsck it.
Nevermind all the other uses for ssl certificates.. if you are referring to secure web sites, which you probably are, the reason we don't all make our own is because the browsers will whine about not recognizing the CA.
This is percieved to turn customers off... so you pay up so things are smooth.
That is the real reason.
If you are talking about certs for vpn stuff, etc.. there is no reason to go with verisign or anyone else.. by all means, make your own. All you need is openssl.
Have a ranking system that would base trust off the number of certificates, the age of the certificates and complaints from users.
So basically a centralized authority that gives out free or cheap (as in as cheap as domains) certificates.
You sign up with them as a reseller. All of your customers buy certs from you.
I'm thinking of this in terms of being a hosting provider as I am.
So I sign up with this centralized authority and purchase certificates for my customers.
Browsers could have a blacklist check on certs. So you try to hit one of my sites, it validates against your list of blacklisted sites that you updated last month and either:
A. Shows up with a good rating.
B. Doesn't show up because it's too new.
The user could then set a threshhold of trust and if the cert passed that threshhold it wouldn't warn them.
This idea isn't very thought out, just an idea I threw together. Run with it.
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
You can get free ones from cacert.org.
I use them to SSL enable my website at glasgownet.com and any other stuff I need certs for.
Well worth it.
In general, there's a lot of confusion about Public Key Infrastructures, partly because of the big gap in the middle of "1. Write Marketing Hype!! 2. ???? 3. ???? 6. PROFIT!!" chain, but mainly because there are different ways to answer questions about "Who's certifying whom or what to do what or be who or what?" which lead to different applications and solve (or fail to solve) different business problems. One major effort to address this systematically is the IETF SPKI Simple Public Key Infrastructure group, much of which is based on the work of Carl Ellison and Ron Rivest (RFC2692, Requirements, RFC2693, Theory.) It turns out that, while the "Some Authority Certifies that You have Documents with your True Name" model that's popularly used is often useful, it's often not the right model, and there are often more useful relationships, such as the DNSSEC authentication used for web sites and email.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I used to work on Microsoft's Public Key Cryptography QA team. We worked with Verisign to create fake certificates to test IE's SSL and Authenticode signed downloads. When we were done testing, someone on our QA team called Verisign customer service and said, "hi, I work on Microsoft's QA team. We are done using those fake certificates for our tests. Can you please revoke (cancel) them?"
Without any further verification, the Verisign customer service agent pushed a button and canceled the real Microsoft certificate, the one used to sign all of Microsoft's downloads, device drivers, and CDs. oops. Luckily, no one pays attention to Verisign's CRL (Certificate Revocation Lists) because certificate revocation is off by default in IE. Since no one really used the CRL, Verisign was able to the remove Microsoft from the CRL and reinstate the Microsoft certificate after a couple days.
So when you "trust" Verisign, think hard about what that really means..
cpeterso
In addition to establishing identity, certificates also allow the transmission of securely (for now) encrypted data. This is the feature everyone wants - the identity aspect is just something for Verisign to hype.
Self-signed certificates are ludicrous - it takes only a few moments longer to create your own CA (certificate authority, what Verisign is) and issue yourself a certificate. Then just link incoming clients to the CA certificate, which will be added to their CA list if they accept it, and after that your site will be free of certificate warnings.
Any benefit that 'root CA' lists may have had has been overridden by uninformed sysadmins. Too often are servers moved to new hostnames or domains, or certificates forgotten to be renewed, etc.
Users trust you to take their data and charge their credit cards, protect their personal information, send them material by delivery and provide information that is true. Why, then, wouldn't they trust you to generate a certificate yourself?
As mentioned above, the endorsement of an arbitrary company means nothing, but responsiblity and security awareness of sysadmins means everything. Owning a credit card does not prove the latter.
-Elentar
The wheel it turns, around and around, with an ancient rumbling sound.
My problem occured when trying to get a cert for a small group of alumni. We've got about 50 people in it. We're just trying to make it possible for us to discuss things on our bulletin board with passwords protected with SSL.
We payed our money to Entrust. We still have not gotten a certificate or a refund. They first required that we prove we have a relationship with the school. We aren't an official organization, don't pretend to, and don't use their domain at all. It's completely separate.
So next they required we show articles of our encorporation. Is this what's required to have a certificate? Why can't joe-random-webmaster have a valid certificate from the "big guys"? Sure, you can go with smaller outfits, but their certs aren't in older browsers.
IMHO, a cert should simply say "This cert was given to the folks who run www.this_domain.com." They can check and verify whois data and your ability to receive email. Any other requirements are just stupid. Just because you want SSL doesn't mean you want to be an e-commerce site.
TLS (SSL) does not need the ugly PKI technology to operate. SSL/TLS could very well use PGP keys. The difference is that PGP technology is more well designed and lends better to help building a web of trust.
Some people might say that newbies can't handle the complexity. Well it's the responsibilty of software developers to help them overcome this. Example: As the same PGP keys would be used for mail, the web of trust could be linked to the addressbook handling.
Besides, the current model gives a sense of security which is not real. Do we really trust CA's? When you go to an "internet cafe", do people check that the list of trusted CA's haven't been altered. In this way, PGP would bring the real sense of security/insecurity which is currently "masked".
FreeSSL offers free certificates. They confirm by email and an automated phone call. You'll be certified in 10 minutes or less. I found them after reading this article and looking around a bit. Absolutely no problem getting it working. Wish I had know about this sooner.
Yes, they also have non-free certs, but for the life of me I can't figure out the difference. My only question is how they make any money offering free certs and making automated long distance confirmation calls.
Gotta say, it's pretty cool when you press # on your telephone and the web page updates to show you've been confirmed.
Now if only I could figure out a way to get SSL working better with name-based virtual hosting.
- Some browsers do not allow you to click 'yes' at all. Think older IE browsers which simply gave you the "something is wrong" page. It may be a completely valid cert in Mozilla, but with this browser you can't view the page no matter how much you want to.
- If you do get the ssl warning and the option to say "yes", how do you know you're not the victim of a man-in-the-middle attack?
Unless you actually control both endpoints (say you are setting up SSL using Stunnel on machines you run) then self-signed certs are not perfectly secure. Or, if you do verify everything as you should, you have introduced a huge hassle in performing secure SSL.For example the latest version of Blazer for my palm has no such feature, so I'm screwed.
In order to click "yes" you should verify that the SHA1 and MD5 fingerprints are correct. Do you carry a copy of these around in your wallet so you can use that web page when you're on the road? I didn't think so.
I only wish I had one.
I use so many SSL certs that I became a reseller for InstantSSL. It basically costs $200 and you get the ability to generate all the certificates you want without first providing business licenses. It also costs about $8 less, too. There's also zero turn around time...I get the completed cert immediately. It's *extremely* convenient but it kind of defeats the concept of a trusted source.
We need to divest SSL from CAs. Encryption should be CA-less. If a user and site want to require identification securely, then there should be a separate way (or optional way within SSL) to accomodate that.
-- @rjamestaylor on Ello
What many people commenting on this story fail to realize is that the Certificate Authorities (CAs) are guaranteeing the integrity and security of their process, and not so much the identity of the person or entity applying for the certificates. In our messaging system, we had set up our own CA to issue personal certificates signed by signing certs that we bought from verisign. Since non-repudiation was an important feature of our messaging system, we did not rely on Verisign to verify identities for personal certs. Typically, a company would contract for us to provide personal certs for their people, and they would be responsible for connecting people with certs.
The idea of connecting site certificates with the issuing of domain names is a good one because the organization issuing the domain names already has a relationship with the owner of the name. This seems like the important link for site certs, and since it represents the potential for additional profits for the issuing organization, I would think they would jump on it. Of course, that's probably part of the problem as well, that nobody wants to pass up the potential revenue, so it is hard to set up the necessary relationships.
That said, it should be clear that it wouldn't be that hard to create a 'public' CA, but it couldn't be free either. When this came up before I outlined how it could be done in a comment, but how would you know you could trust this. I could create certs for myself and my friends, but who else would trust it. It isn't that hard to add new root certs to most browsers, so there is no reason you couldn't do this for your company or organization. If more organizations were actually using client certs to authenticate, it probably would be worthwhile to create a cheap, but secure, public facility.
If anyone has the persistance to actually make this happen, I would certainly be open to helping design the processes and maybe write some software. It really is an excellent idea. Ultimately, I would consider it a complete success when the root certs are pre-loaded into most common browsers. It is completely doable, and although there are important details to get right, it isn't really all that complex.
My first thought as to what you are buying is that Verisign has dealt with microsoft and netscape to make sure their root certificate is in the browser so you don't have to worry about users getting a popup.
What I would like to see (and never will because of profit) is for me to buy a SSL cert, have Verisign or whoever REALLY verify I am who I say I am. Then from my cert be able to generate as many as I need, and so on.
That way, say school.edu could buy a cert, then generate certs for www.school.edu, pop3s.school.edu, otherwww.school.edu, or even generate one for department.school.edu who could then generate one for www.department.school.edu
After all, aren't they supposed to be about a chain of verification up to the root cert?