Hacker News Reader

Comment by TekMol | Hacker News Reader

I still wonder how Let's Encrypt works.

I understand that the problem they solve: A user wants to get the public key for a certain domain. So he knows he is talking to a server by the domain owner and not some man in the middle.

So he asks a third party whos public key he already has. In this case Let's Encrypt. Ok.

But how did Let's Encrypt get the public key from the domain owner?

I know they make the domain owner install some software on his server. But how does that make sure they talk to a server by the domain owner and not a man in the middle? Does the software include some private key so they can send them a "hey, encrypt this" message and to prove the server in fact has that private key?

If so, why is the Let's Encrypt software so complicated and not just a 5 line script or something?

View on HN

They have a variety of "challenges" used to prove control of the domain. They basically boil down to:

- LE makes a request to example.com, to a known URL that contains a key that LE told you to put there

- LE does a DNS lookup for a specific TXT record (again, containing a key they told you to put there).

The complete answer to your question can be found in the ACME spec (the protocol LE uses):

https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.htm...

LE probably does that multiple times from a few places around the internet, to reduce the likelihood of something unexpected going on.

Ain't nobody got time for that!

They might have "a few places around the internet" to verify from, but I doubt it is very diverse location-wise. And there's no way they're going to bother with doing it multiple times, for free.

> they're going to bother with doing it multiple times, for free

You are aware you are talking about the cost of a single HTTP GET?

> You are aware you are talking about the cost of a single HTTP GET?

First, the conversation is about the possibility of multiple (not single) interactions, including protocols other than HTTP such as DNS.

Perhaps you're confusing a subset of what they currently do vs. coordinating the initiation of requests multiple times from a few places around the internet (per OP) supporting multiple protocols, aggregating and verifying the responses, etc. -- all within a reasonable timeframe at scale with Internet infrastructure level high availability (while protecting against malicious misuse)?

I hope this is enough to explain that no, that's not what I was talking about. But thanks for taking the time to reply!

There is a nicely done 'how it works' on Let's Encrypt: https://letsencrypt.org/how-it-works/

I have read that, but it seems overly complicated. Why not just give the domain owner a private key and a script that is a few lines long. So he can sign a message from them and prove he has the key?

In effect that is sort of what they are doing, but simpler.

You claim to have domain x.com. LetsEncrypt sends you a token. Place it in a DNS record or in a pre-determined path on your domain and ask LetsEncrypt to read it back.

If it matches, it is verified that you own the domain.

How is the scheme you propose simpler, whilst retaining the same base guarantee (that the requester is the owner of the domain in question)?

> in a pre-determined path on your domain

That would be easy and elegant. But they want you to install software on your server.

They want to make it easier, and that's the easiest way, but it's not required. You can perfectly well run it on your machine and copy the files manually to the server. You can even use a simple webpage as your local client: https://gethttpsforfree.com/

The only software you need is something that can speak the ACME protocol, which is what letsencrypt uses to receive your CSR (which you can generate yourself with openssl), issue challenge tokens and then (subject to you successfully passing the challenge) give you a certificate.

You don't necessarily have to do any of the above on the server for which you want the certificate. You can do it somewhere else and then transfer the resulting certificate to the intended host (either manually or with a shell script/ansible/puppet whatever).

The software just negociates the token and such things, and communicates with EL to say “I want to have a certificate for such and such domains”.

But you can place these tokens on your webserver by hand if you want, in a pre-determined path.

I always balked at the hoops I had to jump through until Let’s Encrypt came along. I now have two boxes, one Gentoo, one CentOS updating every three months pretty much pain-free. I know it's not a valid counter-argument but I'd say that 100M certs issued and the general tone of user feedback says you're wrong about it being overly complicated.

In the process you describe, there is no step where you confirm that you are actually the domain owner. Anyone could obtain a certificate for google.com.

Verifying domain ownership is what the challenges are responsible for.

To know you're talking to the domain owner, I think you'd have to use the contact info from the whois info. I don't believe that's especially consistent across tlds.

The http or dns challenge/response is more reliable and pretty easy to automate and scale to many domains.

