Let's Encrypt: How It Works

by espadrine • 12 years ago

408 121 12 years ago

radiospiel• 12 years ago

I am somewhat excited about letsencrypt, but isn't ownership verification via DNS not a bit, hmm, strange? After all, a proper certificate should defend against MITM attacks; so if an attacker would be able to take control over the target's DNS, he could easily create a certificate, which looks legit for all intended purposes. Or do I miss something in that regard?

Wilya3• 12 years ago

Ownership verification is already done via DNS by existing CAs. If an attacker has full control over your DNS, he can already change the DNS records and trick a CA into delivering him a genuine certificate.

This isn't really a MITM attack.

slasaus• 12 years ago

"If an attacker has full control over your DNS"

Shouldn't this be "over the CAs DNS resolver"?

/edit

well I guess if the attacker has control over your dns server, ofcours, but another vector is to spoof as the CAs resolver when the CA does a lookup for your domain.

mappu2• 12 years ago

What existing CA's offer this?

The ones i've used (godaddy, startssl, namecheap/ssls.com rapidssl/positivessl) all wanted email verification iirc.

EDIT: of course that's equivalent to verifying the MX. Never mind!

pfg3• 12 years ago

I think you're right, however this is no different from how your average domain-verified certificate is issued (where you'd receive a confirmation mail to something like webmaster@example.com or serve a file given to you by the CA on a specific path). If an attacker manages to hijack your DNS, he could also modify your MX/A records and receive that mail/host the file.

You could argue it's even slightly better, since with this solution, DNS is the only attack surface, whereas with email verification a vulnerable mail or web server would be enough. That is, if DNS is their only supported verification mechanism (which I don't think is true.)

grecy2• 12 years ago

Sorry for the newbie question....

So if I have apache running http://example.com on port 80 and I follow the instructions ($ lets-encrypt example.com)

Will Apache now be correctly serving encrypted traffic on port 443 with a cert for https://example.com ?

haroldp2• 12 years ago

That's the idea. It assumes you are using an OS with a package manager, and letting it manage your software and (to some extent) config files.

st3fan3• 12 years ago

And if you don't, or if you don't want to, it is easy to configure Apache or any web server manually.

All you really need are three things:

* the letsencrypt command line tool that will do the API dance to request the certificate

* a file in your web site root with a ownership verification token or a DNS record with said token

* a configuration file snippet for your server

I'm sure all of this will be documented very well.

grecy2• 12 years ago

