
 Let's Encrypt makes certs for 30% of web domains - lsb
https://www.leebutterman.com/2019/08/05/analyzing-hundreds-of-millions-of-ssl-connections.html
======
hannob
A few of these things, while not necessarily wrong, should be put into
context.

E.g. "Hundreds of thousands of domains' certs expire after 2099". Yeah, but no
publicly trusted certs. They're capped at a bit more than 2 years and there's
a discussion to cap them even more.

The certs they're seeing are almost certainly mostly: "let's create a test
selfsigned cert for this host. how long should it last? let's type in a large
number so we aren't bothered by it any time soon."

~~~
tialaramex
Yes, but...

Historically there were some certs that kept getting grandfathered in after
lifetimes were restricted because they'd been issued before there were any
rules - maybe ten years to expire or even more? I think the last of those
probably went away because of the Symantec distrust (not that they were issued
by Symantec, but they were issued by a CA which was bought by a CA which in
turn was bought by Symantec before it was distrusted) and also of course
they'd have either MD5 or SHA-1 signatures, which are not accepted today
anyway.

There were still certs issued right up until the end of March 2018 with the
old 39 month lifetime maximum. You can see them most easily in the annualised
CT logs for 2021. A while back CT log operators realised that logs just get
longer (of course) and so they would need to periodically make new ones and
archive the old ones. Very quickly they struck upon the idea of annualising
them, instead of running FooBar Log, run FooBar Log 2019, FooBar Log 2020 and
FooBar Log 2021, and then require any submissions to use the log matching the
year of expiry of the certificate they were logging. This way you can archive
FooBar Log 2019 when people get back from holidays after celebrating New Year
2020, all the certs in that log are expired anyway now.

I guess that today the last of those 39 month certs will actually expire
before a brand new 825 day cert, but they are still out there, so don't write
software that assumes leaf certs can't last more than 825 days just yet.

~~~
quink
Minor point - SHA1 root CA certs are trusted by identity, so SHA1 is of no
consequence.

------
sschueller
This kind of centralization is not good. Even thought let's encrypt is non
profit and has a very good service record. We desperately need more like it
spread around the globe.

~~~
FDSGSG
What problems would decentralization solve here?

~~~
mmalone
Competition is always good. For one, a completely decoupled and separately
managed system on a different stack would improve availability of ACME-based
certificates. It would also reduce the concentration of trust in one entity.
While LE is awesome, the target on their back is only getting bigger.

For what it's worth, I'm pretty sure even Let's Encrypt wants to see
competitors to Let's Encrypt.

~~~
progval
> It would also reduce the concentration of trust in one entity.

No it wouldn't. If there are 9999 CAs, you need to trust every single one of
them.

A better argument for having multiple CAs is that it would increase resilience
(against takedowns, bugs, money running out, etc.)

~~~
ryacko
Convergence was a project to have multiple notaries to vouch for a TLS
certificate instead of a chain of CAs.

There are way to decentralize the internet, but there never will be much
interest for it.

~~~
auslander
Extremely funny video by Moxie Marlinspike about it:

[https://m.youtube.com/watch?v=Z7Wl2FW2TcA](https://m.youtube.com/watch?v=Z7Wl2FW2TcA)

~~~
ryacko
Thanks, in some twist of irony, I’ve mistaken Convergence for Perspectives.

------
tpmx
The GCP self-serving platform for certs is very welcome, but still kinda
janky. You end up waiting hours for their batch jobs to run at unknown cycles.

Let's encrypt is awesome because it's instantaneous! You'd think Google would
understand that aspect.

Edit: GCP people: Please give us a an explicit "retry" button to press when
we've set up the DNS records. (I'm talking about the Google Cloud Balancing
Service here. The UI was awesome up until the point it wasn't. The one thing
lacking was a "retry" button.)

~~~
briffle
For GKE, in beta, you can tell the ingress to get a TLS certificate
automatically. Google will manage the whole process. The weird thing is, it
uses letsencrypt. Since Google has their own Root CA, that seemed like an
interesting choice.

[0] [https://cloud.google.com/kubernetes-engine/docs/how-
to/manag...](https://cloud.google.com/kubernetes-engine/docs/how-to/managed-
certs)

~~~
dannyw
Maybe they don’t have a publicly available issuance (challenge/response, ACME,
etc) infrastructure for their Root CA.

Or maybe they just want to keep google CA, limited to Google properties. The
same way you put things in googleusercontent.com and not google.com.

------
lsb
Author here. I'd figured they were big, but I had no idea that big until I did
a www-wide TLS scan. Here for questions

