11 ms·

Let's Encrypt is one of the best things that happened to the web recently. I wish we had more choices though. Relying so much on a single party is unnerving.

nofunsir 8y ago
Do we have conclusive evidence yet that LE is not a honey pot? I mean, if I were the NSA...
- deleted 8y ago
  [deleted]
- jimktrains2 8y ago
  What use would it be? You don't send LE the private key, and if the NSA was just going to forge TLS certs, they wouldn't need LE to do it.
- schoen 8y ago
  What would you do with this power? Let's Encrypt certificates are public and don't involve any knowledge of subscribers' private keys.
  - trash_panda 8y ago
    You don't need to have private keys to exploit this scenario. Let's say you own example.com, and you add a certificate by Let's Encrypt. If Let's Encrypt is a malicious actor, they could MiTM a connection to your site, and present a VALID certificate to the target user, as they hold the private keys used to sign the public certificate. The value of a CA is that it's a trusted 3rd party that holds a private key used to sign public keys (certificates). Never a CA should get hold of your private keys.
    - schoen 8y ago
      > If Let's Encrypt is a malicious actor, they could MiTM a connection to your site, and present a VALID certificate to the target user, as they hold the private keys used to sign the public certificate. I'm not sure if you're referring to CAs' ability to issue fake certificates, or if you're suggesting that the certificate issuer can directly MITM connections. CAs' ability to issue fake certificates is a very serious concern which has led to the Certificate Transparency system where all issued certificates must be publicly disclosed (in a system outside of the issuer's control) in order to be publicly trusted. A site doesn't have to use a certificate from a particular CA in order to be vulnerable to misissuance by that CA, as in the Iranian Comodo and DigiNotar attacks, where Gmail was briefly vulnerable to MITM attacked involving misissued certificates from these CAs even though it didn't normally use certificates from either of them at all. CAs don't have the ability to use their signing keys directly to MITM connections involving certificates that they issued, because the signing key isn't used for any cryptographic purpose other than validating that the certificate (which refers to the site's public key) was validly issued.
      - trash_panda 8y ago
        Of course, you're right. My phrasing was not the best. The rogue CA would need to perform a classical MiTM as all the other mortals do, having access to the signing keys does not give you special MiTM powers, other than when you actually are able to conduct a MiTM through other means, you'll have valid certs to intercept the connection. Totally agree with your point about trust being a very hard problem to solve, that's why CAs first came in to place, and now we have CT (which is not widely adopted yet). It is a problem that has no clear and definite solution yet. Edit: Also, CT is no magical solution. It's just another "node" in the graph of trust we're establishing. As many other things have in the past, the CT system itself could also fail.
        roblabla 8y ago
        Chrome requires certs to be published in CT to trust it[0], since chrome 68[1]. Because of this, I would believe CT is widely adopted. [0]: http://www.certificate-transparency.org/certificate-transparency-in-chrome http://www.certificate-transparency.org/certificate-transpar... , Certificate Inclusion Check [1]: https://groups.google.com/a/chromium.org/forum/#!msg/ct-policy/Qqr59r6yn1A/2t0bWblZBgAJ https://groups.google.com/a/chromium.org/forum/#!msg/ct-poli...
    - kodablah 8y ago
      > If Let's Encrypt is a malicious actor, they could MiTM a connection to your site, and present a VALID certificate to the target user, as they hold the private keys used to sign the public certificate. And if they were able to turn off certificate transparency logs or targeted users only without it (or a hacked browser or whatever) to keep site owners from knowing about invalid certs being given.
- trash_panda 8y ago
  If it's an NSA honeypot it will still be a positive thing for 99% of use cases. Also, why would they do this? It's smarter to compromise the existing CAs.
- 2RTZZSro 8y ago
  HTTPS security model is fundamentally broken to meet the needs of the junta. National Security Letters can be used to "legally" obtain root certificate keys of all Root CAs even remotely affiliated with the United States. You must be extremely naive to believe that the NSA has not already collected all Root CA keys relevant to operations within USA borders. NSL also tend to forbid disclosure of the existence of the NSL, so you will never know that the Root CA is compromised. If you as a Root CA disclose the existence of such a NSL, MS-13 might pay you a visit, and you might unfortunately show up on a obituary in a newspaper nobody reads.
  - Ajedi32 8y ago
    If this were something the NSA were actually doing, wouldn't we have noticed it by now via the rogue certificates showing up in certificate transparency logs?
