Self-Regulating SSL Certificate Authority? 269
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?
Character? (Score:5, Insightful)
They aren't supposed to be verifying your character, they verify your identity.
SelfSign it! (Score:4, Interesting)
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!
DNSSEC is usually the right choice (Score:5, Insightful)
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 [std.com] of Carl Ellison and Ron Rivest (RFC2692, Requirements [isi.edu], RFC2693, Theory [isi.edu].) 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.
DNSSEC isn't (Score:2, Informative)
"We are still doing basic research on what kind of data model will work for dns security. After three or four times of saying "NOW we've got it, THIS TIME for sure" there's finally some humility in the picture... "wonder if THIS'll work?"
It's impossible to know how many more flag days we'll have before it's safe to burn ROMs that marshall and unmarshall the DNSSEC related RR's, or follow chains trying to validate signatures. It sure isn't plain old SIG+KEY, and it sure isn't DS as currently specified. When will it be? We don't know. What has to happen before we will know? We don't know that either.
2535 is already dead and buried. There is no installed base. We're starting from scratch"
Re:DNSSEC isn't (Score:3, Insightful)
The big problem is getting buy-in from the people who run .com, which hasn't happened; I don't suppose there's any overlap between the people who run the various DNS registries and the people who run certification authorities, or that that would have anything to do with it, or that ICANN's many disfunctionalities are at all related? (Sigh.... Versign buying Network Solutions certainly didn't help, not that the business models in the registrar/registry world aren't confused enough.)
Maybe we will end up building some parallel structure that doesn't depend on the root servers or the COM/NET/ORG servers, or some of the other TLDs will start implementing it. I keep hearing various rumbles about Norway or Finland or Tonga, but one of the big registrars could also catalyze it if they wanted.
It's not the data models, it's the processes (Score:4, Insightful)
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.
Why require "identity" at all? (Score:5, Interesting)
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.
Re:Why require "identity" at all? (Score:2)
> discuss things on our bulletin board with
> passwords protected with SSL.
> We payed our money to Entrust.
What possible need do you have for a purchased certificate? Just self-sign and move on.
Self Signed Certs aren't always an option (Score:4, Informative)
- 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.
How about Free? (Score:4, Interesting)
Re:How about Free? (Score:3, Informative)
That's why I need trusted SSL, anyway...
Re:How about Free? (Score:3, Insightful)
Self-signing is ok - but if you work for a big company and/or a financial institution - a CA is like an insurance policy. True - most end users don't know what a CA is, let alone know how to tell if one's legit.
The last dotcom I worked for bought CAs for liability and safety reasons - they were an online bill presentation and payment company.
It's Only an Insurance Policy If... (Score:2)
Sometimes a free or El Cheapo cert is enough; it gives you some calibration on risk levels. I've got a PGP key that I use to sign untrusted pseudonyms, with the policy that I'll only sign any specific name once.
Re:How about Free? (Score:4, Informative)
FreeSSL [freessl.com] also offers inexpensive (though it doesn't quite seem to be free) certs.
They seem to work with Lynx, Mozilla-based browsers, IE... Well. Look at the compatibility list. =]
If you want to be compatible with EVERYONE, you'll have to spend a bit more, but these are good for the majority of e-commerce sites, and intranets/basic sites.
-Sara
Re:How about Free? (Score:2)
Re:How about Free? (Score:3, Interesting)
This is probably true, but it certainly won't change unless there is a way to get that "FREE Certificate...".
Gradually, I can envision some vendors switching from Verisign to Free.... and I can envision myself ordering from them; For example, with vendors that I've ordered from in the past and had good experiences with.
Anyway, like several people have pointed out, a free cert is easy to make, with self-signing. The only advantage to a free-CA would be if their certs didn't generate warning messages on the browser like self-signed ones do.
In order to do that the right way, the free-CA would need to get their public key bundled into the popular browsers... a process that is probably pronounced "kickback".
The alternative way to do this is to try for a "grassroots" adoption of the CA's key into people's browsers. If you visit a site using a Free-CA-signed cert, you'd be encouraged by the site, somehow, to actually import the CA's public key... which would put Free-CA on an equal footing with Verisign and Thawte... on that browser, anyway. If that's the road that ends up getting taken, then I'd gladly load the Free-CD public key on all of my browsers on day 1.
Also keep in mind that this doesn't have to be massively successful in order to reap some gains. Even if it was mildly popular, it might entice Verisign and Thawte to drop their prices a bit in order to decrease the incentive to go with Free-CA.
Free SSL Certificates.. (Score:4, Insightful)
All that a Trusted CA issued certificate says to me is that the potential scammer had the money to buy an SSL certificate.
Re:Free SSL Certificates.. (Score:3, Informative)
SSL (the idea, not just the certificate) provides assurance of the identity of whom you are doing business with (among other things). If you want to buy something from www.amazon.com, SSL verifies that it is really www.amazon.com that you are dealing with and not someone else.
If www.evilcriminal.com buys an SSL certificate, and you do business with www.evilcriminal.com, why is it the fault of SSL that you chose poorly? This is similar to expecting PGP to verify who your friends are. It is not fault of SSL, nor is it a valid reason as to why SSL certificates should be free, if you choose to do business with an untrustworthy company.
Now, to truly have an open CA (there is a group trying - http://www.openca.org/) for signing SSL certificates would require a few things:
1. The CA would need to enforce the same level of identity verification that professional CAs do.
2. The CA would need to convince major browsers that it is credible enough to have its root certificate trusted by default. This usually requires an extensive (and very expensive) Certification and Accreditation (C&A) process to make sure the CA is up to par. The ones I have been involved with usually require an amazing amount of documentation demonstrating superb security, expert personnel, and reliable systems.
3. The CA would need funding for the resources (both human and otherwise) required to maintain it.
However, it still seems like an open CA like this would be possible. First, a highly-respected group of people from the community would need to head it up. They would need to be just as diligent and professional as the existing CAs. Then, though I doubt they would have the funding to undergo a C&A (much less pass one), perhaps Mozilla could add their root certificate to its trusted certificate store. Everyone else (users of IE, etc.) could manually trust this root certificate. Instructions could be provided on the CA's Web site for doing this.
Sure, many people would still receive warnings, but there are a lot of us who would be willing to do business with a site that is protected with an SSL certificate issued by this open CA. Some sites (www.thinkgeek.com) have an open source savvy target audience, so these types of sites would benefit the most.
Re:Free SSL Certificates.. (Score:2)
If the intended use is to verify Amazon (for instance) why do browsers NOT automatically alert you if the Certificate has changed since the last time you were on the site. (I don't care if it is from a valid authority, i care if it has CHANGED.)
Then I care if it is from a valid authority.
I've got it! (Score:5, Insightful)
Re:I've got it! (Score:2)
That's a good idea.
In terms of trust, I think that an even more fundamental level than $NAME, is $MONEY. The latter even gives you a variable measure of trustworthiness where the name is usually just a Boolean.
If any and every bank could tie an escrow account of some amount to guarantee identity to that level of funds, then maybe we'd get somewhere.
I'm not sure what monetary damages Verisign guarantees you if they've certified a fraud. Maybe someone in the know could enlighten me.
Re:I've got it! (Score:3, Insightful)
It's one of the few paths I can imagine to ubiquitous public keys. Of course the current (US) government is so anti-privacy that it's probably not a good idea right now.
I think the Post Office should run a public key system. It kind of fits, they need something electronic to do, and they have a good reputation when it comes to the important parts: they are non-political, provide a fair price, they provide ubiquitous service, there's already laws in place specifically protecting them from fraud, and they have the governmental connection to make those keys official.
No, thanks... (Score:2, Insightful)
Otherwise, you've got a model that says you've got One True Name, usable for everything, and anybody who steals your wallet or hacks your PC (Microsoft and wu-ftpd and sshd would NEVER have bugs!) now 0wnz you. The Social Security Number, with one number that gets used for everything, is a terrible idea, and guarantees that it's easy to correlate any two databases from any groups that have either been forced to use your SSN as a tax number or found it convenient as a "unique" identifier. Besides, then Californians who can speak Spanish wouldn't be allowed to have web sites, just as one of our previous governors decided they shouldn't be allowed to drive. No thanks.
Hype, Antihype (Score:2)
What happens when we do get them? You want the NSA to have a database of encryption keys on-hand? Kind of like that Trusted Authority that one notable polititian proposed should hold all your encryption keys for you. (Can't say his name, 'cause I got massively flamed last time I did.)
Re:I've got it! (Score:2)
In short, in absence of evidence to the contrary, it seems that the $5,000 toilet seat is just something that fucking idiots bring up when they want to accuse the government of being poorly run, but they're too lazy or stupid to find out where the actual problems lie.
huh? (Score:2)
Or does it just sound like it?
SSL authorities (Score:2, Funny)
-BM
Nice thought but... (Score:2, Interesting)
Re:Nice thought but... (Score:2, Insightful)
Why? Getting a phony SSL certificate even from the "big buys" (Verisign, Thawte, etc.) is a piece of cake if you don't mind lying or being unethical. It's not hard to give Verisign the documentation they want even if you dom't have it--as long as you don't mind lying or forging. Someone out to conduct some fraud isn't going to be bothered by this anyway.
If you really trust an SSL certificate--even those issued by Thawte or Verisign--as a key to automatically trust some website with no personal responsibility to make that judgement yourself, you're going to to get burned.
I've said it once and I'll say it again: Verisign and Thawte are NOT what cause my customers to trust me. They trust me because they know me. They trust me because they know people that have purchased from me. Some people (foolishly) trust a website just because it "looks" professional. But virtually no-one trusts a website just because it has a Versign or Thawte logo on it.
Let's put it this way: I had people submitting online orders with credit card information before I got SSL. I had absolutely no security and they trusted me--they even trusted the Internet itself with unencrypted data. Then, after some amount of hassle, I got an SSL certificate with Thawte. I noticed no increase in sales. After a year it was time to renew and Thawte gave me an entirely new bundle of requirements and documents that they wanted just to RENEW me. I said "screw that," cancelled my renewal, and am now happily with Comodo/InstantSSL.
There are many SSL certificate options out there, just like there are many domain registrars out there. And as is the case with domain names, only foolish people with too much money with their hands are staying with Verisign.
Anyone want to put any bets on when Verisign will go out of business? Their customers FLEE because of bad service and high prices, and yet they don't change. Amazing.
Just say no... (Score:5, Interesting)
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...
Re:Just say no... (Score:3, Interesting)
It could present the user with four different levels of increasingly dangerous dialogs:
Start out with something like "Microsoft wants to install a Service Pack Upgrade". Be sure to inlcude a radio button for "always trust Microsoft Corporation"
Next present a dialog that installs "gator"
Then, see if they'd like to host "Back Orfice" and "always trust the Cult of the Dead Cow"
Finally see if they'd like to install a suite of viruses, and email worms.
That way, you could gather and quantify levels of human stupidity. -- maybe even get a regional picture?
BTM
Re:Just say no... (Score:2, Funny)
If you're going for increasing levels of danger, shouldn't that be the last one?
Re:Just say no... (Score:2)
"Who is smarter, the average internet user or a lab rat?"
If you already know who you are dealing with .... (Score:3, Informative)
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.
PGP (Score:3, Insightful)
Zimmerman solved this whole problem over a decade ago. Think web, not hierarchy. You can emulate a hierarchy with it if you really want to.
Ri-i-i-i-ght (Score:4, Insightful)
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.
Re:Ri-i-i-i-ght (Score:2)
A bad match would throw a dialog up that says "this site's key xyz doesn't match its key abc registered at keyserver.org".
From what we've read about what Verisign does when handing out certs to begin with, a submit-your-own-key authority is at least as reliable as what they deliver. A submit-your-own authority could even charge and go through some of the same validity motions that Verisign does.
Re:Ri-i-i-i-ght (Score:2)
You have just described VeriSign, Thawte, and the rest. Except instead of checking each and every cert it only checks that the cert is signed by a trusted authority (ie VeriSign). To do this properly the browser should also fetch a list of revoked certificates. (but it dosen't, and it really diminishes the trust of the whole system.) Checking the cert signature is acutally less bandwidth intensive then checking a cert each and everytime you visit a SSL site.
Web of bosses (Score:2)
You have a job only if the HR department says you have a job. It doesn't matter how many of your coworkers think you work there, one group has the final say.
You're a student in a university only if the registar says you are. It doesn't matter how many other students or professors you can get to think you're a student, only the registar's decision matters.
Even in your own home network, you decide what's your hardware and who's allowed to access it.
I agree that hierarchial solutions don't work well once you start crossing borders, but that accounts for only a small part of the problem for most users and systems. The problems caused when attempting to force PKI to solve this problem are a small fraction of the problems caused by forcing a "web" solution to the far more common hierarchial situations.
Web of Trust? (Score:2)
I suppose that we could get a group of well known celeberties to create the first layer of certs from which everyone else would sign off of. But how would that be better then what we are using now.
Perhaps this is the one time when the government should issue certs just like any other form of offical ID.
Re:PGP (Score:2)
My standard rant about CAs (Score:5, Interesting)
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.
Can you trust Verisign? (Score:5, Interesting)
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..
Re:My standard rant about CAs (Score:2)
How would I know my HTTP connection wasn't hijacked?
Difficulties (Score:4, Interesting)
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...
Web of Trust, a la PGP? (Score:5, Interesting)
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.
Re:Web of Trust, a la PGP? (Score:2)
Then use already existing community. Like Slashdot :)
Seriously, ./ mechanism controling moderators can be used to sign certs of authors and moderators - just as a side effect of authoring and moderating activity.
You've got "Fair" and your cert is signed by one more signer. You've got "Unfair" and your cert marked bad by one more signer. Keep your balance as high as possoble if you want people to trust your cert!
Same way, just with lower rate of signature, can be used against authors - keep your Karma high and your cert will be trusted more.
More generally, that way can be used on many other forums and you can collect trusts from forum to forum using the same cert.
Let your Karma sign your cert!
I doubt it will happen.... (Score:2)
Re:I doubt it will happen.... (Score:2)
To give some level of encryption to the traffic from your webserver.
This is useful any time you don't want the data to be intercepted - not just for commercial reasons.
For instance I might use it to setup a web email reader on my home machine - using ssl nobody can in easily intercept my logon details, or the contents of my emails.
Self-signed and non-trusted CAs (Score:5, Interesting)
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.
Re:lawsuits (Score:2)
It's not your customer who will sue you, it's the random user who trusted your customer, got screwed, but wasn't able to track them down and sue them because the CA didn't verify the customer's identity sufficiently for the "screwee" to locate the site owner to serve process, issue subpoenas, and so on.
It's only a matter of time before Verisgn gets beat up that way, after which certs will get more expensive.
The way I see it, root CAs aren't telling you that you can trust the people whose certs they set up... they're just telling you that if you get screwed, you can find the site owner and set things straight, in court if necessary. That in itself should encourage the certified to behave in a more trustworth manner, but the bottom line is that CAs (theoretically) guarantee accountability.
Chain of trust (Score:5, Insightful)
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?
Scary Warnings (Score:2, Interesting)
Regardless whether it's a big known CA or not, people make mistakes, and a certificate signed by any CA still carries risk IMHO.
There is an entity we all trust - 127.0.0.1 (Score:3, Insightful)
Ummm, security reasons? (Score:5, Interesting)
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)
I'm impressed (Score:5, Funny)
Ladies and gentleman, a round of applause for the only Slashdot editor who reads Slashdot!
OSCA (Score:3, Interesting)
Decentralized public key infrastructure (Score:2)
A system could be developed that uses a more decentralized approach than X.509 does today. Just like PGP uses a web of trust system to validate other people's keys, the same could work for SSL Certs.
But the problem is that you need to "know" enough certificates to be able to trust a stranger. And the role that the Certificate Authorities play now is to serve as the neighborhood mom to tell you who else you can trust to get that info. The trouble is finding a cheap and feasible way to distribute trust.
Self-Signed Certs Don't Mean Much (Score:2, Insightful)
Some trusted authority must be able to (freely) offer certs with some type of identification.
But they do mean SOME things (Score:2)
Create own CA + install as trusted CA in browser (Score:5, Informative)
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.
Here's some Sourceforge projects for you (Score:4, Informative)
Re:Here's some Sourceforge projects for you (Score:2)
http://sourceforge.net/projects/xca/
http://sourceforge.net/projects/php-ca/
http://sourceforge.net/projects/stealthisca/
http://sourceforge.net/projects/mkcert/
Googlify it... (Score:4, Interesting)
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?
It's simple. (Score:3, Insightful)
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.
Don't we have it backwards? (Score:2)
Shouldn't the browsers accept any cert for an SSl connection and that the "norm" be that everyone self signs?
What am I missing?
chuck
Re:Don't we have it backwards? (Score:2, Informative)
Imagine a bad guy is your own network admin
and you are in corporate LAN...
He can spoof foo.com, so the configuration will be.
You "-" [Bad Guy sniffer]translates "-" foo.com
(posing as IP and foo.com for you)
||
\/
logs of your connections
No security at all
Re:Don't we have it backwards? (Score:3, Informative)
A spoofed IP can also be used as a man-in-the-middle attack. You can't protect against one without protecting against the other.
The real issue is that currently to get a certificate you have to be able to prove not only that the domain in question belongs to you, but that you have to prove your own identity. The latter process is what adds the cost, and is essentially unnecessary for most sites - okay, so it's a good idea for a bank site to be able to prove it is the same entity as the high-street bank with the same, but it's hardly an issue for briansbuffyforums.org.
In an ideal world you should get a free certificate in the name of "Owner of mydomain.com" with every domain you register, and only have to pay the extra for formal identity checks if that's actually relevant to your business.
--
Andrew Clover
mailto:and@doxdesk.com
http://www.doxdes
If you wanted to do it properly (Score:3, Insightful)
Please see Schneier (Score:2, Interesting)
http://www.counterpane.com/crypto-gram-9904.html [counterpane.com]
He goes into further detail in "Secrets and Lies," but the essential message is the same, need for a top-level authority basically debunks the notion.
This is evident in the legal mumbo-jumbo of the cert authorities and e-commerce in general. No one is selling non-repudiation with a certificate. The only way to achieve a truly legally-binding non-repudable(sp?) connection is to escrow it to a third-party. All the third party does is run the risks and shoulder the liability in case of a fraud. Thought this was straight crack the first time I looked at it, but my boss explained it very well, "encryption keys and trust chains have been broken."
Guess it would be nice to have a cheaper solution for matching certs to names, but I guess for me that is to self-sign the damn thing and tell my users to deal with it.
Would this idea work? (Score:5, Interesting)
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.
Thawte got this for persons (Score:2, Interesting)
"The Web of Trust is a unique, community-driven certification system based on face-to-face ID validation on a peer-to-peer basis. It's a "bottom-up" CA, compared to traditional "top-down" CA systems. You can be notarised, and then you in turn can act as a notary and certify the identity of your friends"
Use another trust model (Score:2, Interesting)
In the real world, you trust someone if enough "peers" that you trust trust that someone, and probably a bit less
Hey wait, that's PGP's model!
do it through usergroups (Score:2)
I floated the idea in the newsletter and providing a SSL certificate for free as part of membership was well received. To make this work, I need lots of other UUGs to join with UKUUG and share the cost of becoming a SSL signing authority, I would like to get the cost down to about $1/member.
Questions:
Please email me at: addw AT phcomp DOT co DOT uk
What matters is what is being certified (Score:3, Insightful)
And as we all know, even Verisign goofed on their efforts to confirm this for somebody who came in wanting an MS Cert.
The reason they cost too much is we're asking them, in many cases, to certify too much.
When it comes to SSL certs for a browser, all that we're really testing is that the web server we are talking to really is the one at domain foo.com and ip address a.b.c.d.
We never check to see if foo.com is really owned by Foo Industries. We can ask to see the certificate, and find out that it says that, but in practice this is never done.
We could have free certificates that certify that the holder, at the time of issue, controlled the domain foo.com, was able to get mail at postmaster@foo.com and at the time of issue, foo.com resolved to a.b.c.d. That would prevent man in the middle attacks on SSL that are done later, at web connection time.
However, they would not prevent MITM attacks done at the time of certification. ie. if I can spoof the DNS server of the certificate authority, I can convince it that I own yourbank.com, for example. Then later I can spoof yours, so that when you ask for yourbank.com, you get my evil machine, and my machine has a cert that confirms it is microsoft.com, and the golden lock appears.
To get around that, somebody has to verify that you own the domain with a means outside the internet. That's the part that's hard to figure out how to do for free. Ideas include certifying the caller ID (except anybody with a SIP phone can set that to whatever they want.)
There are some tricks you might be able to pull, like having the CA have secure connections to a wide array of distributed net entry points, or a secure connection to the root servers for the major TLDs it is certifying in.
All sounds harder to do for free.
What paying the big bucks for a cert gets you (Score:2)
You are buying off the need to provide more customer support when you pay for an SSL certificate which has a root signing cert already present in the popular browsers.
You are not buying authenticity of sites. We all remember Verisign being tricked [cert.org] into issuing Microsoft certificates to a poseur, right?
Free root cert (Score:5, Informative)
I use them to SSL enable my website at glasgownet.com [glasgownet.com] and any other stuff I need certs for.
Well worth it.
Er... (Score:3, Insightful)
If 90%+ of your users are going to get the warning "The security certificate was issued by a company you have chosen not to trust," you might as well be signing your own certificates. The whole point of having a certificate is that your users won't get that pop-up window when they go to buy something from your store.
Thanks for the info, but until CA Cert gets in the trusted list for IE, it's not worth it... even if it's free.
Grassrooted certificates (Score:2, Insightful)
Let's face it, there's no real security in third party validation anyway when hackers have regularly had certificates issued by third party certifiers in the names of legitimate companies (including microsoft). Transitive trust doesn't work beyond the inherent biometric authentication of vouching for those you know personally, period.
If anyone is interested in participating early, e-mail me at mbs(a)connetic.net
Matthew Strebe
verisign.. (Score:2, Interesting)
I'm not sure how you define trusted sources but I for one wouldn't rely on verisign to validate anything.
Free certs with domain registration (Score:2, Interesting)
All the registar has to do is bribe MS into including their root CA in the next daily IE patch.
Need to develop a web of trust (Score:3, Interesting)
The short and the long of it is - there is no reason to have a free cert organization. They aren't going to be added to the major browsers by default because they can't really certify identities without some form of energy expended, which requires money. Therefore there is little reason to go with an 'organization' or follow the current top-down approach since each site is going to have to be clicked-through by the user anyway, or directed to add that org's top-level cert to their browser manually. How many top level certs can current browsers handle efficiently?
This is essentially the same problem as host name resolution, and more currently spam. Rather than rely on a few large organizations to provide credentials, there should be in place a 'web of trust'. I trust certian individuals and companies. These individuals, companies, and I have PGP keys. These people I trust are on my first level of trust. If you trust me, the people I trust are on your second level of trust, and I am on your first level. I would have a list of people who trust me. If you don't know me, you can check my list of people who trust me, then check their lists and find out, within a few mS, how far away I am from your first level of trust. This is a doubly linked list, and every list is signed by the list owner, and verifiable (ie, I may say that MS trusts me, but you can check their list of people they trust and find out)
The potential for abuse is high, though, so a rating system is used. If you get burned by someone you can 'negatively' trust them. This effectively pushes them further away from the edges of your web of trust, and everyone who trusts them will become suspect, and less trusted.
Verisign can continue its cert program, and you can trust them at the first level and have the same benefits you get now by default in your browser.
It's the beginning of an idea, anyway. Lots of issues yet to be resolved, but a lot of them have been tested on peer-to-peer networks, and it could easily be applied to those networks to improve them as a test bed before writing an RFC and moving forward with it.
-Adam
How about the apache foundation? (Score:2, Interesting)
I've always thought some entity like the Apache foundation should get in the certificate business. They are already issuing the most Web server software, why not web site certificates as well.
A clarification (Score:4, Insightful)
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
Can anybody say... (Score:3, Insightful)
The root of the problem is the technology. (Score:5, Interesting)
TLS (SSL) does not need the ugly PKI technology to operate. SSL/TLS could very well use PGP keys [gnu.org]. 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".
alternatives from academic research - COCA (Score:2, Informative)
this seems like it's got some interesting technology behind it - definitely has a rigorous security model at its core.
Completely free SSL certs at FreeSSL.com. (Score:4, Informative)
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.
Resellers don't need business licenses (Score:5, Informative)
I never understood why encryption is tied to trust (Score:2, Interesting)
Re:I never understood why encryption is tied to tr (Score:3, Insightful)
The SSH protocol as defined by the IETF SECSH working group does pretty much what you ask of it. The major caveat to not using a certificate is that you can't be sure that the communication isn't being intercepted (man in the middle attack). However most (all?) implementations of the SSH protocol use a concept called "known hosts". The known hosts list is the public keys of the hosts you have previously connected to - most (all?) implementations store the name, and the IP addresses.
The known hosts allows you to ensure that on subsequent visits to the same site it is still the same as the one you agreed to trust the first time you connected.
There is no reason why a web browser couldn't implement the same thing. In fact it does when it is telling you that it can't validate the path of a certificate and asks if you want to trust the subject of the certificate.
For example OpenSSH asks a question like this on
the first connection to sourceforge.net:If I answer yes the public key of shell.sourceforge.net is recorded in my known hosts database.
This is assuming that you have made some effort (or don't care) to verify out of band that the fingerprint of the public key is what you expect. This is exactly the same as what you are expected to do when you get the dialog in your web browser that says the issuer of the certificate wasn't recognised.
The difference ? PKI Certificates attempt to tell you who you should trust by using Trust Anchors. If you want to simulate the PGP model, simply remove all the Trust Anchors from your browser and start from scratch.
Re:I never understood why encryption is tied to tr (Score:3, Insightful)
Minor wrongheadedness (Score:3, Informative)
I think you're thinking about SSL in slightly the wrong way. It's intended to guarantee that
1) The person you're talking to and who is talking to is precisely who they say they are
and
2) Nobody else is listening in to or interfering with the communication without the consent of either you or the other party.
Besides, it's widely known that proving oneself virtuous is an NP-complete problem, and therefore beyond the scope of SSL.
its in the model (Score:3, Interesting)
In this respect PGP model is way better. You can use your key to sign others.
SSL should not require CA (Score:4, Insightful)
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.
My thoughts - browsers and profit (Score:4, Informative)
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?
Re:Good idea (Score:3, Informative)
I can appreciate that companies might find value in the corporate levels certs which bestow a certain degree of authenticity but certainly not email certs.
Someone such as gnu.org, or another free software group such mozilla.org should set up a free server that dishes these things out on demand - sign up, wait for the confirmation email, click on the unique link and get your cert. It's certainly no less secure than what the likes of Verisign would sell you and it would dramatically increase the use of encrypted and signed email. This would be a good thing by any measure.
The incredible irony of this is, of course (Score:2)
The main problem with some things being "free" is just that - there ain't enough cash money to make the world go round. I have no problem paying Thawte or Verisign as they promise to get the job done; unlike Joe Gnu, who "might get around to that someday."
Realize this people: you need exchange of money to make things happen. You can't walk into a McDonalds and demand a free Big Mac in the name of freedom and all; it just don't work that way.
I might add that Slashdot calling for free certificate authorities while they pay-for certificate authorities are providing this site revenue!! Just think -- if it weren't for companies like Thawte running their banners, Slashdot would have been down the hole a long time ago -- bandwidth and server datacenters aren't free either, you know.
Re:The incredible irony of this is, of course (Score:3, Insightful)
Re:Non-commercial authorities / .EDU (Score:3, Interesting)
Most annoying.
-Mark