5 ms·

Ask HN: Is Let's Encrypt the new swiss crypto ag?

18 points by Coxa 7y ago

Just wondering ... it does seem less far-fetched in the light of the swiss crypto ag revelations.

smoyer 7y ago
Betteridge's Law says "No" ... and given certificates are generated locally, I don't see how the certificates themselves could be compromised. The trust in a certificate (or trust in a false certificate) could potentially be manipulated in by and upstream party.
- 45ure 7y ago
  The 'law' is more of an observation and generally applies to headlines. I feel you are being overly dismissive, as a question is being asked is in a dedicated section. There have been instances of CA's, most notably Symantec, which have turned out to be bad apples. There is a constant stream of news dispelling myths surrounding seemingly reputable firms regarding encryption/privacy. Whether these incidences are related or not, discussions like these need to be afforded a lot more leeway than most, and fleshed out, rather than being stifled.
  - smoyer 7y ago
    I'm not arguing against having the discussion ... my point is that trust in any certificate is reliant on its chain-of-trust and so if Let's Encrypt has this problem, you can't trust other certificates either. But the implication in the head-line is that the NSA/CIA are controlling Let's Encrypt. If that's true, then we've got a real problem ... on the other hand, I think other CAs have shown that, through incompetence or malice, they can't always be trusted either.
    - nullc 7y ago
      HTTPS certs provide extraordinary limited security in any case, there is no need to single out lets encrypt. If you can receive a http request destined to the target domain (e.g. via MITM near the real target, DNS hijacking, or route hijacking, or MITM near a CA) then you can get a cert issued for that domain by pretty much any popular CA. With security so limited what would be the purpose of compromising lets encrypt?
      - nullc 7y ago
        Massive downvotes but no responses. Is it because you accept that the security provided by HTTPS is limited but don't like people calling that out? It's better than nothing. But it is my perspective that as technical experts any time we are not absolutely frank about the limitations of the current model against powerful MITM attackers we are behaving unethically. There is absolutely no reason for any major state attacker to compromise letsencrypt. Beyond the weaknesses I enumerated above state actors have their own CAs which are accepted by browsers and pinning is effectively dead ( https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning#Browser_support_and_deprecation https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning#Browse... ). What exactly could a state actor hope to accomplish by compromising letsencrypt that they couldn't already do more easily and stealthily?
    - JohnFen 7y ago
      > if Let's Encrypt has this problem, you can't trust other certificates either. To be perfectly honest, I don't really trust the other certs, either. I mean, I pretty much have to, and having a mainstream CA sign a cert does provide a bit of reassurance -- but only a bit. I don't really consider CA signing to mean that the cert is "trustworthy", because I don't really trust those CAs, so if they're the anchor for a chain of trust, then the chain of trust is weak.
infogulch 7y ago
Are you familiar with how certificates and CAs work in general? You don't receive a certificate from the CA, they just sign and attest that the one you made is owned by you. The ways CAs go bad is not breaking any crypto but by signing a certificate that you don't own. This vulnerability is well known and LE takes industry-leading steps to mitigate it via the certificate transparency program which is a permanent auditable log of all certificates they sign.
- Coxa 7y ago
  From my understanding of the certificate transparency program does not mitigate the threat of them simply not disclosing a certificate they signed. Ultimately this still gives them MitM capabilities as long as they control the traffic or am I mistaken?
  - DenseComet 7y ago
    When certificates are submitted to CT logs, they are given Signed Certificate Timestamp by the log, which can be attached to the certificate. Chrome and other major browsers require that every certificate has them attached and signed by a trusted log operator, guaranteeing that each certificate is submitted to a CT log. https://github.com/chromium/ct-policy/blob/master/ct_policy.md#qualifying-certificate https://github.com/chromium/ct-policy/blob/master/ct_policy....
    - Coxa 7y ago
      Seems like this is currently disabled in Firefox [1]. Do you have any sources for Safari or MS Edge? [1] https://wiki.mozilla.org/PKI:CT https://wiki.mozilla.org/PKI:CT
  - infogulch 7y ago
    Yes, this property (CAs are capable of creating and signing near-arbitrary certs) is inherent in the concept of Certificate Authorities in general, and the log doesn't automatically fix that because nothing can. But auditors regularly check served certificates against these logs and report unlogged certificates automatically. This can be verified in your browser with things like OCSP stapling. You may find this useful: http://www.certificate-transparency.org/how-ct-works http://www.certificate-transparency.org/how-ct-works
drummer 7y ago
I suppose it would be trivial for them to issue compromised certificates or record the private key in a targetted attack for a specific domain without anyone noticing.
- seanhunter 7y ago
  Would be trivial except for the fact that they don't issue certificates.
- advisedwang 7y ago
  During normal certificate issuance, they do not generate or see the private key, so they can't compromise the certs they sign for you. Like any other CA, they do have the technical ability to sign arbitrary other certs, so could issue a cert for MITM. As some other comments show, certificate transparency is starting to reduce this risk.
  - jeffrallen 7y ago
    LE does not see the private key but certbot does. Who audits certbot?
    - nwallin 7y ago
      Anyone. It's open source. You can if you'd like. https://github.com/certbot/certbot https://github.com/certbot/certbot
tree3 7y ago
Why are you specifically targeting LE with this post? Why not other CAs?
- Coxa 7y ago
  Because I want to use LE and not other CAs.
  - throwaway3neu94 7y ago
    That's misguided (I'm assuming you're the server admin). Whether you use any specific CA, like LE, or not, has no security impact. It's about what your users trust and you don't control that.
    - Coxa 7y ago
      In an ideal world I would say you're right. In practice they don't even know who they trust.
jeffrallen 7y ago
As a centralized piece of software that has made itself responsible for safely massaging millions of private keys, certbot would certainly be a juicy target for NSA to compromise.

18 points by Coxa 7y ago

Just wondering ... it does seem less far-fetched in the light of the swiss crypto ag revelations.

Betteridge's Law says "No" ... and given certificates are generated locally, I don't see how the certificates themselves could be compromised. The trust in a certificate (or trust in a false certificate) could potentially be manipulated in by and upstream party.

45ure 7y ago
The 'law' is more of an observation and generally applies to headlines. I feel you are being overly dismissive, as a question is being asked is in a dedicated section. There have been instances of CA's, most notably Symantec, which have turned out to be bad apples. There is a constant stream of news dispelling myths surrounding seemingly reputable firms regarding encryption/privacy. Whether these incidences are related or not, discussions like these need to be afforded a lot more leeway than most, and fleshed out, rather than being stifled.
- smoyer 7y ago
  I'm not arguing against having the discussion ... my point is that trust in any certificate is reliant on its chain-of-trust and so if Let's Encrypt has this problem, you can't trust other certificates either. But the implication in the head-line is that the NSA/CIA are controlling Let's Encrypt. If that's true, then we've got a real problem ... on the other hand, I think other CAs have shown that, through incompetence or malice, they can't always be trusted either.
  - nullc 7y ago
    HTTPS certs provide extraordinary limited security in any case, there is no need to single out lets encrypt. If you can receive a http request destined to the target domain (e.g. via MITM near the real target, DNS hijacking, or route hijacking, or MITM near a CA) then you can get a cert issued for that domain by pretty much any popular CA. With security so limited what would be the purpose of compromising lets encrypt?
    - nullc 7y ago
      Massive downvotes but no responses. Is it because you accept that the security provided by HTTPS is limited but don't like people calling that out? It's better than nothing. But it is my perspective that as technical experts any time we are not absolutely frank about the limitations of the current model against powerful MITM attackers we are behaving unethically. There is absolutely no reason for any major state attacker to compromise letsencrypt. Beyond the weaknesses I enumerated above state actors have their own CAs which are accepted by browsers and pinning is effectively dead ( https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning#Browser_support_and_deprecation https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning#Browse... ). What exactly could a state actor hope to accomplish by compromising letsencrypt that they couldn't already do more easily and stealthily?
  - JohnFen 7y ago
    > if Let's Encrypt has this problem, you can't trust other certificates either. To be perfectly honest, I don't really trust the other certs, either. I mean, I pretty much have to, and having a mainstream CA sign a cert does provide a bit of reassurance -- but only a bit. I don't really consider CA signing to mean that the cert is "trustworthy", because I don't really trust those CAs, so if they're the anchor for a chain of trust, then the chain of trust is weak.

infogulch 7y ago

Are you familiar with how certificates and CAs work in general? You don't receive a certificate from the CA, they just sign and attest that the one you made is owned by you. The ways CAs go bad is not breaking any crypto but by signing a certificate that you don't own. This vulnerability is well known and LE takes industry-leading steps to mitigate it via the certificate transparency program which is a permanent auditable log of all certificates they sign.

Coxa 7y ago
From my understanding of the certificate transparency program does not mitigate the threat of them simply not disclosing a certificate they signed. Ultimately this still gives them MitM capabilities as long as they control the traffic or am I mistaken?
- DenseComet 7y ago
  When certificates are submitted to CT logs, they are given Signed Certificate Timestamp by the log, which can be attached to the certificate. Chrome and other major browsers require that every certificate has them attached and signed by a trusted log operator, guaranteeing that each certificate is submitted to a CT log. https://github.com/chromium/ct-policy/blob/master/ct_policy.md#qualifying-certificate https://github.com/chromium/ct-policy/blob/master/ct_policy....
  - Coxa 7y ago
    Seems like this is currently disabled in Firefox [1]. Do you have any sources for Safari or MS Edge? [1] https://wiki.mozilla.org/PKI:CT https://wiki.mozilla.org/PKI:CT
- infogulch 7y ago
  Yes, this property (CAs are capable of creating and signing near-arbitrary certs) is inherent in the concept of Certificate Authorities in general, and the log doesn't automatically fix that because nothing can. But auditors regularly check served certificates against these logs and report unlogged certificates automatically. This can be verified in your browser with things like OCSP stapling. You may find this useful: http://www.certificate-transparency.org/how-ct-works http://www.certificate-transparency.org/how-ct-works

drummer 7y ago

I suppose it would be trivial for them to issue compromised certificates or record the private key in a targetted attack for a specific domain without anyone noticing.

seanhunter 7y ago
Would be trivial except for the fact that they don't issue certificates.
advisedwang 7y ago
During normal certificate issuance, they do not generate or see the private key, so they can't compromise the certs they sign for you. Like any other CA, they do have the technical ability to sign arbitrary other certs, so could issue a cert for MITM. As some other comments show, certificate transparency is starting to reduce this risk.
- jeffrallen 7y ago
  LE does not see the private key but certbot does. Who audits certbot?
  - nwallin 7y ago
    Anyone. It's open source. You can if you'd like. https://github.com/certbot/certbot https://github.com/certbot/certbot

tree3 7y ago

Why are you specifically targeting LE with this post? Why not other CAs?

Coxa 7y ago
Because I want to use LE and not other CAs.
- throwaway3neu94 7y ago
  That's misguided (I'm assuming you're the server admin). Whether you use any specific CA, like LE, or not, has no security impact. It's about what your users trust and you don't control that.
  - Coxa 7y ago
    In an ideal world I would say you're right. In practice they don't even know who they trust.

jeffrallen 7y ago

As a centralized piece of software that has made itself responsible for safely massaging millions of private keys, certbot would certainly be a juicy target for NSA to compromise.