It is good because that way you know that nobody in between can see your traffic. And more often than not it is enough to know that you are talking to the same site you talked to the last time (just like with SSH).
The idea of "no lock icon" in case of a self signed/unknown CA certificate is a really good idea IMHO. The traffic is encrypted, but it does not give the user a false sense of security.
If you don't know who you're talking to, then there is no point in encrypting the data, because you're probably talking to the attacker. ("Man In The Middle")
Now, the idea of "I'm talking to the same person I talked to last time" is useful, but if the users are all conditioned to accept random certificates without understanding, then when they go back a second time (and the attacker is waiting), they'll agree to the new cert, just like they did the first time.
If you create an account on happykittens.com, you don't really care if the cert happykittens.com is sending you is signed by a trusted CA. What you care about is that the second time you visit the site, when you log in with your brand new account, that the cert the site sends you is the same you received when you created the account (the site is the same you created the account on). This has nothing to do with the fact that the cert is signed from a trusted CA or not, and thus, making it difficult for the user to accept a SS cert is not the right solution IMHO.
Key continuity is a fine answer to this problem. Just come up with a way to provide it on every device every user might reasonably want to log in from, for every site on the Internet.
Actually, no. For all practical intents and purposes encryption w/o authentication is as good as no encryption.
Unauthenticated encryption is 'better' than a plaintext in just one thing - it protects against passive snooping. Anyone willing to splice the connection will have full access to all your plaintext data and you won't even know about it. As such it's nothing more than an equivalent of reversible traffic obfuscation.
So if your "better" meant "obfuscated", then, yeah, it's better. But it's no more secure (in a conventional security sense) than a plaintext.
All that's require are scanned documents. And these documents can easily be tampered with or photoshopped. You may think your company details are checked before the cert is issued, but that's crap. We email our docs to a US company, and all the docs are issued by Irish government departments. There's no way in hell that some guy in what amounts to a call centre in the US has access to any Irish database to prove or disprove their validity. SSL certs are a crock of shit - all you need to do to get one you're not entitled to is to be slightly outside the norm, and claiming any small country as your location is good enough for that. Hell, you could make up your own government departments and documents, and that'd be good enough for must of these companies.
Give me a break. This is like saying all online security is a sham because I can always physically break into your office. You know how many times a real CA has fucked up and accidentally issued a Bank of America certificate to organized criminals in Estonia? ZERO.
You can say it's crap all you want, but until you've worked inside a CA and seen what goes on - you know shit. Good luck ordering a cert with your 'shopped docs...
You can't. Seriously, try it.
You can't get a 'proper' cert unless you go through the background checks.
You can't get a domain-only validated one unless you control the domain.
Encryption is nothing without identity assurance.
If you don't know who you're sending the encrypted data to - why bother encrypting in the first place?
Commercial certificates are not a scam. You're paying for a company (the CA) to certify (via the SSL cert signature) that an identity belongs to someone that has provided proof that they're who they say they are.
You can absolutely do what you're requesting by creating your own CA and signing certs for your sites and distributing your CA cert to your users somehow.
If you can figure out how to reliably provide this service for free you could revolutionize crypto on the internet. You might start by looking at what cacert.org has done to see what problems they've hit and why it's not as easy as it seems.
You are absolutely paying a premium based on the market persuasion tactics Verisign and Thawte have employed against the world. It's true that there's no good reason to trust Verisign more than Mozilla, Microsoft, and OpenSSL --- if Mozilla fucks up, you're just as screwed as if Verisign does.
The business model behind certificates may very well be a huge scam. Unfortunately, the technical model behind having a small number of trusted certificates shipped with your browser is not. Until that link breaks, you don't get security without paying Verisign.
It's amazing how many people still think Verisign are the only CA out there. There are a lot now, and if you hunt about, you needn't pay more than $10-$20 for a cert that's trusted in most browsers (granted, they are domain-only validated, but that's a whole different issue that needs to be fixed, I won't bring it up here...)
The reason you 'trust' Verisign/Thawte/Comodo/Geotrust/GoDaddy is because their roots are in the OSs & browsers. You can't get in those root stores without a hell of a lot of hoop-jumping. I know this. The money you pay for a cert does go to covering the costs of the background checks you have to pass through before you get the certificate.
Trust has to start somewhere - why not with large companies who have undergone rigorous procedures that also have been vetted by the companies you're implicitly trusting by installing their software?
If someone on this board wanted to argue that GoDaddy and GeoTrust haven't really seen "vetting" that makes or breaks their security, as a practitioner in this industry, I don't feel I could win that argument.
What you and I are really saying is that a company like Thawte has staked their business on those pubkeys, so that we at least know that if they screw up, they stand a good chance of losing the company.
Webmaster Bob wants to add his key to the server. Bob goes to the server page and hits add key button, puts in an email address for the webmaster, his public key and submits. Then the public key server sometime in the next couple hours goes outs and checks the website itself. If the two match it adds it to the database.
You can have the server require a reverse DNS lookup and also have it use something along the lines of OpenDNS to help secure against fraud. Also if the server itself uses a CA cert to secure data on transit that would also help secure it. Require a revocation key to invalidate self signed keys on the database would also further security.
Then user Joe can add "Self-sign Pub key extension" to Firefox to automate the checking of public keys.
This allows for a relatively cheap self-signing check. Does a minimal amount of is this the real website I'm using but still not quite the level of a paid CA cert that say a bank should have.
Encryption should be separate from identity verification.
Of course identity verification should be properly vetted and you should have to pay a fee, and have documents checked etc.
If however, you just want to provide security for your users by encrypting http, you should not have to jump through hoops and spend money.