How do we know that the recipient of the key in your scenario (or the originator of the CSR) is in fact the domain owner? The domain contains contact information, but the exchange can't be done by email - that's not secure. Can't be done by SMS - that's not secure. We don't know them personally, so there's no obvious out-of-band technique that can be used.

We'd have to go back to physical snail mail using the address on the domain record, and/or notarization. Both of which of non-automated and very slow (relatively speaking).

I quite like using DNS verification for this sort of thing.

There's two ways. You can include in DNS a TXT with the validation string they give you during install, meaning you can do it so it's yours. Or you can add a special file in a special directory of the website behind the domain you're asking a certificate for. So it means you've got access to it so you're the owner, or a technical third party who can do that.

Of course it doesn't prevent a total hack of your infrastructure but when you've come to that point, you've got bigger issues.

https://en.wikipedia.org/wiki/Certificate_signing_request

> A user wants to get the public key for a certain domain. So he knows he is talking to a server by the domain owner and not some man in the middle.

> So he asks a third party whos public key he already has. In this case Let's Encrypt. Ok.

It works quite differently -- the browser doesn't have to talk to Let's Encrypt at all to verify correctness.

How it works:

1. Browser connects to the server

2. TLS handshake, crypto-stuff

3. The server cryptographically presents the browser his certificate

4. The server's certificate is the server's public key, some attributes (like what domain names the cert is valid for) and a digital signature of all that stuff

5. The browser has a list of certificate authorities

6. The browser checks whether the digital signature on the server's certificate is valid and was made by a CA the browser trusts

7. The browser checks that the certificate is valid for the site it's currently accessing

8. Connection legit

The problem that the CAs (including Let's Encrypt) solve is not distribution of public keys, but rather trusting public keys presented by someone.

> But how did Let's Encrypt get the public key from the domain owner? > I know they make the domain owner install some software on his server

What the ACME clients do is two-fold:

1. They put up some sort of challenge response mechanism. This is used by Let's Encrypt to test whether a client is authorized to rule over a domain.

2. They generate (or use) a "Certificate Signing Request" (CSR). A CSR is basically a digital "sign here" field. The CSR contains the server's public key, what domains it wants to represent etc.. The CA checks the CSR using the challenge-response mechanism from (1) and then signs it digitally. The result is a certificate, which is sent back to the client and installed by the client. The private key of the certificate never left the server.

> If so, why is the Let's Encrypt software so complicated and not just a 5 line script or something?

Well it doesn't have to be complicated. acme.sh is only five (thousand) lines of shell :)

There are a bunch of ways the challenge-response mechanism can work, and there are also a lot of other options, which add to the complexity, as well as installation routines for certificates, which support a bunch of different servers.

A specific case with "static" challenge-response could conceivably boil down to just a dozen lines of shell or so.

Nit pick: Although toy systems work by "just" signing the CSR a real CA like Let's Encrypt basically throws the CSR away after verifying its integrity.

The CSR is a signed data structure that says "Hi, here's my public key K1, and I want you to issue me a certificate with properties P1, P2, P3 for names N1, N2, N3" and it's signed using a private key K2.

Using K1 (which is right there in the document) we can check that the K2 signature matches. If not, we can't be sure the real owner of K2 even wanted this certificate and we must reject it.

Then we can look at the list of P1... and N1... and decide if we want to issue a certificate at all. If we do, we can choose to issue any certificate we want, we don't need to issue exactly the one described in the CSR.

This is important because many CSRs, whether generated by well-meaning admins or automatically by an appliance or service, are full of crap that Let's Encrypt doesn't want to, or isn't permitted by the Baseline Requirements to sign.

[ e.g. it's very common for CSRs to claim that London is in a County called Middlesex. Nope, that county was abolished decades ago, London isn't in a county at all, but people see a field labelled "State or County" and they figure they should write something in the box. If a CA signs that, they're claiming Middlesex still exists. ]

By constructing each certificate from first principles after examining the CSR, Let's Encrypt can ensure they sign only certificates for exactly the things they've validated, nothing else.

Thank you, that's a good and important point. It also has the angle that the CA can't accidentally "miss" anything, since the certificate is not constructed from client-supplied data (=> voila, we're at Langsec :)

Reply on news.ycombinator.com