Let's Encrypt issues its 3Bth cert | Hacker News Reader

Let's Encrypt issues its 3Bth cert

search.censys.io

64 pointsdfern20 comments

I'm just glad that Let's Encrypt exists and simply works: never had any problems with certs for my pet projects.

Incredible :)

On a side note: I never realized that all certs issued are publicly listed. This is a pretty big security implication for anyone issuing certs for services that are not intended for public consumption.

If your service's/computer's security requires a hostname to be secret you have big big problems and they aren't the certificate transparency log.

Hostnames are still private information, for example they could be embarrassing and personal. In general private information should not be made public without knowledge and consent.

They also sometimes reveal internal topology, which while it shouldn't be central to security, is often best kept private just as another layer of defence in depth.

The GP is not the first person to discover long after the fact that their internal hostnames have been added to the public log, which might have prompted them to use different hostnames.

It should be made clear that hostnames are posted publically. I just checked and it's not mentioned in the Certbot man page or online documentation, nor mentioned in the log output.

Certificate transparency demands the same from all authorities. This is not limited to LetsEncrypt.

I'm aware, because I read about these things in some depth, but not everyone knows about certificate transparency. Why would they if it isn't highlighted?

As I said, it's not mentioned in the Certbot documentation. There's no warning. It's not obvious at all.

It’s in the LetsEncrypt privacy policy Certbot has you agree to:

> We need to be able to demonstrate to the public, including those who rely on the trustworthiness of our certificates, that our services perform as expected. As a result, we may be unable to delete information, including IP addresses. This information may be made public in a number of ways, including via public API, public repositories, and/or public discussions.

I've never really bought into the argument that DNS zone walking represented any kind of security problem. So what if people know the names I'm using for my computers?

For all the times I've heard people complain about it I have never encountered an actual security situation, or case study, that showed they were an issue. Does anyone know of a security incident that occurred because of publicly releasing internal DNS names? I would like to hear about it.

Here’s one example, where an adversary can use certificate transparency to discover and squat on domains pointed at clouds: https://www.ndss-symposium.org/wp-content/uploads/2018/02/nd...

> all certs issued are publicly listed

By public issuers.

Non-public issuers don't list their certs... until someone stumbles on it and record it, eg:

https://search.censys.io/certificates?q=%28tags.raw%3A+%22un...

Using a wildcard domain (*.agartner.com) helps mask the actual subdomain fyi

So is this the use-case for going through the trouble of having a private Root CA that all your machines trust?

I kind of hate how browsers have pushed this centralized cert system and don't show self signed certs as valid.

It's both understandable, and frustrating, at the same time.

From a threat model perspective, drawing the line where they have doesn't make much sense.

If you can reliably intercept traffic between a host and the internet, then you can get Let's Encrypt (or any other ACME service) to issue a certificate for the host.

If you cannot reliably intercept such traffic, then you can't reliably use a self signed certificate to intercept the traffic.

So, the lock icon basically means "the coffee shop WiFi or your local puppet governement didn't spoof this connection, but AWS, a colo facility, the US/China/etc or a backbone provider may have".

That's much weaker than most people realize.

Edit: Because of this, an unpinned ACME certificate is actually weaker than a pinned self signed certificate for services that only have a few users.

Would you mind to elaborate how A (the ability to intercept traffic) leads to B (the ability to make Let’s Encrypt issue a certificate for the (any?) host? I fail to see the connection

There is a blog post here that describes how to exploit it: https://www.mike-gualtieri.com/posts/chaining-remote-web-vul...

Let's Encrypt issues certs based on challenges. One challenge method is that they make an http request to the domain. If they get the correct response back then they will give you the cert. So what you would do is request a certificate, intercept the challenge, and answer correctly.

Edit: If you did this, it would be show up in certificate transparency logs. So a very alert sysadmin could catch you in the act.

I point to this recent case of a BGP hijack where an attacker got a certificate issued

https://nitter.lacontrevoie.fr/rmhrisk/status/15749933380840...

> So, the lock icon basically means "the coffee shop WiFi or your local puppet governement didn't spoof this connection, but AWS, a colo facility, the US/China/etc or a backbone provider may have".

> That's much weaker than most people realize.

Have you actually tested that? I bet you if you ask the average person "can your coffee shop read your emails" they'll say no, but if you ask "can the NSA read your emails" they'll say yes.

Reply on news.ycombinator.com