- parliament32 8y ago
  It's a valid question, with two possible threat models: 1) the honeypot uses your private keys to MITM connections Let's Encrypt doesn't handle your private keys. You generate them yourself, and submit a CRL to LE to get a cert issued. They have no knowledge of your private key. 2) the honeypot issues fake certs Let's Encrypt submits a log of every cert issued, see https://crt.sh/ https://crt.sh/ . To verify, it'd be pretty trivial to create a browser extension (if one doesn't exist already) that checks whether certs you encounter appear in the certificate log.
  - tialaramex 8y ago
    For CT the finished system involves browsers checking that the server can prove its certificates were logged (the ones you get from Let's Encrypt have such proof embedded) and periodically talking to Log Monitors (e.g. owned by your browser vendor) about proofs it has seen. If somebody has seen a proof that is contradicted by the published log state this means the Logs involved are corrupt. If an otherwise authentic cert is shown without proofs or those proofs are bogus the cert may have been unlogged for nefarious reasons, it shouldn't be accepted and needs reporting Chrome has the start of this, it checks for the proofs. Firefox is getting roughly the same feature "soon". But the finished system with all bells and whistles is probably a year or five away. Good news is that even unfinished CT has been very effective.
- deleted 8y ago
  [deleted]
- zip1234 8y ago
  Any CA could be a honeypot. I would say LE is less likely because so much of what they do is in the open.
3pt14159 8y ago
It is good, but it is annoying that it came out before we were able to properly lock down domains to cert authorities via DNS. It used to be that a malactor had to buy a new cert when they owned part of your backend if they weren't able to get your private keys. Now they can just use Let's Encrypt.
- schoen 8y ago
  Can you clarify what restrictions you'd like to see in place? I didn't quite follow this, but if you can describe what you want to see, I might be able to describe a way to do it or request that it be created.
  - 3pt14159 8y ago
    It's fine now, following CAA records is now mandatory, but prior to 2017 we didn't and even now most websites don't use it. CAA should be mandatory in a Let's Encrypted world because it's now trivial to create a HTTPS cert. It no longer requires stolen credit card details.
    - schoen 8y ago
      Thanks. I'm also hoping that some day there will be a direct domain-registrar-to-CA authentication protocol of some sort!
      - eldridgea 8y ago
        More from the authoritative DNS servers than the registrar but with DNSSEC enabled, DANE[0] is a pretty good system. Google deemed the failure rate of ~2% too high but I hold out hope that banks and other high value targets will use DANE in tandem with the traditional HTTPs CAs and use something like HSTS except instead of requiring HTTPS for a particular domain, will require DANE. Maybe something like viewing your account will accpet a CA signed cert, but an actual money transfer goes through a subdomain that required DANE. [0] https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...

nofunsir 8y ago

Do we have conclusive evidence yet that LE is not a honey pot? I mean, if I were the NSA...

deleted 8y ago
[deleted]
jimktrains2 8y ago
What use would it be? You don't send LE the private key, and if the NSA was just going to forge TLS certs, they wouldn't need LE to do it.
schoen 8y ago
What would you do with this power? Let's Encrypt certificates are public and don't involve any knowledge of subscribers' private keys.
- trash_panda 8y ago
  You don't need to have private keys to exploit this scenario. Let's say you own example.com, and you add a certificate by Let's Encrypt. If Let's Encrypt is a malicious actor, they could MiTM a connection to your site, and present a VALID certificate to the target user, as they hold the private keys used to sign the public certificate. The value of a CA is that it's a trusted 3rd party that holds a private key used to sign public keys (certificates). Never a CA should get hold of your private keys.
  - schoen 8y ago
    > If Let's Encrypt is a malicious actor, they could MiTM a connection to your site, and present a VALID certificate to the target user, as they hold the private keys used to sign the public certificate. I'm not sure if you're referring to CAs' ability to issue fake certificates, or if you're suggesting that the certificate issuer can directly MITM connections. CAs' ability to issue fake certificates is a very serious concern which has led to the Certificate Transparency system where all issued certificates must be publicly disclosed (in a system outside of the issuer's control) in order to be publicly trusted. A site doesn't have to use a certificate from a particular CA in order to be vulnerable to misissuance by that CA, as in the Iranian Comodo and DigiNotar attacks, where Gmail was briefly vulnerable to MITM attacked involving misissued certificates from these CAs even though it didn't normally use certificates from either of them at all. CAs don't have the ability to use their signing keys directly to MITM connections involving certificates that they issued, because the signing key isn't used for any cryptographic purpose other than validating that the certificate (which refers to the site's public key) was validly issued.
    - trash_panda 8y ago
      Of course, you're right. My phrasing was not the best. The rogue CA would need to perform a classical MiTM as all the other mortals do, having access to the signing keys does not give you special MiTM powers, other than when you actually are able to conduct a MiTM through other means, you'll have valid certs to intercept the connection. Totally agree with your point about trust being a very hard problem to solve, that's why CAs first came in to place, and now we have CT (which is not widely adopted yet). It is a problem that has no clear and definite solution yet. Edit: Also, CT is no magical solution. It's just another "node" in the graph of trust we're establishing. As many other things have in the past, the CT system itself could also fail.
      - roblabla 8y ago
        Chrome requires certs to be published in CT to trust it[0], since chrome 68[1]. Because of this, I would believe CT is widely adopted. [0]: http://www.certificate-transparency.org/certificate-transparency-in-chrome http://www.certificate-transparency.org/certificate-transpar... , Certificate Inclusion Check [1]: https://groups.google.com/a/chromium.org/forum/#!msg/ct-policy/Qqr59r6yn1A/2t0bWblZBgAJ https://groups.google.com/a/chromium.org/forum/#!msg/ct-poli...
  - kodablah 8y ago
    > If Let's Encrypt is a malicious actor, they could MiTM a connection to your site, and present a VALID certificate to the target user, as they hold the private keys used to sign the public certificate. And if they were able to turn off certificate transparency logs or targeted users only without it (or a hacked browser or whatever) to keep site owners from knowing about invalid certs being given.
trash_panda 8y ago
If it's an NSA honeypot it will still be a positive thing for 99% of use cases. Also, why would they do this? It's smarter to compromise the existing CAs.
2RTZZSro 8y ago
HTTPS security model is fundamentally broken to meet the needs of the junta. National Security Letters can be used to "legally" obtain root certificate keys of all Root CAs even remotely affiliated with the United States. You must be extremely naive to believe that the NSA has not already collected all Root CA keys relevant to operations within USA borders. NSL also tend to forbid disclosure of the existence of the NSL, so you will never know that the Root CA is compromised. If you as a Root CA disclose the existence of such a NSL, MS-13 might pay you a visit, and you might unfortunately show up on a obituary in a newspaper nobody reads.
- Ajedi32 8y ago
  If this were something the NSA were actually doing, wouldn't we have noticed it by now via the rogue certificates showing up in certificate transparency logs?
parliament32 8y ago
It's a valid question, with two possible threat models: 1) the honeypot uses your private keys to MITM connections Let's Encrypt doesn't handle your private keys. You generate them yourself, and submit a CRL to LE to get a cert issued. They have no knowledge of your private key. 2) the honeypot issues fake certs Let's Encrypt submits a log of every cert issued, see https://crt.sh/ https://crt.sh/ . To verify, it'd be pretty trivial to create a browser extension (if one doesn't exist already) that checks whether certs you encounter appear in the certificate log.
- tialaramex 8y ago
  For CT the finished system involves browsers checking that the server can prove its certificates were logged (the ones you get from Let's Encrypt have such proof embedded) and periodically talking to Log Monitors (e.g. owned by your browser vendor) about proofs it has seen. If somebody has seen a proof that is contradicted by the published log state this means the Logs involved are corrupt. If an otherwise authentic cert is shown without proofs or those proofs are bogus the cert may have been unlogged for nefarious reasons, it shouldn't be accepted and needs reporting Chrome has the start of this, it checks for the proofs. Firefox is getting roughly the same feature "soon". But the finished system with all bells and whistles is probably a year or five away. Good news is that even unfinished CT has been very effective.
deleted 8y ago
[deleted]
zip1234 8y ago
Any CA could be a honeypot. I would say LE is less likely because so much of what they do is in the open.

3pt14159 8y ago

It is good, but it is annoying that it came out before we were able to properly lock down domains to cert authorities via DNS. It used to be that a malactor had to buy a new cert when they owned part of your backend if they weren't able to get your private keys. Now they can just use Let's Encrypt.

schoen 8y ago
Can you clarify what restrictions you'd like to see in place? I didn't quite follow this, but if you can describe what you want to see, I might be able to describe a way to do it or request that it be created.
- 3pt14159 8y ago
  It's fine now, following CAA records is now mandatory, but prior to 2017 we didn't and even now most websites don't use it. CAA should be mandatory in a Let's Encrypted world because it's now trivial to create a HTTPS cert. It no longer requires stolen credit card details.
  - schoen 8y ago
    Thanks. I'm also hoping that some day there will be a direct domain-registrar-to-CA authentication protocol of some sort!
    - eldridgea 8y ago
      More from the authoritative DNS servers than the registrar but with DNSSEC enabled, DANE[0] is a pretty good system. Google deemed the failure rate of ~2% too high but I hold out hope that banks and other high value targets will use DANE in tandem with the traditional HTTPs CAs and use something like HSTS except instead of requiring HTTPS for a particular domain, will require DANE. Maybe something like viewing your account will accpet a CA signed cert, but an actual money transfer goes through a subdomain that required DANE. [0] https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...