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.
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.
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.
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
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.
> 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.
20 comments
[ 3.4 ms ] story [ 61.4 ms ] threadOn 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.
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.
As I said, it's not mentioned in the Certbot documentation. There's no warning. It's not obvious at all.
> 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.
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.
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...
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.
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.
https://nitter.lacontrevoie.fr/rmhrisk/status/15749933380840...
> 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.