4 ms·

Let's Encrypt issues its 3Bth cert

64 points by dfern 4y ago

below43 4y ago
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.
- ehPReth 4y ago
  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.
  - jlokier 4y ago
    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.
    - tinus_hn 4y ago
      Certificate transparency demands the same from all authorities. This is not limited to LetsEncrypt.
      - jlokier 4y ago
        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.
        tinus_hn 4y ago
        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.
    - AndyMcConachie 4y ago
      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.
      - ericpauley 4y ago
        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/ndss2018_06A-4_Borgolte_paper.pdf https://www.ndss-symposium.org/wp-content/uploads/2018/02/nd...
- justsomehnguy 4y ago
  > 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+%22untrusted%22%29+AND+tags.raw%3A+%22unexpired%22& https://search.censys.io/certificates?q=%28tags.raw%3A+%22un...
- agartner 4y ago
  Using a wildcard domain (*.agartner.com) helps mask the actual subdomain fyi
- jaxrtech 4y ago
  So is this the use-case for going through the trouble of having a private Root CA that all your machines trust?
kotborealis 4y ago
I'm just glad that Let's Encrypt exists and simply works: never had any problems with certs for my pet projects.
plopz 4y ago
I kind of hate how browsers have pushed this centralized cert system and don't show self signed certs as valid.
- seanw444 4y ago
  It's both understandable, and frustrating, at the same time.
- hedora 4y ago
  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.
  - qpx 4y ago
    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
    - dolni 4y ago
      There is a blog post here that describes how to exploit it: https://www.mike-gualtieri.com/posts/chaining-remote-web-vulnerabilities-to-abuse-lets-encrypt https://www.mike-gualtieri.com/posts/chaining-remote-web-vul...
    - im3w1l 4y ago
      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.

64 points by dfern 4y ago

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.

ehPReth 4y ago
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.
- jlokier 4y ago
  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.
  - tinus_hn 4y ago
    Certificate transparency demands the same from all authorities. This is not limited to LetsEncrypt.
    - jlokier 4y ago
      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.
      - tinus_hn 4y ago
        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.
  - AndyMcConachie 4y ago
    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.
    - ericpauley 4y ago
      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/ndss2018_06A-4_Borgolte_paper.pdf https://www.ndss-symposium.org/wp-content/uploads/2018/02/nd...
justsomehnguy 4y ago
> 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+%22untrusted%22%29+AND+tags.raw%3A+%22unexpired%22& https://search.censys.io/certificates?q=%28tags.raw%3A+%22un...
agartner 4y ago
Using a wildcard domain (*.agartner.com) helps mask the actual subdomain fyi
jaxrtech 4y ago
So is this the use-case for going through the trouble of having a private Root CA that all your machines trust?

kotborealis 4y ago

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

plopz 4y ago

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

seanw444 4y ago
It's both understandable, and frustrating, at the same time.
hedora 4y ago
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.
- qpx 4y ago
  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
  - dolni 4y ago
    There is a blog post here that describes how to exploit it: https://www.mike-gualtieri.com/posts/chaining-remote-web-vulnerabilities-to-abuse-lets-encrypt https://www.mike-gualtieri.com/posts/chaining-remote-web-vul...
  - im3w1l 4y ago
    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.