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?
It is a pain to go through these guys, especially when you can technically create your own. If there were one big central free place that monitored stuff it would work. But I guess it would have to be trusted like Verisign and the like presently are.
>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?
Doesnt Self-Regulating Authority == Monopoly?
Or does it just sound like it?
the reason that we're shelling out big time bucks for these SSL certificates is because the certificates come from a "trusted" source which in turn means that the people using the certificates (i.e. customers, etc.) feel more comfortable accepting said certificate. I personally would feel more comfortable making purchases online if I knew the SSL certificate was from a verified source and not just some certificate that some Joe Schmoe created.
"Facts are meaningless. You could use facts to prove anything that's even remotely true!" -- Homer Simpson
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.
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.
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...
more like celda
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.
for the very simple reason that I strongly doubt that anybody that has a root certificate which ships in IE/Netscape will sign your CA's key. If this is not done users will see the dreaded 'signer unknown' popup box which is pretty much a deal breaker if you are interested in setting up an eCommerce site (why would you need SSL otherwise?).
-- the cake is a lie
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
side business, as a way for them to make extra money? Verisign and RSA are big companies, and verisign sucks for sure. Thawte is from South Africa. But the EFF...
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?
Does anyone know a site that gives a good description of process you need to go through to get SSL working with Apache? Perhaps it contains a list of signing authorities, prices... etc? I am just looking for information... right now I use the Red Hat default config for https... but I want to understand it better....?
You don't even need to show a business certificate for domain controlled certs. The CA just sends the cert to an email address that will belong to the domain owner (admin contact, root@domain, etc..). Geotrust sells these types of certs and directnic resells them for even cheaper than Geotrust.
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.
What I'm suprised to see is that no one has created an "Open Source Certificate Authority." Sign keys for a nominal fee ($5, 50% donated to FSF, EFF or something), and get this key published in OpenSSL and Mozilla (IE might be harder to do). The idea is simple, but would you be willing to bother?
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.
I'm so used to mis-constructed (read self-signed, out of date, poorly named, etc) certificates that after a few moments of consideration, I usually just click "yes" to trust these things. Anyone out there who wants to start a backyard signing authority can just go for it. Just call your company FreeCert, put up some futzy web page and don't charge a cent. Freeloading certificate-junkies will come flowing to your website generating certificates. They can then put up weenie graphic-links back to your site as payment, and you can sponsor the crapped out server you've got with banner signs and t-shirts with "FreeCert Forever - They'll Never Take Our Freedom" sold online through the online shopping e-commerce solution you've whipped up. Choose life. Choose a sofa. Choose 1024-bit encryption. Choose a f$%#ng great motherboad with dual CPUs. Choose Linux. I chose not to choose linux. I chose something else...
-BM
http://melbournephilosophy.com/
This is slashdot after all so we need to find a way to bash the evil empire. Seriously though, the barrier for entry in the CA market are the browser makers, who hold the almigthy power to annoit this or that CA as trusted. What kind of checks the Redmond crew does to verify that Verisign is actually trustworthy is beyond me, but I would not be surprised if it involves some way that benefits the Bill Gates Foundation. It would probably not be beyond reason to get the Mozilla crew to push one something like a freeware CA, but with Mozilla owning so little of the market the point may be mute. So go ahead fellow zealots. Let's bash Bill for creating an oligopoly out of the CA market. The least they could do is make it a little less scary to users when a site presents a self signed certificate....
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.
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.
Actually, a certificate just prevents a message from popping up and saying "This is not encrypted" or "This is encrypted by a non-trusted authority", which--to the average user--sets off bells and whistles and makes them put their credit card away. It has nothing to do with trust, it has everything to do with the lack of warning.
The majority of people are morons who would be happy to whip out their credit card and trust that IStealCreditCardsforFun.com is a trusted authority, so long as something doesn't pop up and tell them otherwise.
-Sara
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.
I always thought the idea was to secure the transmission of data. If I hunt down foo.com on the web, I'm not really worried that their IP has been spoofed, I just don't want my transaction to be sniffed.
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
I work for an organisation that's active in the banking industry, for security (one of the many, many elements is that) we implement a world-class PKI. And trust me, it is really, really difficult to do it right. The software is in fact the easy part, it's the procedures that make all the difference. Remember the hacker who impersonated as a Microsoft employee and Verisigin didn't check on it (say what you will about MS, but their security dept discovered this, not Verisign...): just an example on how difficult it is to do it right. To implement security correctly you need a lot of work,so that the CA is really very, very certain he's indeed certifying the correct entity.
(you must be from Belgium :)
I would love to help develping a SSL Cert service
anyone needing help. a server, etc. contact me please.
Derek R. Meiresonne
derek (AT) etecc.com
www.eTecc.net
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.
Any discussion of certificate authority isn't complete without a review of Schneier's view on security certificates.
http://www.counterpane.com/crypto-gram-9904.html
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.
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
"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"
Since I work at a university, I always thought it would make sense for EDUCAUSE or whoever it is that administers the .edu domain to be a CA for machines within that realm.
.GOV domains, or similar groupings in other countries.
Kind of silly to be wasting limited money on commercial certs, when it should be possible for educational institutions to work something out between themselves.
The same should apply to
The trust model of X509 Cerifitates is fundamentally flawed, in that it does not mimic the trust model applied in "the real world", but an authoritarian one.
:)
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!
SLOGEN [ http://ungdomshus.nu : Sebastian cover music]
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
Comment removed based on user account deletion
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
http://freessl.com
is not necessarily a more secure web site. You do get less customers calling up because the SSL warning box popped up. i.e.
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 into issuing Microsoft certificates to a poseur, right?
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.
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/!
There are CA's that practice better identity proofing. Try www.digsigtrust.com. In addition to credit card and driver's license number check, authentication information is sent out of band.
Keep in mind, part of the cost of a cert goes to the cost of both physically and logically securing the root private key.
As someone who dose the majority of my shopping online, and as someone who ran a secure shopping site for a few years, I'm glad the certs aren't cheap. Still, a couple hundred bucks for a cert isn't that much, and you can write it off on your taxes as a cost of doing business. Look, if certs were "cheap" or self issued, who in their right mind would trust them? Having gone through the process, having had a bit of a hassle - they rejected my first submission of documents, it feels a little bit better when I click on a "secure" website. It's a fact that in business there HAVE to be some "barriers to entry". If anyone and their brother could set up a "secure" site for free then the whole thing would be a complete joke. Of course I still don't order anything from any site till I check it out...
Wasn't it Verisign's CA who gave out a cert to some guy claiming he was from microsoft giving him access to microsoft's vpn?
I'm not sure how you define trusted sources but I for one wouldn't rely on verisign to validate anything.
Some enterprising domain registar should start handing out free certs with domain registrations. It would be a good way to boost their domain registration business. If you trust the registar enough to handle your domain you should be able to trust them to handle your certificate too.
All the registar has to do is bribe MS into including their root CA in the next daily IE patch.
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
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 with modifying existing web browsers' dialog-boxes to make them less scary, and explain that an unknown root CA doesn't mean end of the world. Then a user could visit the free CA's site, decide if they can trust it, and add it to the configuration if desired.
Regardless whether it's a big known CA or not, people make mistakes, and a certificate signed by any CA still carries risk IMHO.
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.
Four fifths of all our troubles in this life would disappear if we would just sit down and keep still. -C. Coolidge
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
The problem with the "web" approach is that most interactions are strictly hierarchial, and the web approach does not work well in that situation.
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.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
The difference is that with a web, you can have more opportunities to find pathways, and you can assign a degree of trust to various "authorities" instead of it being an all-or-nothing thing.
I know, PGP is an elegant idea (and, btw, so is PKI).
But
Will this appeal to an average consumer ? Say, my grandma visits some website and browser says -
the current trust value is 77.5%
Yeah, right. Cool, but what's next ?
3.243F6A8885A308D313
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
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.
Build stuff. Stuff that walks, stuff that rolls, whatever.
http://www.outwar.com/page.php?x=267317
:)
Very interesting, to say the lease
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.
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.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
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.
Ok... So quantum computers aren't around yet. And everyone is saying, "So, until we get quantum computers..."
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.)
What's this Submit thingy do?
...ICANN?
What's this Submit thingy do?
Very informative!
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
From the story: 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?
Ken Thompson who we all know and love from UNIX lore has written Reflections on Trusting Trust which describes just this problem.
Imagine that you insert a backdoor into a compiler, so that everything the compiler compiles is trojaned. If the compiler detects that it is recompiling itself, it quietly reinserts the trojan code. The actual source code to the trojan might be wiped out, but as long as you are running infected binaries, it will keep popping up again and again.
From the paper: "First we compile the modified source with the normal C compiler to produce a bugged binary. We install this binary as the official C. We can now remove the bugs from the source of the compiler and the new binary will reinsert the bugs whenever it is compiled. Of course, the login command will remain bugged with no trace in source anywhere."
A very interesting read.
DNSSEC is vaporware. AFAIK It was never finished, much less deployed by Verisign or anyone else. Quoting Vixie:
... ...
"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"
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".
PGP's web of trust is a good idea but how do we go about setting up the first layer of trust. With PGP you can physically meet your party to exchange keys. But that isn't possible with an e-store.
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.
Slashdot, home of supporters of free software, free music, and free speech.Except for Moderators that disagree with you.
this seems like it's got some interesting technology behind it - definitely has a rigorous security model at its core.
A self-signed cert for http://www.example.com/ doesn't tell you that they're the same Example Inc. that makes those really cool ExampleWidgets, so you may not want to give them your credit card number without some more verification. But it does mean that they're the same http://www.example.com/ that you accepted a cert from last week, and that your encrypted mail to postmaster@example.com is going to the address postmaster on the same system that controls the web site.
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!
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.
Why can't SSL support encryption without a certificate? I mean, how often do you really look at the certificate details to "make sure the website is who it says it is"? The whole point of SSL for me is to reassure the customers that their credit card details aren't going to be intercepted in some way en route from their browser to my server - so why can't I just offer them encryption without having to go through the expense and rigmarole of getting a certificate?
That at the top of this very page is a giant banner ad for Thawte's certificate authority. Don't believe me? Here's the banner ad.
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.
how does this prove the character of those running the SSL server?
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.
25% Funny, 25% Insightful, 25% Informative, 25% Troll
I ran into this same problem a year ago, plus working in an academic environment, no one wants to pay for anything :) So I wrote an article about it for UNIX Review.
0 25 067917864/
http://www.unixreview.com/documents/s=1353/uni1
It's highly unlikely Verisign will ever get beaten up this way. In fact, it's nearly impossible.
The reason is economics. Setting up a fake web site is far too much effort to waste for the money a typical crook gets from small customer transactions before the whole thing is shut down. That's why fraud is largely a phenonema confined to sites like ebay, where all you have to do is compose what is little more than an html email.
Of course, that's the reason the whole "certificate" scheme works despite its obvious flaws. It isn't necessary, and in fact, is little other than a way for browser operators to shake down web sites.
The whole signing/certification process is a scam if you ask me, and twice clients of mine have been able to get CAs from Verisign without appropriate documetation to even prove the identities requested were legitimate. There is no uniform policy where a signed CA means anything as far as I can tell. It's basically a fee you pay to select politically-connected companies, to keep an intimidating dialogue box from popping up for users when they connect to your site in SSL mode. You pay some BS company for the false idea that somehow things are more secure when they aren't.
The only real security that's ever been useful on the Internet is the Fair Credit Billing Act of 1976 which protects consumers against charges to their credit cards (not debit cards!) for any unauthorized purchases. Everything else is trivial in comparison.
Why doesn't anyone question why almost all the browsers don't pull down and integrate the rejection list? Mozilla by default does not have an CRL's installed. Why not? Without the rejection lists, the certificates showing identity is USELESS! Right now I'm sure that my browser would still authenticate the fake MS cert simply because no one updates the CRLs. Until the CRLs are updated automaticly, we might as well not use SSL. Without CRLs every session is vunerable to the man in the middle attack.
Ahh, the fun of security.
The biggest problem with CA's right now, and why they cost so damn much is that they try to prove EVERYTHING about who you are (or more to the point, the identities behind your website). Addresses, company names, incorporation dates, etc. all fall into the vast black hole that is a certificate. But why? Why for every secure connection that you want to generate between a browser and a server do you need to prove that your company is at such and such an address and is run by Joe Hotschidt? What if the client doesn't care?
For example: My company has a secure server for employees that contains sensitive but not secret information. It's protected by username and password so we wanted a secure submission of this information. Enter https and the magic certificate. Employees don't care where the server is. They just want to know that nobody's going to get their password. And no way was the company going to pay to have a CA verify the site's authenticity; what was the point? So I had to set up our own CA and self-sign the certificate. But that then causes browser problems when a message pops up on users' machines saying "this is an unknown root authority blah, blah, blah". The complaints rolled in to which we had to respond "Just click O.K."
What needs to change isn't whether or not there are free CA's. What needs to change is the architecture of certificates themselves. We need to establish different classes of certificates whereby a site that only wants to generate a secure connection can self-sign without problem. A site that wants to establish its location in the community and the identity of its operators could go to a CA. A company that wants to verify that it is who it says it is and follows sound business practices could have its location and business identity established by CA and its reputation established through peer signing.
My solution, in an ideal world, would be to create a certificate environment where a minimum of these three certificate levels exist. Different identifying icons could be displayed in the status bar of a browser to represent each level. Perhaps provide one lock symbol for each level satisfied.
This still leaves a system open to abuse as people could conceivably create certificate identities for the sole purpose of peer signing a certificate to create the illusion of a solid reputation. A solution to this would be to add value-signing to certificates. Not only could you peer sign a certificate saying a company was bona-fide, you could also sign a certificate with "These guys are crooks, don't do business with them." Again, the problem of abuse arises. What about a malicious user that wishes to create a bad reputation for an organization (enemy, rival, competitor, etc.).
I would say that the best solution to both of those problems would be to add relative weight to the signature of a peer. For example: Older signatures would be assigned greater weight than newer ones; greater weight would be assigned to signatures with a higher numbers and percentages of 'bona-fides' than 'crooks'; signatures verified by a Root CA would be assigned a higher value than non-verified. Signing would be somewhat recursive (you would have to verify the signatures of the signatures of the signatures, etc.), but that is not unlike the current system when you get down to the level of workgroup level CA's. A formula could be put together with a points system that assigned certain points to certain signatures and the point system could be calculated dynamically.
There you have your security, identity establishment and legitimacy rolled all into one. Of course the purpose of all this is to get the certificate equivalent of a Better Business Bureau listing. But the key remains that a better method for managing certificates exists.
Now, I have considered that there are still ways to cheat the system, but I would ask the reader to keep in mind two things:
1. It's no worse than what's out there currently
2. Even if you develop a perfect system where a company's legitimacy and reputation can be irrefutably established, all it takes is one guy with no conscience, a floppy disk and access to a company's credit card database to make certificate signing incosequential.
Yeah, I figured someone else would come up with it too. So I typed as fast as I could. =) Just lucky timing on my part I suppose.
About evaluation schemes though: The system has to be self serving. It can't rely upon the user to do much of anything. Much less take the initiative to visit the authority website and 'vote'. Opposingly, the raw number of user approved certificates is absolutely useless. This is because:
All the raw number of downloads would tell us is how many idiots got trojaned. While effective at informing us about the security awareness of the average web user, it doesn't make for a good measure of trust.
I guess that's what we have to do here, is come up with a "trust quantifying feedback loop (for the internet)". You may all consider this prior art if some asshole tries to patent such an idea. And I hereby bequoth it to the public domain.
Remember: umount it before you fsck it.
freessl.com provides free ssl certificates. I use one on my site and you don't get the error saying its from an untrusted source. Pretty cool.
You don't need certificates to produce encrypted connections in SSL. This will as you say only stop passive packet sniffing though.
This is the problem with X.509 model. They have 2 different entities - certificates and certificate authorities. When you purchase certificate you could not use it to certify other entities, like people within your company. I think it is doene intentionally to keep revenue stream locked between selected few.
In this respect PGP model is way better. You can use your key to sign others.
Think about how spammers, and their grifting ilk, think.
Would clever manipulation allow individuals to create "well-known" identities at will? Something along the lines of how sites attempt to manipulate google rankings (with varying results).
Just a quick thought of caution....
There is nothing stopping anyone from creating/issuing their own certificates. However, the overwhelming majority of the browsers in existence only have 'built in' recognition for the current 'official' set of CA's. There is no way to mass-upgrade them that wouldnt involve the cooperation of other monopolies that have no incentive to do so (eg, MS).
Regardless of all that, SSL encryption is a semi-useless feature anyway, except for giving end-user clueless types a false sense of security. SSL protects your CC number (or whatever data) for the few microseconds it takes to transmit it from your browser to the server - it does nothing to protect it after the server emails it (usually unencrypted) to whoever has to process your order, and it sits in a (usually unencrypted) mailspool on some erver somewhere, or on some unsecure windows client machine in an Outlook Express folder somewhere. Either that, or it gets stored in some file or database, again usually unencrypted.
Even *without* SSL its a huge task to try and sniff some backbone connection somewhere and extract someones CC out of one transaction. The access and equipment required is cost prohibitive for the gain involved. From a potential crackers point of view, its far more productive to get access to the stored emailbox or database, with dozens or hundreds of card numbers, with much less expertise, access, and equipment. And instead of one CC #, you get many.
Picture a ship, with a thick, strong chain tied to a length of ordinary rope, which is then tied to the dock - SSL/HTTPS places an iron shield around the chain, and doesnt do anything to even make anyone aware of the rope, let alone do anything to protect it or strengthen it. Its protecting the LEAST likely avenue of interception for the information.
Go ahead and invent one...
1. Invent unthought-of revolutionary encryprion scheme
2. Patent it
3. Profit!
No ??? here, whoever does it makes an instant win. The only thing I can think of that could get close is quantum entagnement. Deliver the entangled random signal pair to the parties and upon observation it will become a good one-time password. Shame MITM can still preemt a party, proxy the communication and snoop the data...
Mi domando chi à il mandante di tutte le cazzate che faccio - Altan
You have been totally cheated. You actually don't need any of this. If you just get each user to load a Certificate Authority Public Certificate to there browser you could produce as many certificates a you wished, i.e you could change sites, issue user certificates, revoke old certificates. This is actually fairly easy. You have to give everyone the Certificate Authority Public Certificate and they need to import it into the browser.
In Mozilla
Edit->Preferences->Privacy & Security->Certificates->Manage Certificates->Authorities->Import
In Internet Explorer
Tools->Internet Options->Content->Certificates->Certifica te Authoritys->Import
I did this about 6 years ago for an intranet project I was working on. Look at
http://www.pseudonym.org/ssl/ssl_ca.html
This gives the details of doing it with openSSL
Huh? I think you've missed my point.
There's nothing wrong with the encryption mechanism SSL uses now.
All I want is to be able to unhook that from the "trust" side of the equation, so that my website can offer an encrypted data channel without me having to prove myself to some third-party self-appointed "authority".
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
The best solution would be for Goverments to start offering certificates. This would solve two problems.
* Legal juristiction over site.
* Verification of identity.
If the government recognizes the web site then it can verify it has a ligitimate legal entity in that country and in the case of fraud the countrys laws will have clear juristiction to prosecute the company.
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
Yeah, who's ready to wait in that line?!
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.
This is exactly how SSL certificates work. You seem to have gotten confused because there are some preloaded certifying authorities in most web browsers. You can add or remove any Certifying authority you wish, in the same way you can in PGP.
But I continue to *hope* Verisign takes a beating. :-)
Build stuff. Stuff that walks, stuff that rolls, whatever.
The root page which includes the above two recipes, among others: OpenSSL Certificate Cookbook
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.
Every town, county and state has a chamber of commerce. Let them offer certs to their members as a perk of membership. If you're running a business, it's worth joining the chamber most of the time anyway and it's cheaper than an SSL cert in most cases.
As a bonus, since they're in this to get membership fees and they already know who their members are, the actual work of verification drops.
Look up "man-in-the-middle attack". An encrypted channel is useless if it leads to a malicious third party, rather than the peer you had intended to talk to.
Unfortunately, for countries in the 3rd or even 2nd world, this would end up being just one more excuse to shake down a business or force them to take on a dumb cousin as an employee.
Not all governments are trustworthy and sometimes companies are online in an effort to evade their local rapacious government.
Well you can always make your own certs, then make a .reg file (Windows Guys) that puts you as a trusted root and distrubute that to your customers.
Another little tidbit:
Even so we trust Verisign as a root CA. But Verisign themselves do not even keep up with their own certs.
What do I mean. Go on do netsol.com (networksolutions a verisign company). In your browser settings shut of the old "untrustworthy" SSL 2.0 and leave on only SSL 3.0 and TLS 1.0.
Now click on account manger and guess what you can not connect. Now turn 2.0 back on.... now you can connect.
I think it is wonderful that you have to go back to the old SSL 2.0 to make a payment transaction on Verisign/NetworkSolutions.
Dave
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?
I was under the impression that Internet Explorer at least would accept a site's SSL certificate as valid if it's issuer has a valid (and verifiable) SSL certificate... basically meaning if you buy just one, you are in essence a CA, for whatever it's worth. So someone out there could, in theory, sign others certificates. But I wouldn't be too surprised with Microsoft owning VeriSign if, even if it works, there's some policy you agreed to saying you would never do such a terrible thing.
That behind me, my thonghts on DNSSEC. The main problem with DNSSEC is that DNS itself has no concept of security; any attempt to add signatures has the issue of having to graft on signatures to a system not designed to have signatures. For example:
-
A DNS packet can only be 512 bytes long; that really is not enough room to fit a signature.
-
How do you sign the statement "this host name does not exist"? All of the solutions have a problem. We either have to put a private key on an internet connected computer, or we have to reveal all of the host names that exist in our network.
-
Digital signatures add a good deal of workload to already overloaded recursive DNS servers.
The real solution is to replace DNS by something better. As I said before, and will say again, this something better needs real authentication, the ability to more have more finely tuned hostname delegation, no CNAME referrals, have NS and PTR referrals be done by IP instead of name, and so on. This next-generation protocol needs to be well-thought out; the original DNS is well known to be poorly designed because things like were not thought out and even a "this host name does not exist" reply is a hack with DNS.- Sam
The secret to enjoying Slashdot is to realize that it should not be taken too seriously.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
Just install the certs into your browser trusted cert repository/stunnel server directory/http server directory.
While you're there you might wish to remove any CAs which you don't recognize.
So far that works for me.
With the posters small group of 50 a self signed certs and/or self created CAs should work pretty well.
The only reason to buy a cert from those CAs is their CA cert is installed by default in most browsers, and so visitors don't get a popup dialog (or even worse get barred from entry). There is no other reason.
Such things are unnecessary (or even counter productive) for employees or members of private organizations - they get a cert issued by their organization.
Unfortunately that's a common misconception.
You should never trust people just because they have a cert from Verisign. ID cards, passports, driving licenses and birth certificates don't say how trustworthy you are.
CA certs just say, "CA says: Joe Smith is Joe Smith". I haven't seen public CAs who say "We gave this cert to Joe Smith because he is a good person".
All a lowlevel personal cert tells you is that someone has a valid email address.
The next level cert tells you that someone gave a valid credit card number.
The next level cert probably tells you that someone showed more ID and money to the CA and the CA thought the ID and money looked ok.
The next level cert might tell you that someone physically went to the CA's premises, presented some ID and good money to the CA, and maybe a bunch of other folks whom the CA knows also told the CA that someone really is that someone.
So far I have not seen a public CA that says that person is trustworthy, or bothers to find out if that person is trustworthy.
Note: Private CAs could be a different thing. Your company could choose to issue certain certs only to trusted people.
Furthermore even if a Public CA said someone was trustworthy, why should you automatically believe them? Have you yourself certified that Public CA for trustworthiness? If you haven't then you shouldn't trust them if they ever certify people for trustworthiness.
Well it doesn't matter as much, if they use credit cards.
:)
The risk is taken mainly by the merchants and/or the card company/bank (depending on the type of transaction).
Just say "No I didn't do that" and voila chargeback.
Of course if that happens too many times under suspicious circumstances you could get inconvenienced...
The risk is far higher if you use real cash, cheques or debit cards. Even if there are safeguards, it's YOUR money that's gone whilst the investigations proceed till you finally get your money back. Whereas with a credit card, it's the BANK+/MERCHANT's money that's gone, not yours. Guess how long they'll take to investigate that? Plus would it really matter to you?
of the story was that the guy asking didn't want to fork over "large amounts of cash". For your personal website that you want to protect from the NSA or god-knows whom cause you're a paranoid tinfoil-beanie type, $150 a year might seem like a lot of money, but a bank or an insurance is really not going to care.
Same thing as the hard-disk deleting policies mentioned yesterday: since noone truly cares about the amount of porn on your disks, you're fine just formatting them or zeroing them out a couple of times, cause the cost of having them shreddered would seem quite high.
You're also fine just tearing up your bank statements a couple of times instead of hiring someone to incinerate them.
Some ISP's make their own... Like zet.no (see cert author) They're a norwegian small isp, with a few hundred clients (mostly companies.).SO why not other could do this I wonder. What is wrong with making your own? At least it ensures that only the other end can read, not any sniffer, and at least for me it is the most important. Usually I don't think it is as easy to replace a entire site as to sniff. So for me it is most important to ensure that only 1st and 2nd part can read the message. However, I understand that some have a need for authentiacting that remote is the one it is claiming to be. But how many users would notice if it were zet.nu instead of zet.no? And how difficult would it be to replace the papers needed to get a VeriSign cert? Panaroid users could even request a mail (snail mail) with a floppy with the ssl pub cert on, so they could check! It would also not be a problem to enable something like the PGP keysigning, that sites sign each others certs. Then you, for example, would be pretty ensured that a site who had a cert signed by slashdot.org;) and Google you would be pretty ensured that it actually would bethe site it was claiming. I do not think it is right that you should pay for encryption. Encryption is a Human Right, it is a part of Freedom of speech, to be able to communicate without that 3rd part is reading!
Assembling etherkillers for fun an profit
www.evilcriminal.com, what a cool domain name - and up for grabs too. Gimme, gimme, gimme :-)
"but with Mozilla owning so little of the market the point may be mute. "
Points can never be "mute", as in unable to speak.
But they can be "moot" meaning technically correct but not mattering due to overriding circumstances.
Don't worry, I've worked with VP's of large companies that don't know the difference either. So Illiteracy is not an impediment to success....carry on.
I have recently had to get SSL certs for a couple of sites that i am admin to and decided to go with http://www.securessl.co.uk I did a check of the certs and they were just as accepted as the expensive Thawte/Verisign and the verification process is damn near identical. So more secure and excepted than FreeSSL/Entrust/Geotrust ETC. I know that this company is a reseller of InstantSSL but the staff were more efficent and friendlier with suppoer issues and the cost was the same so went for them. $49 for a year now that is a more realistic price for certs that are trusted and have a warranty which none of the other players offer.
similar thread in standards mailing list
http://www.garlic.com/~lynn/aepay10.htm#79/ /www.garlic.com/~lynn/aepay10.htm#81g arlic.com/~lynn/aepay10.htm#82. com/~lynn/aepay10.htm#83
m l#sslcert s
http://www.garlic.com/~lynn/aepay10.htm#78
http:
http://www.
http://www.garlic
whole collection of posts on the subject
http://www.garlic.com/~lynn/subpubkey.ht
I've allways though the post office would be the best option, they are known to be trust worth organisation and avoids the issue of political complications. After all stamps started as stamps off as an notary device of trust and authority.
The Apache Compile HOWTO gives a reliable process for building mod_ssl into Apache, including dependencies, creating a server cert, etc. It also contains references & links to more information. -ZK
It's typically refered to as 'self-signing', which normally happens when you first install your webserver.
And yes, it will complain that it's coming from an untrusted source, but it can be usefull for test boxes and intranets, where you have a limited number of people whom you can control accessing the system.
You gain the benefits of encryption, but because a certificate authority hasn't approved it, you'll get the 'untrusted' box popping up when people connect.
Build it, and they will come^Hplain.