Hacker News Reader

Comment by luser001 | Hacker News Reader

Serious question: why do you want it to be free?

I paid $10 for an SSL cert. Isn't that low enough?

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.

Thank you. I have said this many times. I have 10 dollars, but unlike the US or some other developed country, I can't just ship it overseas.

I guess we need a way to buy certificates with bitcoins?

Namecheap sells SSLs certificates and accepts Bitcoin, at the very least.

It saddens me that every domain registration does not come with a free domain-validated SSL certificate.

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.

Could you explain both those points in a bit more detail - I am a bit fuzzy this morning.

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.

aha - I shall have to go read up on dnssec.

edit: cdjk - thank you - I have to edit-reply as there appears to be an increased time delay on replies. Maybe its me. Bought it.

I recommend DNSSEC Mastery, by Michael Lucas:

http://blather.michaelwlucas.com/archives/1640

It's not out yet, but an nearly-complete draft is available on leanpub (with updates once he finishes copy editing):

https://leanpub.com/dnssecmastery

edit reply: I think the thread is nesting to far...

gandi.net provides a single-address SSL cert free-of-charge for a year with a domain registration or transfer. See: http://www.gandi.net/ssl :)

For the first year, and only the first year. You shouldn't be smiling about the recurring fee.

Actually, they give it to you for the year when you renew as well. So if you renew yearly, you get a year ssl as well.

Also their basic SSL Cert is only about $16 USD. Very reasonable.

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.

It's gotten a lot easier - especially for AWS users and being able to have it dealt with by the load balancer.

> Serious question: why do you want it to be free?

If I wasn't at least a little bit clever with my spending, I would have a lot more difficulty paying my rent.

Why would I want to pay if there is alternatives offering the same product at no cost?

> 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.

[2]: It's not, that's why the system works.

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.

That wouldn't solve the problem in the posted article at all, though. The ad-inserting proxy could then just un-encrypt and re-encrypt.

The point of certs is to stop an attacker just sitting in the middle and handing out their own cert and you not being able to tell the difference.

Their motivation is to sell high assurance certificates to people who have been enticed by the free plans.

It costs them nothing more than a few seconds of server time to produce a signed certificat for me.

Reply on news.ycombinator.com