There are several billion people for which that's significant, whether because of where they live, or their age, or access to credit cards to make purchases online easily. $10 more than doubles the minimum cost of having a website on your own domain.
I think this is what's going to drive the adoption of DNSSEC: free, DNS-validated SSL certs.
IPv6 should address the other problem - namely, that SSL certs are per-ip, not per-hostname, which makes hosting multiple sites a pain with IPv4. Or SNI could work, once Windows XP is truly abandoned.
Historically, you can't serve multiple sites from one IP address (i.e. named virtual hosts) and use HTTPS. The reason for this is that the hostname of the site is included in the HTTP request from the client:
HTTP/1.1 GET /
Host: mysite.com
By the time the server has decoded and read this header, you have presumably already started the secure connection, so the server has to have already selected which certificate to use for the session.
Workarounds are to have multiple IP addresses on your box with one cert per IP, or run the server on multiple ports with one cert per port. In both cases this enables the server to know which certificate to use from the underlying connection properties, and not wait for the encoded traffic to start arriving.
SNI (Server Name Identification) is an extension to TLS (Transport Layer Security) that essentially adds the hostname into the SSL negotiation, so this cert can be selected by the server in advance. It made it into OpenSSL implementations in the mid-2000s and is reasonably widely adopted.
Legacy libraries, Internet Explorer <=7, and Windows <=XP won't support it so it's not quite ready for mainstream use. Give it 5 years or so...
The sibling poster does a good job explaining SNI. The shorter version is that without SNI all you know when establishing the secure connection is the IP address, so you can't do name based virtual hosts.
I'm not an expert on DNSSEC, but the idea is that there is a chain of trust going back to the domain registrar. If a receive a signed DNS response, and everything verifies, then I know that it comes from the person who registered the domain. I can't add a signed entry for example.com, so if I received a signed DNS response for example.com, I know it ultimately originated (with possible caching like normal DNS) from whomever registered example.com.
You can then add what is essentially a TXT record to the DNS entries for a domain that is the fingerprint of an SSL cert. If you receive that as a valid dnssec response, you know it can be trusted.
Essentially the dnssec infrastructure replaces the CA infrastructure.
You can do the same thing with ssh key fingerprints too.
They're also a PITA to setup.
A lot of amateur webmasters have only just figured out FTP and wordpress. The whole CSR , key gen ritual is another big barrier.
> Why would I want to pay if there is alternatives offering the same product at no cost?
Because free isn't necessarily a sustainable model given the current CA environment. Any server can generate its own certificate, but this does little to verify the identity of the server you are connecting to.
My point is that CA's provide a service that can't reliably be accomplished for free (yet - the CA model has many of its own issues). If you can find one for free, I would be lead to ask "what are their motives for providing this service to me?"
It would be nice to have the option of encryption without identity validation. Most people interact with most sites without it today -- over HTTP. The only reason we can't encrypt all those connections is the big scary error message browsers throw up when you do so without paying a CA for their signature.
It has nothing to do with paying money, it has to do with reputation. The fact the most the companies (CAs) that are willing to put their reputation on the line for you will do a bit of checking to make sure you're who you say you are, and that this process incurs some overhead, is a byproduct.
Let's put it another way, would you really trust that you're talking to https://www.amazon.com if it's trivial to get a cert for www.amazon.com[1] that's signed by a CA that the browsers include and trust[2]? How is it any different if the browser doesn't tell you the current cert is of dubious reputation?
[1]: It is, I could generate one right now using openssl.
Web-of-trust schemes are effective. The usual way we find out about stuff like this happening is word-of-mouth. Infrastructure for the process would automate it - after all the only thing you need is a way to say "this is what the certificate's hash should be".
I'm not asserting that there's no other way to do it, just that getting rid of the popup that says the site is untrusted is not a solution, nor even a step in the right direction, IMHO.
I paid $10 for an SSL cert. Isn't that low enough?