~~~
tialaramex
You list the ciphersuite that got chosen for each connection, but I think this
could use at least a caveat explaining that the way this works means you'd
need to do a LOT more work to figure out what the servers might have agreed to
do for some other client.

What I mean here is that TLS up until TLS 1.2 goes like this:

Client: "Hi, I know ciphersuites A, B, C, D, E, F and G"

Server: "OK, let's do C"

And so you can't tell whether the server actually knows A, B, D, E, F, G or
even I through Z. They just decided to pick C this time for some reason.

In TLS 1.3 it's sort of better (all of the ciphersuites you shouldn't use
don't exist any more) and sort of worse because now it goes:

Client: "Hi, let's do method B, I'll go first, 123456 and a goldfish and the
colour yellow"

Server: "Cool, method B works for me, I pick 567890, a swan and mauve"

Probably all TLS 1.3 servers today are willing to do anything method not just
method B, since all the methods are shiny and new. But perhaps not, and you
can't tell except by failing the connection which takes more round trips.

~~~
achillean
With regards to the supported SSL/ TLS versions you can get that information
from Shodan. We do explicit handshakes using each version. For example, here
is an overview of servers supporting TLS 1.3:

[https://www.shodan.io/report/unklm3m7](https://www.shodan.io/report/unklm3m7)

Disclaimer: I run Shodan.

------
gator-io
When LetsEncrypt came out, I wrote a service (free) that monitors LetsEncrypt
certs externally and sends alerts when they are close to expiring. It can be
used as a backup to the automatic emails that are sent:

[https://letsmonitor.org](https://letsmonitor.org)

~~~
kumarm
Nice. Couple of things:

1\. Why not integrate and let user monitor all their SSL certs for a domain in
a single shot? Like retrieve all certs for a domain (similar to
[https://crt.sh](https://crt.sh) identity like search result)

2\. When registered, I did not receive an email confirmation/validation. So I
am not sure if I will get an email before my certs are up for renewal.

------
nickpsecurity
They give away paid products for free. Products that Google penalizes you for
not having. Then, many people needing or wanting that product used their free
alternative.

I still don’t know if that vs version with more paying customers is a good
thing in long run. Good for now, though.

~~~
tracker1
In practice, most CAs are over-charging for what should be highly automated
(like LE). Other CAs also push EV and other certs that cost more, but don't
really add much value in practice.

In the end, the "free" version is good enough for most people. I would suggest
if you're using it in a commercial environment that you consider setting up a
scheduled donation. Which likely does help a lot for what they are doing.

------
sideshowmel
Certbot is awesome! It really gives you no excuse not to provide https on your
website.

------
FreeHugs
One thing I don't understand about Let's Encrypt:

Why do the certificates expire after 90 days? What would be the downside of
giving them a longer expiration time?

~~~
canofbars
The security aspects have been covered but there is another advantage. When
people get a 2 year certificate they very often forget to renew it until their
website becomes broken. With a 90 day expiry you are pretty much forced to add
a task to crontab that renews automatically.

------
fireattack
>Almost 1.6M domains had a cert that had recently expired (in July, the month
of the scan). Almost 3.7M domains had a cert that expired in 2019 (the year of
the scan). Over 9.6M domains had a cert that expired in the 2010s!

This doesn't make sense. Even assuming you included the ones that had expired
certs in "had a cert that expired in the 2010s", it would only be
1.6+3.7~=5.3M.

Where does the rest 4.3M come from?

~~~
hcs
Those are certs that not-so-recently expired, the heading is "Millions of
certs served have expired".

~~~
fireattack
Ah, you're right.

------
hanoz
Good. Now who's going to do the same for domain names? And why hasn't this
happened yet?

~~~
prirun
The thing that irks me about domain names is that registrars hold onto expired
domain names and put them in their domain auctions. ICANN needs a new rule
that registrars can't hang onto expired domain names for more than 30-90 days.

From [https://www.godaddy.com/help/when-can-i-register-an-
expired-...](https://www.godaddy.com/help/when-can-i-register-an-expired-
domain-name-572):

"If the domain name is not renewed, redeemed, or purchased through an auction,
it is returned to its registry. _The registry determines when the domain name
is released again for registration._ "

------
daveheq
The article says "Current SSL cert lifetime best practices put lifetimes at 90
days" but SSL is deprecated... so its lifetime best practice is 0 days.

------
manishsharan
can someone please share how they deploy/distribute Let's encrypt certificates
with auto renewal on load balanced multiple EC2 servers for the same dns name.
I had tried this a while but had to give up and just bought SSL certs which I
then include in my EC2 image.

~~~
markstos
If your load balancers are AWS load balancers, you are doing it wrong. AWS
provides their own free certificates that work the load balancer and they
handle renewal as well. Let's Encrypt would be an unnecessary additional
dependency and complexity.

(At least if you are comfortable terminating your SSL at the load balancer. If
you plan to use SSL between the AWS LBs and your EC2 instances, then AWS certs
don't work there and you'll need to provision them yourself using something
like LE).

~~~
owenmarshall
> (At least if you are comfortable terminating your SSL at the load balancer.
> If you plan to use SSL between the AWS LBs and your EC2 instances, then AWS
> certs don't work there and you'll need to provision them yourself using
> something like LE).

Interesting note - ALBs/ELBs (NLBs with SSL termination as well, I would
assume, but I am not sure) do not perform validation of your backend
certificate. You can terminate at the load balancer and use an expired self
signed SHA1 cert for all AWS cares.

~~~
abofh
Elbs do support public key verification of the backends (search for Enable
backend authentication). I believe you are correct wrt Albs and nlbs, and in
neither case does it check the cert ttbomlk, just the public key.

------
mpaxd
Most hosting businesses have moved to LE. Hell even admin panels like Plesk
have it out of the box.

------
bane
Could be concerning, see

[https://blog.talosintelligence.com/2019/04/seaturtle.html](https://blog.talosintelligence.com/2019/04/seaturtle.html)

~~~
lucb1e
If you just want to post a link, I'd rather you submit a story with a title
than put a "see, this is concerning:" in the comments.

Moreover, I don't see how this article is relevant to Let's Encrypt's
popularity. There are only two mentions in the article about LE, this is one:
"These actors use Let's Encrypts, Comodo, Sectigo, and self-signed
certificates in their MitM servers to gain the initial round of credentials."
So they use normal public infrastructure to get certificates? That is
concerning, how?

~~~
bane
You are most welcome.

~~~
lucb1e
Not sure what you mean by that. It's clearly sarcastic but I can't tell what
you mean to say.

------
sigmonsays
does anyone care that letsencrypt and other CAs are sharing their certificate
requests to indexers?

It allows someone to discover every one of your HTTPS certificates that you've
requested.

For instance, here is some free rabbitmq clusters to use...
[https://censys.io/certificates?q=parsed.extensions.subject_a...](https://censys.io/certificates?q=parsed.extensions.subject_alt_name.dns_names%3A+rabbitmq)

Default password of guest/guest works on [http://rabbitmq.avtomain-
crypto.com/#/](http://rabbitmq.avtomain-crypto.com/#/)

~~~
tialaramex
I have some tremendously bad news if you thought that publicly accessible
services on the Internet are secret.

Several distinct outfits sell what they call "passive DNS" which is a feed of
snooped DNS queries and their answers, minus any identifying information. So
you don't need a certificate, if anybody, anywhere, looks up the name and it
has an answer then these systems will tell you what it is.

The records come through roughly like this:

name: 'news.ycombinator.com'

type: 'A'

value: '209.216.230.240'

------
buboard
SSL certs sound like something that should be in a blockchain. Why isnt it?

~~~
hitpointdrew
Because where is the incentive? Why would anyone be a "miner"? What reward
would there be?

~~~
buboard
could be a nonprofit, like letsencrypt

~~~
Biganon
That's not the point. In a decentralized system, every actor needs an
incentive to mine new blocks in the chain. In cryptocurrencies, the incentive
is the creation of new money attached to your name. But what if we're not
dealing with a currency, but something else?

~~~
buboard
you are thinking of bitcoin. there are many different blockchain setups . and
there is already namecoin

~~~
MertsA
The whole point of providing an incentive is to give a bunch of decentralized
miners a reason to devote a reasonable amount of processing power to securing
the blockchain. If there's only a single non-profit mining the chain, because
why on earth would a bunch of other people throw money away for no reward,
then for an attacker it's substantially more feasible to perform a 51% attack.

For Bitcoin there's currently around $132,000 of incentive for mining given
out every 10 minutes. In a race to the bottom that basically equates to a bit
under $132,000 worth of compute resources expended for mining every 10
minutes. An attacker with enough resources to perform an attack on Bitcoin
would have to spend more than that $132,000 every 10 minutes and keep it up
for the duration of their attack.

"Blockchain" for random hip projects more often than not is just buzzword
nonsense that does nothing to improve security. A blockchain without mining is
just silly, mining only works when it provides sufficient incentive such that
attacking that blockchain is much more expensive than any payoff of attacking
it is worth.

