Let's Encrypt Is Making Web Encryption Easier

That's the conclusion of a research paper:

Once [costs and complexity] are eliminated, it enables big hosting providers to issue and deploy certificates for their customers in bulk, thus quickly and automatically enable encryption across a large number of domains. For example, we have shown that currently, 47% of LE certified domains are hosted at three large hosting companies (Automattic/wordpress.com, Shopify, and OVH).

Paper: "No domain left behind: is Let's Encrypt democratizing encryption?"

Abstract: The 2013 National Security Agency revelations of pervasive monitoring have lead to an "encryption rush" across the computer and Internet industry. To push back against massive surveillance and protect users privacy, vendors, hosting and cloud providers have widely deployed encryption on their hardware, communication links, and applications. As a consequence, the most of web traffic nowadays is encrypted. However, there is still a significant part of Internet traffic that is not encrypted. It has been argued that both costs and complexity associated with obtaining and deploying X.509 certificates are major barriers for widespread encryption, since these certificates are required to established encrypted connections. To address these issues, the Electronic Frontier Foundation, Mozilla Foundation, and the University of Michigan have set up Let's Encrypt (LE), a certificate authority that provides both free X.509 certificates and software that automates the deployment of these certificates. In this paper, we investigate if LE has been successful in democratizing encryption: we analyze certificate issuance in the first year of LE and show from various perspectives that LE adoption has an upward trend and it is in fact being successful in covering the lower-cost end of the hosting market.

Reddit thread.

Posted on December 14, 2016 at 6:46 AM • 27 Comments


TGDecember 14, 2016 8:17 AM

I think Let's Encrypt is a great idea, but I have an issue with it. I wanted to use it on one of my servers, but last time I checked, their script needed to run with root privilege, which is a big no-no for me. Is this still the case?

Pete S.December 14, 2016 9:11 AM

TG: the reference implementation, certbot, does need to run as root. But there's many other implementations that exist, and several don't require root.

Peter PearsonDecember 14, 2016 11:22 AM

Let's Encrypt has ruined my strategy for secure browsing. That strategy was to disable all root certificates except a handful of Really Serious certificate authorities whose root certs are used by the very few sites whose security I Really Care about (e.g., my bank). During casual browsing, I would see -- and click past -- occasional warnings, but when filling out my bank's login page, a glance at the security indicator in the address bar would assure me that my connection was well certified.

Since I haven't enabled Let's Encrypt's root certificate, Let's Encrypt's increasing popularity has made my normal browsing tedious due to warnings for sites whose security I don't really care about.

Someday something like certificate pinning might provide a practical way for me to ensure strong security on a few selected sites, while accepting sloppy security on all other sites. But what's the right strategy in the meantime?

albertDecember 14, 2016 12:34 PM


If you're that concerned about security, you should be doing your banking on a separate machine. Since bank websites shouldn't require a lot of performance, a LiveCD system on modest hardware would do. You can be -very- specific in your setup, since you don't need compatibility with casual websites.

. .. . .. --- ....

K.S.December 14, 2016 12:47 PM

@Peter Pearson
I use dedicated hardware for "Really Care", such as banking, uses. It isn't used for anything else, so you don't have to consider usability aspect.

So get a laptop, stick a fresh hard drive into it, reflash BIOS, install and harden clean OS of your choice from optic media, and only use this laptop over wired connections. Bonus points for encrypting hard drive and keeping it in a locked cabinet.

WaelDecember 14, 2016 1:04 PM

@K.S., @Peter Pearson,

So get a laptop, stick a fresh hard drive into it, reflash BIOS, [...] and only use this laptop over wired connections.

Not sufficient. Are you implying that "wired connections" are somehow "secure"? And what image do you recommend to flash the BIOS? And how do you know the image is "good". And if it's good, how do you know other FW images are "not bad", and ...

TGDecember 14, 2016 1:12 PM

@ Pete S: could you point me out to some of those implementations please? I might give LE a second try on my server.

My InfoDecember 14, 2016 1:28 PM

Re: O.P.

Once [costs and complexity] are eliminated, it enables big hosting providers to issue and deploy certificates for their customers in bulk, thus quickly and automatically enable encryption across a large number of domains.

Oh yeah, I can do that too. Just generate a self-signed certificate-signing certificate, and have all my most worshipful customers "trust" it....

Ross SniderDecember 14, 2016 2:26 PM

Unfortunately the 2013 Mass Surveillance Disclosures showed that PKI has been broken. I don't see how Let's Encrypt addresses this? Does it do something special or is it more of the same?