Nice, thanks. (I'm running on Ubuntu, so should be good)

bifurcation7• 12 years ago

The ultimate vision is to make it even easier than that -- you set the "turn on HTTPS" option, and the platform auto-configures HTTPS with a certificate and appropriate ciphers. That will require upgrades to apache, nginx, IIS, etc., though, so in the meantime, we have the "lets-encrypt" script to semi-automate things.

ivok• 12 years ago

So going from a single command to a different single command? How much simpler could it get?

haroldp2• 12 years ago

It seems like the one thing this doesn't/can't address is the IP shortage. Does help much if example.com is virtual hosted on the same IP address as 100 other sites?

cmwright2• 12 years ago

The SNI stuff (http://en.wikipedia.org/wiki/Server_Name_Indication) helps with this if you can do without XP support.

sp332• 12 years ago

It's not really XP that's the problem, but IE6. Firefox and Chrome support SNI even if you run them on XP.

ZoFreX3• 12 years ago

And also Android 2.3 stock browser support.

silverwind• 12 years ago

This really isn't a problem any more with SNI. With XP dying out, there's really no excuse anymore to not use it for shared hosting.

tedunangst5• 12 years ago

Python 2.7 (no SNI support) is the new Windows XP. Not a browser problem, but if you're building an API, it will lock people out.

(sorry to beat a dead horse, but it's burned me recently and I think people are flipping the https only switch without awareness or consideration. doesn't mean "don't switch", but be aware.)

Simucal• 12 years ago

What kind of impact is Let's Encrypt going to have on the CA industry? I'm not that familiar with the current state of the CA companies, nor do I understand this industry well enough to know if this is going to be a major hit to them or not.

Is there any reason why a company would prefer a CA other than Let's Encrypt?

st3fan3• 12 years ago

Insurance, guarantees, EV certs, doing business with a big trusted company. All reasons to stay with your regular CA.

(Personally I don't care about any of those reasons - I just want my website to be SSL powered with an official cert and modern cipher configuration.)

aeden• 12 years ago

The impact depends largely on their ability to get their root certificate into all of the browsers. It'll be interesting to see what happens with older versions of browsers as well, since if they start with a brand new root certificate then I'm not sure what happens with the older browsers.

If they can get their certificate into all of the browsers then it's possible they could achieve broad adoption for domain-verified certificates. There will still be a market for other validation types (organization validated and extended validation, for example) though.

Supermighty• 12 years ago

since if they start with a brand new root certificate then I'm not sure what happens with the older browsers.

IdenTrust will cross-sign Let's Encrypt root cert. I imagine they will keep it cross-signed, for backwards compatibility, once LE has their root cert in all the browsers.

mike-cardwell• 12 years ago

It will cost existing CAs a lot of business. We already had free certs from StartSSL, but they were for non-commercial purposes only.

I imagine a lot of shared hosting companies who currently resell SSL certs to their own customers will be switching to this next year.

I will certainly use them, and will only recommend them and nobody else. The only reason I'd ever look at one of the old CAs now, is for EV certs. But 99% of the time, people don't need an EV cert.

ultramancool2• 12 years ago

It's very, very hard for traditional CAs to compete with free, trusted in all major platforms and with dead simple set up. Hopefully this sort of scheme, combined with the added trust of Certificate Transparency, can kill off most traditional CAs.

The only reason I would still buy 1 certificate is for wildcard support.

dale3862• 12 years ago

Which browsers will trust Let's Encrypt certificates out of the box? There may be a major backwards compatibility gap here.

jeffreyrogers3• 12 years ago

I'm not sure why you've been downvoted. This is a very reasonable concern and one that should be addressed.

joshmoz• 12 years ago

We'll have very broad compatibility from day one via cross-signing by IdenTrust.

dale3862• 12 years ago

Great, thanks -- I'm looking forward to your release.

Animats2• 12 years ago

Keep track of when your certificate is going to expire, and automatically renew it.

Or, all you have to do is let this new piece of software run periodically on your secure server. What could possibly go wrong?

st3fan3• 12 years ago

Why so negative? Don't you think this is much better than the very manual ways that we now have?

Automate it. Make it part of your maintenance scripts. Put it in a cron job. I think it will be a huge step forward.

jeffreyrogers3• 12 years ago

I think the OP was expressing concern over Let's Encrypt being installed on servers and potentially doing malicious things. Of course, if you apply this logic to Let's Encrypt you could just as well apply it to your web server or your mail server, or even your OS itself. At some point you just have to trust that the people and organizations that you're getting your software from aren't malicious... or you could write everything from scratch yourself.

jeffreyrogers3• 12 years ago

I take it you've read the source code of Apache and Nginx then and confirmed that they aren't doing anything malicious as well? :)

In any practical security system you are always going to have to trust that certain components are doing what they say they're doing. Fortunately, Let's Encrypt is from a reputable group, and sponsored by organizations with good reputations (Mozilla, EFF, etc.), which is about as good as you can hope for.

akerl_• 12 years ago

Yes, I need to trust some things. But I can limit the amount of trust I need to have by limiting the number of things to run. I can add a reminder to my calendar to say "hey renew your certs", or better yet I can add a check to my existing monitoring service to look at expiration dates. Why run a whole new persistent service just for this?

tedunangst5• 12 years ago

Many people draw a line between one time trust and continuous trust. If this thing can update the certs on my server whenever it likes, that's substantially more trust than permitting it to install a cert exactly once. If, for example, it has a bug that permits a malicious upstream to overwrite arbitrary files, the window of vulnerability expands from "the CA is pwned this instant" to "the CA will at any future time ever be pwned".

ZoFreX3• 12 years ago

It's a balance, at the end of the day. I won't be auto-updating on my server because it's not hard for me to do that myself. But if someone is just running a site where HTTPS isn't particularly important (a personal blog, say) then the convenience might outweigh the very slight security concern - better they are using HTTPS at all, if the alternative to convenience is HTTP.

xorcist2• 12 years ago

You're probably already doing something similar if you use OCSP stapling.

It needs to run continously for revocation purposes but8

xorcist2• 12 years ago

You're probably already doing something similar if you use OCSP stapling.

It needs to run continously for revocation purposes but you don't notice because it's integrated in your web server. This could be done in the same way.

tedunangst5• 12 years ago

Unfortunate choice of wording. From the web page:

Obtain a browser-trusted certificate and set it up on your web server

From the "RFC" on github:

In the background, the web server contacts the CA and uses ACME to request that a certificate be issued for the intended domain name(s).
Once the CA is satisfied, the certificate is issued and the web server automatically downloads and installs it, potentially notifying the operator via e-mail, SMS, etc.

This really sounds like they are generating the key pair, not just signing it. I think (hope) that's not the case, but clarity on this issue is pretty important.

CGamesPlay• 12 years ago

The technical overview [1] shows that the private key is on your server and never leaves it.

[1] https://letsencrypt.org/howitworks/technology/

jdkasten2• 12 years ago

The open source python code also demonstrates it.

https://github.com/letsencrypt/lets-encrypt-preview

adamtj2• 12 years ago

They're generating the certificate, not the keys. Those are different things. You can probably think of the certificate as the computer equivalent of photo ID for the server.

They both show who you are (Driver's License: your name, cert: hostname), what you look like (DL: photo of you, cert: the key's fingerprint) and provide proof that they are genuine (DL: difficult and illegal fake, cert: practically impossible to do the math to forge a signature).

Note that they mention certificate singing requests. If the CA generated the keys, it wouldn't also need a CSR. It could just generate and send you the public and private keys and the signed certificate for them. However, it does need some information about the keys it's signing. You provide that information in the form of a CSR.

grey-area4• 12 years ago

Looks to me like it generates the keys locally OR you can specify the keys if you like. But since the private key doesn't leave your server, it doesn't really matter either way.

https://github.com/letsencrypt/lets-encrypt-preview/blob/mas...

ecoffey• 12 years ago

The driver license analogy is pretty great, I'll be stealing that :-)

venomsnake• 12 years ago

Automatically prove to the Let’s Encrypt CA that you control the website

If something could "just" prove identity without worrying about MITM we would not need the whole RSA stuff.

cakeface• 12 years ago

I had a hard time un-packing this for a minute so I want to try and clarify.

The part about proving to Let's Encrypt is problematic for sites that do not already have TLS on the example.com domain. Any plain HTTP request that Let's Encrypt makes to example.com to validate that you've put up some content on the server is susceptible to a MITM attack. I guess that means for users setting up certs for the first time they can't just put some content up on example.com and need to use DNS or something else to prove ownership.

The MITM problem with requests to example.com doesn't exist if example.com is already set up for HTTPS, which is probably why the examples on the technical description show requests for https://example.com/8303. I was confused about that at first because Let's Encrypt is largely targeted towards people without any TLS encryption yet.

iancarroll6• 12 years ago

I guess that means for users setting up certs for the first time they can't just put some content up on example.com and need to use DNS or something else to prove ownership.

FYI, CAs do this already (HTTP validation), but an easy fix is to generate a self signed cert and pass the fingerprint of it to the CA.

murbard2• 12 years ago

I don't see how using TLS would prevent MITM in this case. TLS only prevents MITM if you know public key or if it's been signed by a CA, but neither is the case here.

StavrosK3• 12 years ago

Why can DNS not be spoofed when HTTP can? It seems to me that you need one to spoof the other...

schizoidboy• 12 years ago

Great project! Please also provide a yum repository and instructions (and any others you feel are popular enough). You may want to look at the way SSLMate does it, with an operating system drop down selection (Debian, Ubuntu, RedHat, Arch, Mac, Other).

schoen4• 12 years ago

We are actually hoping to have packages shipping from the official OS repositories, so you won't even have to get the package from us. (If anyone wants to help with this aspect, please get in touch.)

mappu2• 12 years ago

Is it possible to get new packages into Jessie post-freeze?

debacle• 12 years ago

I really like this and I am excited by the sponsor list. The self-signed cert notification in browsers is becoming more obnoxious every year.

drostie• 12 years ago

Does this kill the business model for normal CAs, or is there something worth going to another CA for?

Also, how trivial/hard will it be for a state agent to generate its own certificate-signing traffic and use the Let's Encrypt CA to sign arbitrary domains of their choosing?

StavrosK3• 12 years ago

I'm thinking someone could spoof a DNS entry for the signing server and prove that they own any domain they want, is that prevented somehow?

sbierwagen2• 12 years ago

If an attacker can spoof DNS, they can just create A records that point to their own server, and MITM from that.

Public key pinning would protect against that class of attacks: https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinn...

sbierwagen2• 12 years ago

It doesn't issue EV certs, so the business model for traditional CAs will be those.

raesene3• 12 years ago

I don't think EV SSL certificates have been a big success (though that's just a personal opinion rather something backed with specific data)

For me the differentiation in the browser presentation of EV against ordinary SSL doesn't provide much additional security. Most users don't notice the difference and even if they do, wouldn't remember which sites had an EV certificate, such that they would notice it changing back to non-EV

Wilya3• 12 years ago

CA also offer more expensive tiers of certificates, that include EV, or a warranty for commercial transactions.

I've never used those, and I don't know how relevant these are for companies, though.

dewey• 12 years ago

Is this a wildcard certificate and will it cover subdomains that way? Couldn't find anything on the site clarifying that.

giovannibajo1• 12 years ago

Why caring at all about OCSP/CRL revocations that don't work anyway (https://www.imperialviolet.org/2014/04/29/revocationagain.ht...)? If you have an agent running on the webserver, you're 99% close to simply use short-lived certs. Just issue 1-week certs and be done with.

bifurcation7• 12 years ago

Getting to short-lived certificates is a goal, but the reality for now is that OCSP and CRLs are what implementations require, and what the CABF Baseline Requirements require. So we'll need to start with those.

z3t4• 12 years ago

Wouldn't it be much easier if lets-encrypt just created the .crt .key files!? Rather then set it up automagically.

You could have it run once a year via crontab.

I would like to keep the control of my .conf files.

jdkasten2• 12 years ago

That will be an option.

Also, the current implementation only changes the SSLCertificateFile directive if you provide your own --key, --csr and already have an SSL vhost for the domain. (This one change is logged.)

don_draper• 12 years ago

Note to self: Donate to EFF

higherpurpose• 12 years ago

Why leave for tomorrow what you can do today?

https://supporters.eff.org/donate

bifurcation7• 12 years ago

Let's Encrypt: How It Works

Related Stories