hip2b2 asks:
"SSL over HTTP is becoming a very popular way of securing websites for eCommerce and other forms of secure transactions. A vital ingredient of a SSL protected website is an SSL certificate.
In the Philippines, most of the secure website here buy their certificates from Verisign.
Why should we trust a certification authority that is located in a different country and charges and arm and a leg for a certificate instead of a local one? I can pay 349USD for a Verisign or 125USD for one from Thawte, which is not cheap here. With an exchange rate of around 48.50PHP per USD, this amount is beyond the reach of most local sites who just want to setup secure sites to try out the technology or use it for some charitable purpose. How do we expect to promote the use of SSL in our websites locally with these prohibitive costs? This problem is not limited to the Philippines, I presume that other countries could also relate to this issue." Right now, the cost of an SSL certificate is one of the prices for doing business on the internet (in addition to bandwitdh costs), but what would it take to start up another company that issues CAs, especially if you want to do it outside of the US?
"Is it a question of trust? Do local ecommerce and secure sites trust verisign more that say a local company that provides secure certificates? What confuses me is why is there no proliferation of trusted local institutional CAs? In the future, Verisign might end up being another Network Solutions.
Oh wait! Network Solutions is a Verisign company!
What are the barriers for setting up local country CAs? Right now, I presume that browser makers are the ones listing the trusted root CAs on their browsers by default. If my university were to setup a root CA how would we get netscape and the other browser makers to recognize us? or is there some sort of governing body for assigning root CAs like ICANN is supposed to be for name resolution? or could this be one of ICANN's eventual functions?"
nationalism? (Score:1)
Simple introduction to certificates and CAs (Score:1)
There's a good older article that can be found on just this topic. I've done a lot of reading on this topic on the web, and it's one of the simplest introductions I've found. The article is called Introducing SSL and Certificates Using SSLeay [ultranet.com]. Just read through the first four sections. They talk about how certificates are used, what a Certificate Authority does, and how SSL works. It's good stuff.
SSL = encryption + verification of IDENTITY (Score:1)
The thing is, 99% of the people who want to use SSL could care less about establishing their identity or the location of their server. They just want to encrypt the data to prevent casual interception. Unfortunately for them, SSL won't allow web sites to have one (encryption) without the other (identity) without imposing its own penalty: scaring web site visitors and making them affirmatively agree to accept it as "untrusted". In all likelihood, most USERS wouldn't care about the identity aspect either... if browsers didn't make such a big deal about it and give less astute users the impression that they'd be safer submitting their info in the clear. Untrusted certs aren't less effective as encryption keys... they just have zero worth for establishing identity.
A reasonable compromise that could be deployed by the Powers that Be (Microsoft & Netscape) would be to create an explicit category of untrustworthy SSL certificates whose only worth was encryption alone, and tell users exactly that the first time they encounter such a cert, and make it easy for users to check the "never bother me about this again" button.
Within a few months, it would de-mystify such certs, and users would dismiss the first instance of such browser-generated notices the same way they dismiss the notice generated during the first instance of insecure and SSL form submits now.
Considering the deprecated state of Netscape today on every platform for which MSIE exists, Microsoft could probably even do something like this unilaterally, and make it retroactive to older versions of MSIE too using Windows Update [the same way ancient 3.x versions of MSIE can still have the newest JVM and Javascript]. What's in it for Microsoft? They could create an option to differentiate between insecure SSL certs created by Win2k Server and Everyone Else's (making the option to differentiate between them default to Windows Only). Underhanded? Probably. A worthwhile sacrifice for the sake of getting something like this into MSIE ASAP? Yeah.
Re:nationalism? (Score:2)
cost (Score:1)
In any case, it would be VERY nice to see more competition in this area, and get several more CAs authorized.
Open Source to the rescue? (Score:1)
Of course that could also lead to problems, where some browsers will recognize CA X and some won't.
Re:Open Source to the rescue? (Score:1)
Re:Open Source to the rescue? (Score:1)
of course, we're talking about somewhat clueful people here. Idiots might have some problems...
Re:Roll your own (complete instructions) (Score:3)
Yes, the insurance aspect of the big-time cert companies is nice, but more important for many businesses that do B2C ecommerce is that the "VeriSign" logo, like one from the Chamber of Commerce or Better Business Bureau, helps assure customers that there's a substantial business behind the Web site they see. But plenty of businesses do well without joining a CoC or the BBB (the best auto repair shop I've found locally belongs to neither, for instance), especially those that foster close personal relationships with customers.
I have never taken credit cards directly online for my limo business. I started it in pre-Internet days and still have the same old XON credit card terminal I got in the late 80s, and it still works fine. Customers either hand us their cards when they get in one of the limos or, if it's something like a business person whose company is paying or a celeb whose travel is being covered by a production company (which is how most celebrity transport is handled, BTW), a secretary or other admin person usually calls or faxes directly with the trip/charter information anyway and includes the credit card number and expiration date in that call or fax.
My limo partner and I are considering taking cards directly online before long. Small businesses (like ours) that don't have (*cough*) huge amounts of VC or IPO cash tend to be far more conservative than wing-ding companies because if we don't make a profit almost every single month we go broke. (The garage where we take our limos is *just now* thinking about putting up a Web site.)
But if I decide to take credit cards online, I am *not* going to fork over $200 or $300 or $400 for a third-party cert. I'll just put an ordering page -- one page -- on Joes's server and ride on *his* cert in return for a small fee, like maybe a six-pack or two.
- Robin
Re:Another use for php... (Score:1)
Re:Expensive is fine... (Score:2)
Not everythign on the internet is for making money.
Re:Pay for trust (Score:5)
The reason for having these expensive certs from these companies is that you are paying for that level of trust. If i was giving out certs for free there would be no reason at all to trust me. However having a big name like verisign as the provider of your cert is like wearing brand name cloths, its a status symbol and it brings with it a level of trust, which is very important for ecommerce sites to have.
Form what I've seen, it's not at all hard to get a bogus cert. You're basically paying for a rubber stamp. The primary reason certs are used is simply to convince the browser to open an ssl session without popping open 6 dialog boxes worth of FUD.
The certs themselves are simple enough to create (including a CA cert).
What is really needed is various levels of cert from self generated ones that simply allow encryped connections all the way up to one that represents careful auditing and controls to surely verify the identity of the server on the other end.
I notice that it costs a lot more to get a wildcard cert (*.my-domain) than a single one (www.my-domain) even though the level of verification is the same.
Limited Monopoly (Score:2)
But take a look at the costs again. It's $125/yr. for a Thawte certs (the drawback to a Thawte cert is that it doesn't work in older versions of Netscape and IE which make up less than 1% of browser usage). That's roughtly $10/mo. for a secure site which is not at all expensive. It's really not that prohibitive to setup an SSL site. Prior to the release of the RSA patent into the public domain, that was your primary cost (passed on through purchases of software like Stronghold), and that cost is now basically gone.
If I was a small business, I would gladly pay only $10/mo. for secure server capabilities.
Re:Limited Monopoly (Score:2)
I would venture to say that the 80-90% of the world's population that lives on less than 1 USD/day are not on the Internet, much less needing to run their own secure sites. Ten dollars/month equates out to roughly 33 US cents/day. If you're running a business on the Internet that can't get at least that much money/day for operating costs, I don't think the SSL certificate is going to be the issue about whether you're successful or not.
Taken out of context (Score:2)
The essay asks Ten Important Questions and attempts to explore each one with some depth. These are not necessarily obvious issues; you might not think of them unless you spent some serious time pondering the ramifications of Trusted Third Parties (TTP) and Public Key Infrastructures (PKI). If you read the essay and consider it carefully, you will realize that using PKI to realize a TTP electronically has some pitfalls and while these may be addressed, it is labor-intensive (read: not cheap).
A lot of the posts on this story have been predictably dismissive of the issues laid out in Schneier and Ellison's essay. Part of the reason for this attitude is that some of these issues seem contrived or academic until you are in a situation where there are serious consequences for getting them wrong.
To borrow an example from the field of US law, consider the case of Colin Ferguson. Ferguson shot and killed several commuters before being wrestled to the ground when he ran out of ammo. When the police arrived, the witnesses probably said,"This guy shot some people," not,"This guy allegedly shot some people!" The next day, millions of break-room conversations no doubt mentioned "The guy who shot all those people on the train," not,"The guy who allegedly shot all those people on the train."
Why shouldn't they? After all, barring supernatural circumstances, there wasn't really any doubt that Mr. Ferguson has commited the crimes of which he was accused, yet any attorney or responsible news organization would have carefully referred to Mr. Ferguson as "the alleged attacker" until the point at which he was found guilty. In the US, people are legally considered innocent until found guilty in a court of law, and people who are responsible for maintaining this system (lawyers, legislators, judges, and to some extent, the media) will (or should) assiduously use the term "alleged" until a conviction is obtained; in the case of Colin Ferguson, this detail seemed absurd, but like many of the "overblown" details of PKI, and TTP, there are important issues at stake (just wait until you are accused of a crime you didn't commit!).
Now that you are thinking about that, how would you feel about a witness affadavid(sp?) that was validated only with a digital signature, rather than in-person testimony. Nervous? You should be. (Don't panic, this would probably be a violation of your VIth Amendment right to face your accuser.)
It should be little wonder that the boilerplate "Certification Practice Statement" (CPS), that any Certificate Authority (CA) should have, was drafted by the American Bar Association (the professional assocation of American lawyers).
What the referenced essay was trying to do was not to trivialize or malign PKI, but the highlight the issues that ultimately make it expensive to do PKIs and TTPs correctly. Before you run out, download OpenSSL and start cutting some free certificates, you should really understand why paying US$1000 for the same cryptography might be worth the money when this is something valuable at stake.
Re:Root CA's (Score:2)
- I'm fairly sure that if you serve your root certificate with an appropriate Content-Type, and Netscape will happily import it after confirming with the user.
You are correct, but the real problem is steering Joe-Sixpack to that CA cert location. Typical end-users just aren't aware of them or used to downloading them. I addressed this in another post. [slashdot.org]Re:Open Source to the rescue? (Score:2)
- the first time a web page comes up that's signed by CA X, the browser says "Here are the details for CA X. Do you wish to install this key permanently so that you will not be warned about certs signed by this CA in the future?"
Yes, but where does this CA public key come from? All the browser knows, at that point, is that the server certificate has been signed by an unknown CA. The CA's public key is not part of the SSL handshake. How do you redirect the browser to find the CA certificate for that CA without allowing an attacker to steer the browser to a bogus cert?For example, the browser says,"This certificate has been signed by Verisign. Do you want to accept Verisign's CA certificate (from www.h4x0r.com)?
Re:Bootstrap Problem, dood ... (Score:2)
- If they have *no* CA's, how do they import any other ones? Without a cerver cert, any imposter could (say) dos the CA, and spoof their address.
You have both failed to understand how CA certs work and brilliantly highlighted a little-considered problem with PKI.You need at least one cert in the browser
The CA certs that are embedded in the browser have absolutely nothing to do with downloading new CA certs. The new CA certs are just that -- new CA certs.
The problem you highlight is this: how do I know that the CA cert that I'm downloading actually contains the public key for the CA I think it does? When your browser quietly loads an SSL page, you have to just assume that the CA certificates that installed in that browser are valid.
The accepted solution to this problem is to publish CA certificates so widely that subverting a single channel would be unlikely to result in a signficant number of people obtaining the fake CA cert. Furthermore, a human can verify the "Certificate FingerPrint" (an MD5 or SHA-1 hash of the cert). This Certificate Fingerprint should be so ubiquitous that a fake CA certificate should be immediately obvious.
Of course, this assumes that you, the recipient of the CA Cert make some effort (or any effort, for that matter), to verify the CA Cert. Have you verify any cert you've ever recieved? I'd be willing to be that most people reading this have never done so.
In summary, the bootstrap issue is a big deal, although you are mistaken that you need a CA cert in the browser to verify subsequent CA certs; they aren't related.
Re:Don't CA's cross-certificate each other? (Score:2)
- Very often, CA's certify each other.
No, they don't. You must be confusing one of two things.Sometimes a CA will sign the credentials of a subordinate CA. The new CA usually operates within a narrow context. When we have been talking about CA in this discussion, we have been talking about root CA's that are not certified by any other CA.
What I think you are talking about is cross-certification. Let's say that my company trust Verisign and your company trusts Thawte. If we want to work together, we can take the option of using the same CA, which means one of us has to go through the process of forming a new trust relationship. Instead, we can have a cross-certfied CA set up. This CA is endorsed (signed) by both Thawte and Verisign, meaning that my company will trust certs sign by the new CA and so will yours, although neither of us form a new trust relationship.
Even if you were correct, you still haven't solved the problem. Let's say I've got Verisign's root CA certificate signed by Thawte. How do I know it was really signed by Thawte? I need Thawte's root CA cert... and well, we're back at square 0.
Re:Open Source to the rescue? (Score:5)
- A CA will just have to convince the open source projects (possibly by donating money and/or servers and/or people contributing to the browser code) to get their cert in the default setup.
This is a Bad Thing(tm). By allowing an open-source project to include the CA's they want, I anticipate a veritable fuckload of weird CA certs embedded in Mozilla. (Maybe the Powers That Be on Mozilla or other OSS browsers will be hyperclued, but I, for one, don't want to take that risk.)Instead, OSS browsers should contain no CAs. Upon install, the browser may bring up instructions on how to find the most popular CA root certs. Then Joe Six-Pack will have to get them, or find himself constantly nagged on SSL sights. The upshot will be that the browser is not quitely trusting anyone, and Joe Six-Pack now has an awareness of CA certs and how to load them.
Re:SSL = encryption + verification of IDENTITY (Score:2)
Re:SSL Certificates for Distributed servers (Score:2)
It's also possible to buy "wildcard certificates", e.g., for "*.mydomain.com", but these are very expensive and not all browsers (or other SSL software) know about them.
Re:uh, not necessary (Score:2)
Re:What About Equifax? (Score:2)
Once I find a root CA that is trusted by most browsers, inexpensive, and is run by people I don't dislike so much, I'll certainly switch.
In the mean time, I'm reasonably happy with recommending Equifax to people who don't want to pay more money for Verisign/Thawte.
Re:NSA Backdoor to Verisign (Score:3)
You do not at any time in the registration process (or afterward) give your site's private server key to Verisign. You only send them your public key, and that is what they sign.
This is not a back door, because ANYONE connecting to your SSL'd server gets that very same public key.
If the NSA can break the public key crypto and use your public key to compute your private key, they certainly don't need (or want) Verisign involved in the process.
Re:Roll your own (complete instructions) (Score:2)
Re:rebuttal (Score:2)
2) It is up to the browser vendors to decide who has a trustworthy network and who doesn't. If you can't trust your browser vendor on security issues, who can you trust(another reason not to use IE)?
Re:Generate your own CA. (Score:2)
Re:The case for goverment controlled CAs (Score:2)
Re:The case for goverment controlled CAs (Score:2)
> (ideally international, thus UN) sponsored body which achieves thrustworthiness trough legal > backing.
> This anihilates the market and the situation of near-monopoly we presently face.
Only by going to a total monopoly system. And why do you make the assumption that governments are trustworthy? *I* certainly dont trust them.
> I mean, your passport is issued by the state and I'd venture to guess nobody even among the > most extreme libertarians would challenge that...
Sure I will. What gives governments the right to control my movements?
The situation may be bad now, but the solution you propose will only make it worse; who says SSL and the CA system is the final word in authorization/authentication? Why not let the market decide?
It's a question of perceived value (Score:2)
Let's say a large, trusted entity (like IBM, or a large bank) would start giving out certificates for little or no money. Many would be concerned that they won't do a good background check, or be vigilant for abuses of certificates when the customers aren't paying for it. Also, the customers would get the sense that 'just anybody' could get hold of a certificate, which would seem to cheapen its value in itself. Basic psychology, really (and this is a large part of the reason why a Weight Watcher program works - at least temporarily - whereas magazine diets don't).
Roll your own (complete instructions) (Score:2)
Why not become your own CA? If the user can't trust you, why are they visiting your site? (*) Complete instructions are here [pseudonym.org].
Sure, the browser asks the users to confirm (once only per browser per cert), but if you link from an unsecured splash page that tells them what to expect and how to react to it, they get over the shock just fine.
Expensive trust? Think of the RIAA: to artists, ``trust us because we can get you royalties''; to buyers, ``trust us because our stuff is legal [implication: and other people's stuff is at best second-rate]''. But it's similar to the one liner about big government: any organisation big enough to give you everything you want is also big enough to take everything you have.
(*) Note: IE ``the browser that reaches the places the other browsers miss'' has all manner of exciting ways to obliterate or export your precious data without warning you, and in some cases without you being aware that it happened. Oh, and it matters not whether this happens over an open link or through an SSL link sprinkled with with Thawte holy water. Where do you want your data to go today?
Trust and liability (Score:3)
Trust - These certs are often a stamp of approval when conducting electronic commerece, etc, that the connection is secure, and that the party is who they say they are.
The first part is fairly straightforward. If you are using SSL then the connection is encrypted, and very likely secure.
It is the second part that makes certificates expensive. The Certificate Authorities (CA's) require a certain amount of information from you upfront before they issue a certificate. This is then used whenever you certificate is used to verify that you are indeed the person who originally received the certificate.
There are varying levels of assurance for this process. Most people opt for the basic level of assurance, which requires some paperwork and verifiable contact information.
There are additional levels which in some cases require your physical presence, a notary public, and some other contraints which I cannot recall, however, these are not used to my knowledge.
So, the root of the problem is that of trust. And trust is not cheap, when accounting for processing, maintenance, liability, etc. I beleive there is also a fair amount of cost to be considered a 'trustworthy' CA by the big browset CO's. Like Internet Exploder and Nutscrape.
Mozilla... (Score:2)
But I suppose "might" isn't good for a business model... on the other hand, the Mozilla organisation would almost certainly be sympathetic to any company wanting help to bring down the cost of SSL certs.
Gerv
Re:Mozilla... (Score:2)
They were disabled on the Netscape branch by agreement between Netscape and mozilla.org as part of mozilla.org's commitment to safeguarding web standards. The fixed positioning code had a number of bugs which would have plagued web developers trying to use fixed positioning in years to come. It was thought better just to turn it off.
Gerv
Re:What About Equifax? (Score:2)
Obviously, I have a lasting impression of them that does not incline me to expect anything but a headache from them.
Have you had contact with them? Do you use them? Has the way they do business changed to the point where I could reassess them favorably?
--
Re:What About Equifax? (Score:5)
--
Re:Pay for trust (Score:2)
You are buying trust, and liability... if Verisign's infrastructure fails then they are liable for any damage to their customer's trust infrastructure. It may be that Verisign isn't setup for catastropic failure (do the research yourself). You need to see their contracts specify liability and how much, and who pays and who is backing them. Who provides their insurance? What does that policy cover? What's their PKI policy, how is this ENsured? How is that procedure audited?
This is why you pay.
Re:Mozilla/Konqueror should include a 'Free' SSL C (Score:2)
And what would Verisign be forwarding, exactly? They never see the private key.
--
Contradiction (Score:2)
Great, when my credit card number is stolen we can track down the trouble to an ISP that can just say "Sorrry, common carrier".
That's what really irks me about certificates. There is no gaurantee of trust whatsoever as far as I'm concerned, and it's just extortion at this point.
What does a certificate buy you? As a consumer, ALL I care about is that my communication is secured. Even if a company has (or seems to have) a certificate from a valid CA there is still NO WAY I am going to trust them with my credit card number until they have a reputation. What really needs to happen is a seperation of encryption and identification which are all wrapped in the same bundle right now.
I think all sites should just start generating thier own certificates. All it would take is a few big sites like Amazon to switch away from Verisign and the root CA's would be finished. The message you get isn't even all that bad, it looks so much like the message you normally see most people would just click right through it.
Re:Contradiction (Score:2)
Again, I say - how useful is that! Am I supposed to be comforted that an SSL has granted authority to someone they absolutley know to a copany that in turn has granted authority to someone who has signed up over the web? Are all ISP's offering such survaces really looking into customer with the same depth the CA's supposedly are? Are all of the "trusted" CA's looking at customers with the same level of depth as Verisign?
But forget that point which I consider only a small issue. As a consumer, have you HONESTLY ever looked up a certificate from any online source to verfiy they are who they say they are? Do you think it would really come in handy if you had a problem? I don't think so, and on that basis I don't see where having a site get a certificate from a CA is any better than just making up one of thier own.
Re:Contradiction (Score:2)
As for your time being too valuable to spend checking on a merchant, I suppose you'd just sumbit your credit card number anywhere with SSL encryption. That's your choice, but as for me I tend to only use sites I trust. Does owning a certificate imply that they hold all your CC data in a secure location and not on the web server in a text file? Does owning a certificate imply that they don't have a CEO who plans to move to Brazil next month for the rest of his life, taking your CC with him?
I frankly don't have the time to worry about these things either, so I tend to shop at well known locations online. If there are two sites offering a DVD for sale and one of the sites is $5 less, if it looks seedy or too unknown I'll pass it by and spend a little more. In no way is mere ownership of a certificate any indication they deserve my trust, nor is it (or should it be) for most people. Since in the end the certificate can say nothing of any realy value to a consumer, why use it?
For the cost, why do you assume that every site online that uses a certificate will want to have a credit card setup as well? Then the $125 (with no other cost to be had) might not be so negligable. Imagine a site where you can post anon feedback/tips about a company or organization. Imagine an online game site that just wants to make sure moves are transmitted without fear of interception. I can think of a lot of uses where SSL is going to be used for it's only real function, encryption of communication.
But even if the cost is negligable to someone, does not mean it's useful. If I stood on the corner by a business you owned and said you'd have to give my a dollar a week or I'd tell passers-by that your shop wasn't to be trusted, that cost would be negligible as well. You wouldn't want to pay it, would you? I'm against using a CA on principal, that it is wrong and misleading to consumers by promising more than it can deliver. The cost is negligible to merchants but incalcuable to consumers, and it's time someone exposed CA's for the sham they are. Unfortunatley, I'm sure it will take years to rid ourselves of them.
Re:VeriSign Price (Score:2)
Because they can, it's as simple as that...
Re:Why do we need "certificates"? (Score:3)
Your web browser currently ships with two (maybe more?) hard-coded keys: Verisign's and Thawte's. These keys are used to securely transfer the host keys of secure web sites you connect to.
I think each country needs its own CA, and I think browsers should ship with keys for all of those CAs. But it's really up to the browser vendors (by that I mean Microsoft, realistically).
* I know this doesn't often happen in the real world, but it should. You never know if your SSH connection is being relayed through another host unless you can verify the authenticity of the host key.
Re:cost (Score:2)
The real reason they can do this is because they have a monopoly.
Re:Trust and liability (Score:2)
It has nothing to do with background checks or proving who you are. They just rely on Dunn & Bradstreet anyway. It's all about the monopoly and collusion.
Re:cost (Score:2)
Anyhow you failed to address any of my points.
Re:Trust and liability (Score:2)
Go back and re-read the thread. This has nothing to do with what I am saying. It should not matter weather my servers are in the same domain, a different domain, a different IP, visible to the outside world or not. The purpose of a certificate is to assure somebody that I am who I say I am. Once verisign or thawte has done that they have no business charging me for every server or IP address I have. I can maybe accept a nominal fee per key to pay for the microsecond of computer time it takes to generate one but they are simply ripping off people by charging per server and per IP.
I have one business, one billing address, one president, one CEO, one listing with Dunn and Bradstreet, one corporate licence. I have about a dozen domain names, a hand full of IP addresses, and a buttload of virtual servers. I should be able to apply the same key on all of them if I want to. All my customers care about is that somebody checked me out.
This has nothing to do with information it has to do with abuse of a monopoly.
Legitimate Business (Score:3)
The use of the word "legitimate" in this case refers to the identity of the organization who have recieved the certificate. Verisign has gone to some length to verify that the certificate has been issued to the correct organization. So sure, Versign will ensure that the certificat they issue to Visa is actually being isued to Visa and not some Joe Scamartist looking to fish for credit card accounts.
But once again - this does not mean the business in question has legitimate business practices. Just because the Verisign certificate was issued to Joe's Imports, it doesn't guarantee that Joe's Imports will really honor the order for a PS2 I just placed and paid for with my credit card.
It might be worthwhile to point out that Verisign DOES support an ADDITIONAL program called WebTrust ( http://www.aicpa.org/webtrust/index.htm [aicpa.org]). This seems to be a further step to linking a legitimate identity to a legitimate business practice.
Re:rebuttal (Score:2)
For all the customer knows, the "Vendor Company" CA could actually be run by a malicious hacker trying to eavesdrop on his communications with your site. > when was the last time those who did know check the validity of a cert or the company that issued it?
A long time ago... Indeed, most of the times, the browser does it for me. However, it can only do this automatically if the cert is signed by a CA recognized by the browser.
> No thank you I would rather create, monitor, and control our own certs in house, and ensure that our information is to be used by our company solely.
This is ok as long as you only care about in-house communication, but what if you sell to outside consumers who have no way of doublechecking your certificates? First they'd somehow need to get your public key, or a fingerprint of it via a secure channel (telephone? postal mail? Neither is 100% secure), which would cost you lots of processing costs.
Next, if you're really so worried about whether Verisign and Trust-E are able to guarantee the security of their infrastructure, why should your customer believe that you are able to properly secure your private key?
There are some situations where you don't need to bother with CA-signed certificates:
- In-house use: install your own CA certificate in all user's browsers
- Customers with whom you deal in meatspace: hand them floppy disks with your certificate or public key, or hand them cards with your certificate fingerprint
- You just want to stop the casual eavesdropper, but are not concerned about sophisticated man-in-the-middle attacks
However, in the general case of e-commerce with customers that you never met physically, and where you care about security, certificates are indeed very useful.Re:Open Source to the rescue? (Score:2)
Errm, wouldn't it be more appropriate if the CA convinced the projects by showing that it takes its job seriously? Does the do reliable identity checks, or does it hand certificates out (in any name) to anybody who pays the fee? Is its network secure, or is its private CA key available to any 'leet script kiddie off the street? Just watching the size of the bribe^H^H^H^H^Hdonation seems to be awfully dangerous to me...
Btw, what do the current browsers companies do? Do they just make sure the payment is in, or do they also consider who the CA is? I'd date to hope it's the latter...
Don't CA's cross-certificate each other? (Score:2)
Very often, CA's certify each other. So Thawte could for example certify Verisign's certificate or vice-versa. That way, you'd only need one of them installed on bootstrap, whereas the other could be loaded dynamically in a 100% secure fashion.
Re:What About Equifax? (Score:2)
Installing a new CA root certificate in your browser should be a concious choice. By doing so, you say that you trust the CA to properly verify the identities of parties to whom it grants identity certificates, that it appropriately manages its own security, and that it doesn't lightly delegate its CA authority to untrusted parties. There are some doubts [slashdot.org] about this last point, as it seems.
If your browser now doesn't warn you about potential security breaches caused by Equifax' carelessness, this doesn't mean that your browser is no more secure than IE, it just means that you, the user made a bad judgment by including Equifax's CA certificate in it.
Re:Don't CA's cross-certificate each other? (Score:2)
Wouldn't that actually be a very dangerous thing to do for Thawte and Verisign? As far as I know, CA certificates (i.e. certificates granting the right to operate a CA) have no "scoping" information (such as *.yourcorp.com), only a maximal chain length (meaning that can make sure that your CA doesn't cross-certificate yet another CA). As there is no scoping, your "private" CA would be allowed to certify just about any site, not just the ones under your jurisdiction. And because of the cross-certificate, any browser trusting Thawte or Verisign would trust your CA too! Given how dangerous this is, I doubt that Thawte or Verisign ever would do that.
Rumors are that Equifax hands out these cross-certificates rather easily [slashdot.org]. Interestingly enough, Thawte's cross certificate for Equifax has a chain-length of 1, meaning that a browser trusting Thawte also trusts any identity certificates directly issued by Equifax but (fortunately) not certificates issued by CA's cross-certified by Equifax...
Re:The SSL scam (Score:3)
While it costs almost nothing to make the certificate per se, checking the identity of the requestor, and maintaining the security of your certificate DB and CA private keys does have a cost. And what happens if somehow somebody tricks the CA into issuing him a fraudulent certificate which will then be used for hacking? Would the CA be liable for damages? Does it have to take out an insurance to cover these kinds of risks? What is the price of this insurance?
Re:What About Equifax? (Score:3)
What About Equifax? (Score:3)
Mozilla/Konqueror should include a 'Free' SSL CA (Score:2)
Personally, i don't give a rats ass about the 'Certification' aspect, i just want to be able to secure my web traffic in a user-friendly way.
It'll all be fun and games till we find out that Verisign promptly sends every key registered with them to the NSA for monitoring.
Re:It's a question of perceived value (Score:2)
All your event [openschedule.org] are belong to us.
Re:What About Equifax? (Score:2)
Only useful if the company backs it up (Score:2)
Re:What About Equifax? (Score:4)
Equifax marked my cert as suitable for use as a CA. Fortunately Thawte set the maximum chain length to one so I can't actually sign other certs. If they hadn't done this I would be able to set up my own CA, and the browsers would give it the same trust they give Thawte. Scary.
I found Equifax fine for customer service. Installing the cert was a bit of a nuisance because there was an extra step in the chain compared to a Thawte or Verisign cert. However once that was overcome everything worked fine.
Re:So do HTTP/SSL *just* *like* we do secure shell (Score:2)
At least with a CA, you have someone certifing that "Certificate X is real", an dyou can verif that signature. So a man in th emiddle would need to get his bogus cert signed by verisign (or another trusted ca) - good luck on that.
Should just make a "web of trust" style system. Have sysadmins from ISPs and web hosters sign eachothers keys, and sign the keys of the peopel they host for etc...and build a big web.
hmmm its an idea anyway
-Steve
Re:Same Here (Score:2)
From the point of view of a customer, having a trusted third party to verify a web site's identity can help you know that a web site is probably who they claim that they are.... If people started scamming IDs with thawte or verisign ID,s it would break the trust that people have in thawte/verisign Certs -- that would lessen the value of getting thawte/verisign certs -- and browser builders (Netscape, MS, Mozilla, etc.) might stop putting their public root cert in their default cert list.
If all you're doing is talking to yourself, and people who know you personally, you can give them a copy of a floppy/CD with your root cert on it and they (you) can install it on the remote machine.
If you then generate your cite cert, and then remove the private key of the root cert from the machine then -- barring a breakin where your root private gets stolen/coppied, you have some physical certainty that your key is not compromised.
This, of course, requires that your machine remain otherwise secure.
----
I use my own, private cert, on my personal web site. I trust it completely. If I was going to be doing sensitive work remotely, I'd use it in preference to a thawte or verisign key -- however, I'd personally install the (my) root cert on my remote machine(s).
--
install-certs.exe and email forwards (Score:2)
Does it require people to manually update their master certificates? This usually doesn't go down too well with joe-sixpack.
Then provide an "installer" program to update the certs. If Joe Sixpack will run elfbowl.exe or sextris.exe, then he'll probably run install-certs.exe. And if you play some cheesy animation [planetstarsiege.com] while the certs are being updated, this program will spread just as fast as elfbowl.
All your hallucinogen [pineight.com] are belong to us.
Trust is not about social status (Score:2)
Interesting problem... (Score:2)
Good point. Not that I don't trust verisign, but why would I trust some relatively unknown certificate provider in the Philippines?
I think it would be wrong to try to convince browser makers to add every kind of certificate authority by default. Instead, you should team up with the major ISP's in the Philippines (and ideally the government) to create a local one.
Now, why do you need the support of ISP's? Well, because (at least this is the case in my country, it might not be true in the Philippines) most users get a disk from their ISP when they sign up, and generally keep on using that software without bothering to download updated versions of the software over the net. These disks could add local modifications, such as adding the local certificate provider among the trusted authorities. This would most likely make 90% of the users happy, and the rest should probably be technical enough to understand how to add an additional authority themselves.
Ok, perhaps less than ideal, but I think it would solve the Philippine problem. If your site deals with international customers, you would probably have to resign to an expensive verisign certificate, or accept loss of customers due to confusion or mistrust. But from my understanding, the problem was mostly relating to Philippine websites targeting Philippine users. Case closed.
VeriSign (Score:2)
I don't know specifically about SSL, but I know when it came to buying something else from VeriSign, it was *cheaper* to go through a VeriSign affiliate than it was through VeriSign. It doesn't make a whole heck of a lot of sense, but companies that resell VeriSign products sell for less than VeriSign.
Go figure.
Re:Why do we need "certificates"? (Score:2)
Silly me... I always thought it was their massive installed base of merchants that made these names valuable to consumers. Just goes to show how little I knew.
How To Set Prices... (Score:3)
So with that little marketing gem in the back of your head, go poke around the web and view the certificates for every SSL site you come to. Since I bought a cert last summer, I've taken a peek here and there, and the vast majority of sites with SSL certs are using Verisign, with a minimum price of $349.
The conventional marketing wisdom of pricing, Thawte is a give-away at $125. Verisign acquired Thawte some time ago, and they still haven't raised Thawte's long-standing price that's about 1/3rd of when Verisign charges. Since I use Thawte, I hope they don't raise the price... though it would probably be a good business decision, absent of other considerations (they're probably smarter than most monopolies and know they'd be acused of monopoly pricing).
Now these slashdot threads often are all sorts of comments about what's "right", when "should" and what "ought" to be. I'm sure a number of slashdot regulars reading this post will feel it's morally wrong... but before flaming, remember that setting prices is about Marketing. If some marketing guy came to me and starting spouting off about how to write code and design circuitry, he'd be just as far outside his area as I'd be (an engineer) trying to tell marketing experts that a price "ought" to be low because some small customers in other countries can't afford a cert (or at least will complain about the price).
Are the Thawte/Verisign prices a "rip-off"? Even if the product costs absolutely nothing (which isn't the case here), a good metric for pricing is what the market will accept. Thawte did quite well offering a lower cost alternative, but the truth is that they didn't overtake Verisign offering the same product at 1/3rd the price, so for most customers the price certainly isn't too high.
There was a brief time when I wasn't happy about having to pay $125. Maybe I even felt is was a "rip-off" for a while. The truth though, in the larger picture, is that even Verisign's price, at nearly three times when Thawte charges, isn't a big deal to most customers. It would be a very bad business decision to lower the price based on whining from a tiny fraction of the potential customer base.
It's the browser, stupid (Score:3)
Re:Root CA's (Score:2)
Really? I'm fairly sure that if you serve your root certificate with an appropriate Content-Type, and Netscape will happily import it after confirming with the user. You can check Netscape's MIME mappings (in the preferences under "Applications") to see the handler and MIME type. I'd be rather surprised if Internet Explorer doesn't also support this.
Screw the signing. (Score:2)
My school [lakeheadu.ca] runs a mail server [lakeheadu.ca] running debian, and they've signed their own cert. We don't give a crap that verisign hasn't signed it. All we care is that it _is_ secure.
We'll probably get around to changing the date soon.
---
FreeCert (Score:5)
Another use for php... (Score:2)
and what are the units? functions? lines of code? files?
Re:Pay for trust (Score:2)
That might be true for US companies. From Europe, all it takes to get a Global Id, is a phone number where Verisign calls back and verifies that the other side knows about the Global Id application.
And the real bummer is, they don't even require that the phone number is at the actual company the certificate is for. In our consulting company, we ordered many certificates for our clients and "verified" these certificate applications by being the point of contact for Verisign. And we were open about this against Verisign - we didn't make up a fake identity that we were actually our client.
Some of our clients do online banking. Needless to say, we regularily [sp?] point out to our client's management that these Verisign certificates are not worth a penny from the point of security. OTOH, as one needs a CA where the respective root certificate is already in the end user's browser, there is no possibility to use other certificates.
And, to be honest, from a risk management point of view, it's not so problematic. The damages that may occur by some imposter (who also would have to fake DNS on the Internet and/or hijack TCP/IP connections at a grand scale, btw) are not high enough to let the business opportunity slip away. It all boils down to the fact that there is no 100% security. You have to look at the risks, the damages that may occur, analyze them and decide if your're going to use this technology nevertheless. And for most B-to-C business, it's good enough.
Now, for B-to-B business, that's an other story because the sums involved are much higher and one usually doesn't have a money limit on the transfers.
Open CA. (Score:2)
I think no one has really complained about the price of a cert much because businesses mostly use this type of service, and for a business $125/year isn't that much. But what about individuals buying certs to secure private information - seems reasonable if you can get the cost below $40/year. There is a market here. I bet it's only a matter of time before someone starts to offer a lower priced solution.
I run a discount web hosting and web design company, and I think a lot of our customers would be interested in having some type of secure cert if the price wasn't above $40/year. Right now we just resale the use of our cert because the price is too high for them to get thier own. Something to think about anyway.
Re:Expensive is relative (Score:2)
Re:An open authority may be a solution (Score:2)
No, it shouldn't. But in reality, it does. Most people tend to things that are nice/clean looking over something that's been cut and pasted together. That's why marketing is everything. And good marketing comes from good image making. And you need money to make a good image.
Re:uh, not necessary (Score:2)
Re:VeriSign Price (Score:2)
Re:Alternatives... (Score:2)
Alternatives... (Score:2)
I hope you can use it!
Re:The case for goverment controlled CAs (Score:2)
Re:Why do we need "certificates"? (Score:3)
As to startig your own CA, i quote from Webopedia [internet.com]
The role of the CA in this process is to guarantee that the individual granted the unique certificate is, in fact, who he or she claims to be. Usually, this means that the CA has an arrangement with a financial institution, such as a credit card company, which provides it with information to confirm an individual's claimed identity
So, you have to have money and connections, but it is possable to start one, even outside the US, as proved by this artical [internet.com] that talks about a CA in asia. Again with references to close ties with financial institutions.
Maybe there is hope, but it seams a pretty slim chance that just anybody can come up with code for encryption and then start selling them...
Re:VeriSign Price (Score:2)
It's called price discrimination. Take in more revenue by creating cost-neutral differentiations in your product line that will sort out your clients based on their willingness to pay.
It's the same thing used by airlines when they requre a Saturday-night stay for discount fares. Perfectly acceptable business practice, in the absence of a monopoly (in which case the mildest of things can become abhorrent).
Re:non ecommerce uses (Score:2)
Read your browser's documentation to learn how to import your home-perm-kit CA's cert into the browser. Presto, no more warnings.
I don't understand what you're getting at here, but there's no difference between using one computer to create the certificate, and using two.
Re:SSL Certificates for Distributed servers (Score:2)
This is for public use? Install a single SSL-enabled reverse proxy in front of your servers. Use a URL scheme that allows you to split the traffic as necessary.
Or, if it's for internal use, under no circumstances should you buy a certificate. There's absolutely no point.
Re:Pay for trust (Score:3)
Yet, Thawte, which Verisign owns, has no such requirements. You can get a certificate from them that works just as well, for much less money.
Last time I applied for one, the only documentation they needed was a faxed copy of the Secretary of State's acknowledge of receipt of incorporation papers, and maybe an old phone bill or something.
Re:Monopoly Market (Score:2)
--
Re:Am I missing something here ... (Score:2)
Companies need to charge something to pay for the necessary checks to ensure you are who you say you are and also to handle revokations, etc. But $125/year seems kinda high, especially when you often need more than one certifictae to properly secure multiple services.
--
Network Solutions becoming like MS? (Score:2)
There should be different country "verisign" type SSL cert. providers, just in case of different currency interests. Nationalism is a slight concern here, as when currency is involved, most countrys like to deal with that "inside"
That's just mho tho
rebuttal (Score:3)
You should read the article... Think about the CA business really good for a second.
CA sells certificates to ensure your data is encrypted between client and server. You, yourself as a vendor can create your own certificate which costs nothing. Now... do you know entirely that the CA company is entirely secure, simply because they claim to be?
Things to think about:
Who gave the right to these companies to issue certificates, their is no governing entity to monitor these companies security policies. Are their employees trustworthy, is their network trustworthy, whats the difference between seeing a "Trust-E" certificate and "Vendor Company" certificate?
Most people aren't really keen on whats going on between SSL on the client and server side, and when was the last time those who did know check the validity of a cert or the company that issued it?
So you mean to tell me you would dish out a couple of grand because a company "says its so and xxx certificate is the definitive line on secure services?"
No thank you I would rather create, monitor, and control our own certs in house, and ensure that our information is to be used by our company solely.
who's that girl [speedygrl.com]?
The SSL scam (Score:5)
Ten Risks of PKI [antioffline.com]: What You're not Being Told about Public Key Infrastructure By Carl Ellison and Bruce Schneier
Very informative (mirrored) document explaining this question and others in detail.
Swedishporn [speedygrl.com]
Re:Pay for trust (Score:2)
Actually, it's something of a hassle just to get a legitimate cert. You must, for instance, have a Dun & Bradstreet listing (among some of Verisign's irritating requirements.) Of course, it's possible to fake your way into it, but these companies provide a fairly decent level of identity verification.
What is really needed is various levels of cert from self generated ones that simply allow encryped connections all the way up to one that represents careful auditing and controls to surely verify the identity of the server on the other end.
The problem is that it's hard to explain to a browsing user exactly what level of authentication they're using. I mean, most people are just learning to look for that little padlock in the corner of the window. Imagine trying to explain the difference between a simple encrypted link and a fully authenticated connection in an unconfusing manner?
Re:What About Equifax? (Score:2)
Trust and liability (Score:2)
VeriSign Price (Score:2)
I think it should be noted that according to VeriSign pricing [verisign.com] the $349 is only for a 40-bit cert. The 128-bit cert is now $895 USD.
Root CA's (Score:5)
Of course, you can always manually import a root CA, but this is generally beyond the scope of Joe Six-Pack just trying to login to check his stock quotes.
An open authority may be a solution (Score:2)
Of course, the fact that now a handful of commercial companies are the only players in the game is normal. This happens with lot of new technologies. But, also as in a lot of technologies, there comes a time when the technology should be available to more people without having to support a few commercial players.
The idea of trust, which is what the main point is here, can also be handed to an open institute without the goal of profit making.
Just like open source software exists because it fulfills a legitimate goal (slashdot-readers know all about that), the trust needed to secure a website can also be laid in the hands of a trustworthy open institute.
The intellectual property isn't an issue here. A group of people in the know would relatively easy be able to set up such a secure institute for handing out certificates. It's not like this idea is patented. And I expect after a while this will be accepted by the Internet community, including browser makers etc.
Effectively, this will be accepted just like all the Internet protocols are accepted (and are in fact the basis of the complete Internet).