ab praeceptisDecember 14, 2016 2:39 PM

As far as I'm concerned let's encrypt is crap and I avoid it like the pestilence.

And, quelle surprise, it just so happens to have come alive, when pretty much every serious professional has lost trust in tls.

More importantly, though, l.e. brought dynamic at the wrong end. We need dynamic at the revocation end.

Quite many people have made quite some effort to make sure they're talking to whom they think they talk to. Pinning, cross-referencing, cache matching, and other mechanisms have been developped. And now, bang, short-term certs ~ high increase of cycle speed.

Call me idiot if you want but in my minds eye nsa is the real winner in that game.

rDecember 14, 2016 3:22 PM


You call having to decrypt (with keys) a blanket encrypted web easier for the NSA?

"California to adopt first U.S. energy-saving rules for computers"

Your theory of ease is flawed, especially for someone as seemingly well educated as yourself. Not only does encryption en mass complicate matters of identifying specific encrypted streams (think embedding and redteams) but it also complicates the energy requirements for such practices.

It makes things harder for non-nsa for sure, so on that front it makes things easier for them by raising the bar for others.

Other than that? I just see typical ab.

rDecember 14, 2016 3:23 PM

It's the right move, no matter what ab thinks about the PKI connotations.

If he had a better solution he'd be espousing that just like he did on the other thread.

rDecember 14, 2016 3:33 PM

More to the point ab,

"Let's Encrypt Is Making Web Encryption Easier"

They are authoring (granted, potentially authortarian exploitable) integration tools and dialog which IS undoubtedly making "web encryption easier".

Let's Encrypt is not torproject.org


ab praeceptisDecember 14, 2016 4:13 PM

My Info

Indeed. The "thus quickly and automatically enable encryption across a large number of domains" mantra tells a lot.

They have created a frenzy. Why would I need to encrypt my connection to youtube or to a news site? After all, the vast majority of web content is expressely made for public consumption. Yet, if aunties yum-yum recipees blog doesn't support https it's considered as retarded or at least a very yesteryear.

What is regrettably little mentioned is the cost side. TLS doesn't come for free; it eats up considerable resources and, in fact, opens an attack vector, namely (D)DOS. Simple thing: If I can handle 3000 reqs/s on a given server I can handle maybe 300 TLS reqs/s on that same server. To make it worse, TLS is, seen from the attackers perspective, brutally asymetrical to his advantage. All he needs to do is to attempt a connection to make my server work hard.

Another issue I have that is more let's encrypt specific is that the "holy part" in PKE is the private key. Which necessarily is on my server. Just like the code from let's encrypt ...

I hear "but the key is root/600 and the script shall not be run as root" - bullshit. Experience tells us clearly that in real life a lot is done as root and many admins don't work meeting propoer OpSec guidelines.

Finally, the browser guys have put let's encrypt on the accept list quickly and generally treated it like the coming of the messiah. They might as well have stopped their stupid "unsigned certificate! Do not proceed!" witchhunt against self-signed certs to achive the same result, namely to "quickly and automatically enable encryption across a large number of domains"; and nothing would have been lost as one could still have green bars and funny lock symbols ("golden 'secure' stickers") for signed certificates.

But instead of stopping the witchhunt and accepting self-signed certs or maybe showing them with a yellow bar they chose to continue the witchhunt and to feed us worthless and even dangerous let's encrypt crap.

One major message to finally learn is this: Do not trust the browser people!

rDecember 14, 2016 4:21 PM

https://news.ycombinator.com/item?id=12661227 (isp ip spoofing statics and talk)

also, ask yourself why would there be advocates for outlawing encryption?

Don't trust the browser people?

Don't trust anybody.

They have created a frenzy. Why would I need to encrypt my connection to youtube or to a news site? After all, the vast majority of web content is expressely made for public consumption. Yet, if aunties yum-yum recipees blog doesn't support https it's considered as retarded or at least a very yesteryear.

I'll see your "why would I need to encrypt" and raise you a duh:


It's not just kids sites, pbs.org itself too not to mention countless other NEWS and VIDEO aggregation sites too.

We all know, that you could pick up Zika and give it to your wife.

CNE is no different.

rDecember 14, 2016 4:26 PM

Allowing a person to easily include a band-aid for midpoint vulnerability is not a bad thing, it's a whole lot easier to offer and implement than asking the 10,000 companies involved in your website facing software to patch video and audio codec issues script failures image encoding apache nginx etc ahead of time or all at once don't you think?

