Slashdot Mirror
Free SSL Certificate Project
An anonymous reader writes "Do you have a website or run even a web server and want to secure the traffic between your visitors browser and the web site? Did you find out, that in order to make your site SSL aware, you'll need a SSL (Secure Sockets Layer) certificate? Are you also surprised to find out that such a certificate can cost you up to a few hundred dollars, valid for one year only? For what, you might ask yourself? Linuxlookup.com is running a small article on free SSL certificates."
I thought the whole point of SSL is that not just anyone could get a cert...
TODO: Something witty here...
Just explain to your customers why you cert isnt registered.
Secure certs are one of the biggest ripoffs known to man. The sad fact is that they really only prove that money was able to change hands. This is way, way overdue.
Dog is my co-pilot.
Are steak-knives included in the article? Here's a tip for the AC. Don't make your post sound like a cheap advert. This is a news aggregator (well, it claims to be anyway). Articles should have summaries in a manner that most respected news-sources use. Not like some used car salesman. And if this is off-topic. Sorry, but I'm discussing all that I can, the article summary. The site's down so I can't read the article itself.
Anyone CAN get one! All you have to do is pay X amount of money.
Besides, do you really trust people such as Verisign to actively control certs?
Like being able to self-issue a certif is new? Used some random tool that came with MS Office to do it last time I had a use for one, of course that was Office 2K or thereabouts but it's probably still there, and there are probably alot of other ways to self-issue one. The entire point of the big expensive ones is that you have a "trusted" authority validating the transaction.
Common sense says, make sure the StartCom CA Certificate is not on any of my machines!
The entire point of using certificates is so that you know that there is a certified binding between a public key and an identity. If you don't know who will recieve your encrypted information then there's no point encrypting it in the first place!
In fact, even mod_ssl has information on how to do so on the site:
http://www.modssl.org/docs/2.6/ssl_faq.html#ToC27
- - - - - Fear not the reaper, but my shiny white teeth.
So to sum up, this article is completly useless. Anyone can do this at home, without them.
wtf.n0x.org
Oh and he was protecting his customers by parading around to the press with his lips attached to Daryl's buttocks right? You do remember him traveling around with Daryl spewing their BS to everyone right? Give me a frigging break I won't buy crap from them, I also refuse to help anyone hosting stuff on their servers.
Got Code?
Think about this for a minute... The purpose of SSL is not to secure data during transport, it is to secure data during transport AND to verify to the sender that the reciever is who they claim to be.
Without identity verification there is NO POINT in encryption for most usages.
The point is to make the person who is submitting their credit card number resonably secure in the knowledge that they are sending it to who they think they are. This cannot happen without identity verification.
- sigs are stupid
1. Getting an SSL certificate can require that you fax a copy of your articles of incorporation, public contact information, etc. Someone ends up doing some legwork to ensure that you are who you say you are and that you can be tracked down in the event that there is a complaint.
2. Virtual hosts often share a single IP among many websites. You can't just authorize a name; SSL requires (from my understanding) a unique IP. That would make the IPv4 system even more strained.
3. Certification pricing is partly based on trust. Anyone can generate a free certificate. But it won't work with every system because it wasn't created by a "trusted provider."
If you can't afford a $200US/year fee for conducting "secure" business online, I probably wouldn't want to do business with you anyway.
They should've told SCO to stuff it. Their money (ev1's) went to help SCO perpetuate this crap on others. By extension, so did their customers' money. I know if I were an ev1 customer I would've gone balistic and dropped them immediately. I imagine many people did. If everyone stands up to SCO, what they going to do?
I'm not so certain I believe their excuse that they were protecting customers. Let the customers decide if they want to purchase SCO licenses. EV1 has the resources to fight and that's what they should've done.
I certainly see no reason to give them more money. I'd choose a different SSL provider that is not verisign (they suck too) that didn't give money to SCO, even if that provider cost more.
Take the obvious Fight Club quote ...over a long enough time line the survival rate for everyone drops to zero... and apply the same logic to the chances of a certificate being compromised: over a long enough time line the chances of a certificate being compromised approach one....
Good CAs deal with this in two ways: expiration dates and revocation lists. An expiration date protects your customers from getting something which might've been signed three years ago on the sly, and thinking it's a legitimate offering from the company. A revocation list protects your customers by letting them contact the CA's site to see if your certificate is known to have been compromised.
I want a new world. I think this one is broken.
I agree with this. Ensuring economic reliability for citizens is the government's job, not the private sector's. There is a major conflict of interest when private companies (e.g. Verisign) are making a business out of selling certificates -- i.e. selling trust. Verisign wants your money; what's their motivation to make sure your paperwork is legit? Verisign regularly accepts forged business reg documents, from what I have heard.
Let the government issue crypto certificates, I say.
As you imply, various levels of government are already responsible for issuing the various forms of primary identification which will subsequently be used, by third parties, to sign your certificates.
It makes perfect sense to issue a companion certificate to each of these primary forms of identification. There are good reasons for expiring many forms of identity, and certificates are no different in this regard. Just make the expiry date of the certificate correspond to the expiry date of the identity document or license. The authority and all of the related procedural infrastructure is already in place. So how hard could it be?
By the way, Canada Post was registered a few years ago as a Certificate Authority, but no longer. I'd be interested in knowing the politics behind its disappearance.
Parity: What to do when the weekend comes.
Many fine, relevant comments have already been made in this thread. But I didn't see anyone point out the downside of free SSL certificates: free phishing sites!
Yes, it's possible to freely self-sign certificates to get encryption. I run my own certificate authority for encrypting traffic among my clients, if they aren't conducting e-commerce. These self-signed certificates work fine without triggering a browser warning--if you import the certificate authority certificate.
For my public/e-commerce sites, I use FreeSSL, at $35/year. This buys me a blessing from a CA that is pre-installed in over 95% of all browsers in use. What's not covered? Konqueror. Curl. I think Safari, though I haven't checked recently. For my clients who want those to work, I suggest spending the ~$120 or so for a Geotrust cert.
Now, imagine if every spammer in the world could get an SSL certificate for free... Already domains are cheap enough that they can set them up to easily spoof real web sites--banks, etc. Imagine if every one of those had an SSL certificate, and didn't trigger a browser warning? Most people I know look for the lock. If the lock is there, they trust the site. They don't actually look at the certificate, or even the URL much.
For this reason alone, I'm glad certs aren't free. You can do encryption for free, but I'd prefer my browser to at least let me know the site I'm visiting is too cheap to buy a real cert. (that's not meant as a slam, since I'm too cheap to buy one for most of my sites...).
Cheers,
Freelock Computing
Open Source Solutions for Small Business Problems
Freelock Computing
yes but unless your clients install their root certs they will still get the pop cert warning. Installing their root cert as trusted also compromises you since you have no idea what kind of unscrupulos people they are giving certs to. The trust is not in the certificate, but who is signing the certificate. If I trust verisign, then I trust anyone verisign trusts. Do you trust anyone startcom.org trusts?
did you forget to take your meds?
You can create your own SSL Certificate, however whoever visits your server must chose to accept it. Just because it isn't "Certified" doesn't mean that your site is insecure.
Although, it seems that many of these server certificates are at least a little overpriced. I guess there's a price to pay for that extra compatibility you get because the client certificate is already installed on popular web browsers.
The whole point of certificates is to associate other pieces of information with a private key, like a legal name, an official company name, an address and location, the domain name... the CA isn't just supposed to sign certs that associates those types of information at random, they're supposed to make sure that the information in the certificate they sign reflects the actual entity which holds the private key. Well that's what a CA is supposed to do in theory at least....
If the CA is just signing everything that gets sent to them or simply not including enough identifying information as in your idea then there is no point in the CA's existance... I can't use the certificates they sign to help get an idea of who I'm talking to...
How is one cert more secure than another? Does VeriSign use magic bits that are harder to crack?
"Never underestimate the power of stupid people in large groups."
they do nothing. For once, if the government had a CA authority and actually issue SSLs to companies that are registered with them, it would help. When you register for DBA (Doing Business As) or file articles of incorporation, they should be the ones to issue the certificates as they are the most qualified to judge authenticity and do ID checks. Isn't that the reason why we file these things with the government and NOT Verisign?
/ personal/index.html
This is the one place the government DOES need to be a part of, and yet they do not. Government in all the wrong places.... go figures.
Or when people WANT to be verified online, then the government should be the ones issuing the certificates. When a person say they are Joe Smith, which type of ID do you believe more? An ID issued by some company or a government issued driver's license/ID?
The government actually should have a Certification Authority freely (or some nominal fee) available to its citizens.
See, proper government involvement: http://www.hongkongpost.gov.hk/product/ecert/type
If you are worried enough to want encryption, then you should be worried about man in the middle attacks. No point telling people their credit card details or email will be encrypted if it just gets sent to a random criminal who can read it, re-encrypt it and send it on to you.
If users can verify the identity of the far end point some other way, perhaps because they have previously connected to it, or because they are within a trusted environment, you don't need the signing, or can self-sign. This is how ssh works, you're supposed to check the server ID the first time you use it and then at least simple MITM attacks result in a warning.
But HTTPS is more about reassuring end users than any significant security concern in most situations, and knowing who they are talking to is part of that.
_O_
.|< The named which can be named is not the true named
This is the case if you want to use the default HTTPS port (443) since the hostname is encrypted.
More to the point, the certificate exchange identifying the server happens before you ever get to send the HTTP headers. You can only serve one SSL certificate on each port.
The protocol could be extended to support this, e.g.:
Client: connect SSL
Server: hi, I'm www.site1.com
Client: OK, that cert checks out, but I wanted www.site2.com
Server: OK, here's the www.site2.com cert
Client: OK
but it doesn't currently.
What nobody realizes is that certificates only actually solve a very small problem. They prove that a person is who they say they are. It's like picking up a hitchhiker because they've shown you their driver's license. The fact that they can prove who the are says nothing about the safety of actually letting the person into your car. Certificates provide a false sense of security, but making people think it's ok to install such-and-such active-x control, because it's signed. It doesn't matter if you can track down the person who created it once your data is all gone. Tracking the person down isn't going to get your data back.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.