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.
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?
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.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
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?
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.
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.
[Connection closed by foreign host]
Its about the same as a dollar bill drawn in crayon.
Some trusted authority must be able to (freely) offer certs with some type of identification.
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
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.
You'd make the person show up, in person, with 100 points of ID including 2 primary documents and 3 secondary documents, and you'd take a picture and fingerprints before you handed over the keys. You think all that's going to cost $15? I think not, expect the price of a simple certificate to go up.
How we know is more important than what we know.
Certs cost money because they are trying to certify things like "This key belongs to real representatives of Microsoft corporation, which is really the incorporated company headquartered in Redmond, WA, etc. etc."
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.
Has it been over a year since you last donated to the Electronic Frontier Foundation
Grassrooted certificates are not a new idea (as discussed here). My company is planning to start a free certificate issuing authority funded by pop-under advertisements that will get it's root certificates registered with Microsoft when enough revenue has been collected to do so. The URL will be www.grassrooted.org.
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
aka Matthew at SlashNOT/!
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
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.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
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.
...ICANN?
What's this Submit thingy do?
No, I'm not trying to be funny - while it's convenient to have your browsers come with certs for cert authorities that your browers' authors trust, the real certificate authority that a PKI tool should support is keys signed by you, the reader. (That's different from self-signed keys, which are signed by you, the keyholder, though you the reader at 127.0.0.1 will presumably have a self-signed key.) If the browser's certificate checker tools can't handle a hierarchy, where you get to sign the members of the hierarchy and what they can do, they're deficient. That's not exactly the same as "being able to add CAs to your browser", though it's pretty close; you may have different preferences for how deep different parts of the tree can be. For instance, there are some organizations you'll trust to sign certs for subdomains of their domain name, but not to sign other sites, while there are other organizations you'll trust to sign almost anything (e.g. Visa if you only use Visa credit cards on line), and others you'll trust for email addresses in their domains (e.g. you'll trust FreeEMail.Example.Com certs for sending encrypted mail to FreeEMail.Example.Com accounts, but you won't trust them to tell you that georgewbush@FreeEMail.Example.Com is owned by any particular George W. Bush that you might know from other channels.)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
It's great that someone is handing out free certs, but CA Cert isn't trusted by Internet Explorer.
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.
Simpli - Your source for San Jose dedicated servers and colocation!
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.
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.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
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
Think Kerberos. The two parties don't really trust each other so they ask a key server they both trust to verify their identities. The whole point in encryption is secrecy of the channel key so you want to make shure this isn't snooped by anybody. The site uses certification to publish it's public key so you know where your random session key is being sent (no MITM poser) and keep trusting it.
Mi domando chi à il mandante di tutte le cazzate che faccio - Altan
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.
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.
Think chamber of commerce running this instead of Joe GNU. They already charge money for membership, know who their members are (and thus are superior to Verisign in most cases), and are generally trustworthy members of their community.
Entities with their root certificates in browsers giving away certificates that are able to sign anyone's key would of course defeat the whole system.