Give it up, the whole underlying system is far more broken it's PKI subsidiary and this _helps_.

fishytooDecember 14, 2016 5:14 PM


Just to note that my preference for TLS secured sites stems from the added layer assurance that the bits being sent by the server are the same ones I receive at my end. The reduced risk at my end makes the extra work for the server worth it to me.

Self signed certificates are nice, but don't have the backing in most browsers to be reliable (e.g. the revocation issue). Having certificates signed by a certificate authority also gives me confidence that the secure connection is using a current key, and that the proper server is responding (vs. an imposter).

Hopefully the growing popularity of EV certs by will help keep differentiation of properly vetted keys easy in the browser now that anyone can use TLS.

Mike AmlingDecember 14, 2016 6:07 PM

I wonder how many of the LE-secured (and other) sites' private keys have been compromised without the knowledge of their owners.

KarinDecember 14, 2016 7:29 PM


I think some of the proposed solutions to your problem are overkill. You could just make a separate "secure" browser profile (e.g. run "firefox --ProfileManager" to create, then "firefox -P profilename" to use; setting $LOGNAME differently for each may help if you find stuff popping into the wrong instance). Do whatever you want with the CAs in that profile. Personally I disable them all and manually add overrides after verifying individual cert fingerprints elsewhere. You should block unencrypted traffic too: use an adblocker on "http://*" or point the http proxy (but not https) to localhost.

I recommend using separate profiles for Google, Facebook, and any other site known to track you across the web (assuming you're not using Tor Browser or some anti-tracking add-on).

CassandraDecember 15, 2016 2:11 AM

@Peter Pearson, @Karin

is there a quick way of un-trusting all (or the bulk of) Certificate Authorities currently trusted by Firefox/PaleMoon (and, possibly, other browsers). Obviously you can go through and do it one-by-one, but that is a little tiresome.

Also, does the process survive upgrades?

For general browsing purposes, I'd like to remove trust from most CAs and re-enable them on an ad hoc basis whilst I browse.

Pete S.December 15, 2016 4:41 AM

@ TG: Here's the official list: https://letsencrypt.org/docs/client-options/ -- I'm sure there's others, but I'd start there.

I used the dehydrated script with NearlyFreeSpeech.net (they have a slightly customized version that calls their API to update certs with the server, but otherwise the ACME stuff is pretty stock). It doesn't require root. Your mileage may vary.

tialaramexDecember 15, 2016 8:26 AM

At least one commenter has pointed at the fact that the Let's Encrypt client software runs on the same machine where the private key is kept. This is in fact only a convenience, for the majority of people who are just trying to get it to work and not focused on producing absolutely best possible security and is not necessary.

You can run a Let's Encrypt client -- including EFF's Certbot (their example client) or some of the others -- using a Certificate Signing Request (CSR) and thus without the client having access to the TLS private key at all. You obviously need to ensure all the names you want on your certificate are listed in the CSR. In this mode you're left to your own devices to manage renewal, key rolling and several other decisions which could otherwise be done by their client automatically, because you've set yourself up as the expert.

KarinDecember 15, 2016 8:59 AM


This disables all the built-in CAs on Linux:

mkdir ~/no-certs
gcc -shared -fPIC -xc -o ~/no-certs/libnssckbi.so /dev/null

Go to Advanced / Certificates / View / Authorities to check (if you didn't start from a clean profile there may be a few to clear out), and make sure https://www.google.com gives an SSL error. You might need to set "browser.xul.error_pages.expert_bad_cert" to true in about:config to be able to accept the cert anyway (verify the fingerprint first!).

meDecember 15, 2016 9:37 AM

@Pete S.,

Probably something along the lines of running certbot as follows:

certbot --standalone --standalone-supported-challenges http-01 --http-01-port 20081 certonly

And then proxy any requests from nginx to certbot:

location /.well-known/acme-challenge/ {
proxy_set_header Host $host;
allow all;

That's it: certbot will request a certificate, the LetsEncrypt server will connect to your site to validate the challenge, the request gets proxied to certbot which responds to the LetsEncrypt server and everybody is happy. certbot will try to save the certificate files in /etc/letsencrypt so you'll have to do some chmod voodoo to make that part work.

CassandraDecember 15, 2016 12:25 PM


Thank-you, that helps a great deal. I should have said I use a Linux platform (amongst others) for Internet-connected data processing.


Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Resilient.