36 ms·

There's not much to spy on. It's not like LetsEncrypt generate your private keys and give them to you. They sign a request that you send them (and they don't ge

There's not much to spy on. It's not like LetsEncrypt generate your private keys and give them to you. They sign a request that you send them (and they don't get to ever see your actual private key). So an evil CA won't be able to crack your encrypted website. An evil CA can of course generate fake certificates for any hostname they like, but those people already exist. Have you taken a look at just how many different root CAs are out there, and are trusted by your OS/browser? It includes hundreds of companies and governments. Then there are even more (countless?) 'second level CAs' (I forget the proper term, sorry!) who can also generate and sign a trusted certificate for any hostname, because, while they aren't a root CA, their authority has been signed in turn by a top-level CA. The web of trust is very large and has many points of failure.

paulddraper 7y ago
> 'second level CAs' (I forget the proper term, sorry!) Perhaps intermediate CA. https://en.wikipedia.org/w/index.php?title=Intermediate_certificate_authorities&redirect=no https://en.wikipedia.org/w/index.php?title=Intermediate_cert...
DaiPlusPlus 7y ago
> So an evil CA won't be able to crack your encrypted website. If the evil CA is default-trusted by major OS and browser vendors then they can - with their own private key then do a MITM.
- tgsovlerkhgsel 7y ago
  That would require them to issue a separate certificate. Certificate Transparency provides significant deterrence against that. They can either log it into Certificate Transparency (and include the SCT, the "receipt" for logging it, in the cert), or not do that. If they log it, the server operator can see (in the public CT logs) that a certificate was issued for his domain by someone else, and raise hell. If they don't log it, the certificate won't have an SCT. That means that software that enforces CT can treat the certificate as invalid, and if someone saw the cert on the wire, it would immediately appear suspicious since all Let's Encrypt certs are supposed to have an SCT. They could also get an evil CT log to issue a SCT without logging it, but that would generate irrefutable cryptographic proof of malfeasance of the CT log.
  - alwillis 7y ago
    They could also get an evil CT log to issue a SCT without logging it… If a SCT is issued, it has to be logged within a certain amout of time; 3rd party auditors check for this. [1]: An auditor is a third party that keeps log operators honest. They query logs from various vantage points on the internet and gossip with each other about what order certificates are in. They’re like the paparazzi of the PKI. They also keep track of whether an SCT has been honored or not by measuring the time it took between the SCT’s timestamp and the corresponding certificate showing up in the log. And only certain logs are trusted anyway [2]; a CT log that doesn't meet certain requirements wouldn't be trusted to begin with. And if a trusted CT log turned evil, it would quickly be noticed. [1]: https://blog.cloudflare.com/introducing-certificate-transparency-and-nimbus/ https://blog.cloudflare.com/introducing-certificate-transpar... [2]: https://github.com/chromium/ct-policy/blob/master/log_policy.md https://github.com/chromium/ct-policy/blob/master/log_policy...
    - tgsovlerkhgsel 7y ago
      The malicious cert would presumably only be used against specific targets, reducing the chance that an auditor gets to see it. But indeed, an SCT and a later timestamp on the log without having logged the cert would be the cryptographic evidence I talked about.
- alwillis 7y ago
  1. Certification Authority Authorization (CAA) specifies which CAs are allowed to issue certificates for your website. Of course if the CA is truly evil, they would ignore whatever is specified. [1] 2. A DNSSEC-signed website can use DANE to specify which certificate, intermediate or key is authorized to be used. [2][3] [1]: https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-cabrowser-forum#comment-361374 https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-c... [2]: https://weberblog.net/how-to-use-danetlsa/ https://weberblog.net/how-to-use-danetlsa/ [3]: https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022 https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3...
  - tptacek 7y ago
    No it can't, because no mainstream browser supports or ever will support DANE.
    - alwillis 7y ago
      Notice I never mentioned browsers. Breaking news: there are other applications on the internet other than browsers. And some of them use TLSA records. It’s the de facto standard for for secure email, especially if you want guaranteed protection from downgrade attacks.
      - tptacek 7y ago
        Virtually no email sent on the Internet is protected by DANE, DNSSEC, or TLSA. Nor is it likely ever to be, since the major email providers standardized MTA-STS specifically to avoid DNSSEC, as you can see from the opening paragraphs of the standard.
        alwillis 7y ago
        This is provably false. DNSSEC, DANE and TLSA are widely used to secure SMTP servers. From the web page showing the nearly 2 million domains with signed MX and DANE records [1]: The following graph depicts the number of domains that have deployed DANE/SMTP. Specifically, their zone is signed, their MX records all point to hosts that have DANE TLSA records. Regarding MTA-STS, it's a work-around for the large global email providers that can’t implement DNSSEC for a variety of reasons. Again, MTA-STS has problems, the main one is being susceptible to downgrade attacks because MTA-STS doesn’t use DNSSEC. An attacker can MiTM a connection preventing a TLS connection. The MTA-STS RFC [2] confirms this: The DNS-Based Authentication of a Named Entities (DANE)TLSA record [RFC7672] is similar, in that DANE is also designed to upgrade unauthenticated encryption or plaintext transmission into authenticated, downgrade-resistant encrypted transmission. DANE requires DNSSEC [RFC4033] for authentication; the mechanism described here instead relies on certification authorities (CAs) and does not require DNSSEC, at a cost of risking malicious downgrades. There’s no dispute about any of this, so it’s not clear why you continue to make false and misleading statements about these technologies, regardless of your opinions about them. You know the old saying: you’re entitled to your own opinion but not your own facts. [1]: https://stats.dnssec-tools.org/#dnssec https://stats.dnssec-tools.org/#dnssec [2]: https://tools.ietf.org/html/rfc8461#section-2 https://tools.ietf.org/html/rfc8461#section-2 A more complete description I posted previously: https://news.ycombinator.com/item?id=22338742 https://news.ycombinator.com/item?id=22338742
panny 7y ago
>An evil CA can of course generate fake certificates for any hostname they like, but those people already exist [citation needed] If that were true, I'd expect browser/OS makers to promptly revoke trusted CA status for them.
- ohyeshedid 7y ago
  Promptly meaning as soon as they find out, which is likely nearly instant these days for large services. Comodo issued bogus certs, so did MCS. It's happened a few times over the years.
- hawkice 7y ago
  Only if they abused it. If it's a government CA, and they use it only to trap pedophiles and ISIL, I don't see them doing anything.
  - comex 7y ago
    I’m pretty sure browsers will de-trust CAs that intentionally sign forged certificates regardless of what they’re used for.
  - tracker1 7y ago
    Only pedophiles and ISIL need encryption, so what are you worried about... just do all your banking etc. over plain HTTP... I'm sure no foreign governments are listening on ANY compromised devices in the middle, or have any motivations you disagree with.
- Thorrez 7y ago
  >promptly It takes a very long time to revoke trust if you don't want to break the web. Symantec was discovered to have misissued a bunch of certs in 2015[1] (including for google.com). No one removed trust for them. Then in Jan 2017 it was discovered they misissued a bunch more[2]. I believe it was the end of 2018 before browsers finally removed trust for them. [1] https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html https://security.googleblog.com/2015/10/sustaining-digital-c... [2] https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html https://security.googleblog.com/2017/09/chromes-plan-to-dist...

paulddraper 7y ago

> 'second level CAs' (I forget the proper term, sorry!) Perhaps intermediate CA. https://en.wikipedia.org/w/index.php?title=Intermediate_certificate_authorities&redirect=no https://en.wikipedia.org/w/index.php?title=Intermediate_cert...

DaiPlusPlus 7y ago

> So an evil CA won't be able to crack your encrypted website. If the evil CA is default-trusted by major OS and browser vendors then they can - with their own private key then do a MITM.

tgsovlerkhgsel 7y ago
That would require them to issue a separate certificate. Certificate Transparency provides significant deterrence against that. They can either log it into Certificate Transparency (and include the SCT, the "receipt" for logging it, in the cert), or not do that. If they log it, the server operator can see (in the public CT logs) that a certificate was issued for his domain by someone else, and raise hell. If they don't log it, the certificate won't have an SCT. That means that software that enforces CT can treat the certificate as invalid, and if someone saw the cert on the wire, it would immediately appear suspicious since all Let's Encrypt certs are supposed to have an SCT. They could also get an evil CT log to issue a SCT without logging it, but that would generate irrefutable cryptographic proof of malfeasance of the CT log.
- alwillis 7y ago
  They could also get an evil CT log to issue a SCT without logging it… If a SCT is issued, it has to be logged within a certain amout of time; 3rd party auditors check for this. [1]: An auditor is a third party that keeps log operators honest. They query logs from various vantage points on the internet and gossip with each other about what order certificates are in. They’re like the paparazzi of the PKI. They also keep track of whether an SCT has been honored or not by measuring the time it took between the SCT’s timestamp and the corresponding certificate showing up in the log. And only certain logs are trusted anyway [2]; a CT log that doesn't meet certain requirements wouldn't be trusted to begin with. And if a trusted CT log turned evil, it would quickly be noticed. [1]: https://blog.cloudflare.com/introducing-certificate-transparency-and-nimbus/ https://blog.cloudflare.com/introducing-certificate-transpar... [2]: https://github.com/chromium/ct-policy/blob/master/log_policy.md https://github.com/chromium/ct-policy/blob/master/log_policy...
  - tgsovlerkhgsel 7y ago
    The malicious cert would presumably only be used against specific targets, reducing the chance that an auditor gets to see it. But indeed, an SCT and a later timestamp on the log without having logged the cert would be the cryptographic evidence I talked about.
alwillis 7y ago
1. Certification Authority Authorization (CAA) specifies which CAs are allowed to issue certificates for your website. Of course if the CA is truly evil, they would ignore whatever is specified. [1] 2. A DNSSEC-signed website can use DANE to specify which certificate, intermediate or key is authorized to be used. [2][3] [1]: https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-cabrowser-forum#comment-361374 https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-c... [2]: https://weberblog.net/how-to-use-danetlsa/ https://weberblog.net/how-to-use-danetlsa/ [3]: https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022 https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3...
- tptacek 7y ago
  No it can't, because no mainstream browser supports or ever will support DANE.
  - alwillis 7y ago
    Notice I never mentioned browsers. Breaking news: there are other applications on the internet other than browsers. And some of them use TLSA records. It’s the de facto standard for for secure email, especially if you want guaranteed protection from downgrade attacks.
    - tptacek 7y ago
      Virtually no email sent on the Internet is protected by DANE, DNSSEC, or TLSA. Nor is it likely ever to be, since the major email providers standardized MTA-STS specifically to avoid DNSSEC, as you can see from the opening paragraphs of the standard.
      - alwillis 7y ago
        This is provably false. DNSSEC, DANE and TLSA are widely used to secure SMTP servers. From the web page showing the nearly 2 million domains with signed MX and DANE records [1]: The following graph depicts the number of domains that have deployed DANE/SMTP. Specifically, their zone is signed, their MX records all point to hosts that have DANE TLSA records. Regarding MTA-STS, it's a work-around for the large global email providers that can’t implement DNSSEC for a variety of reasons. Again, MTA-STS has problems, the main one is being susceptible to downgrade attacks because MTA-STS doesn’t use DNSSEC. An attacker can MiTM a connection preventing a TLS connection. The MTA-STS RFC [2] confirms this: The DNS-Based Authentication of a Named Entities (DANE)TLSA record [RFC7672] is similar, in that DANE is also designed to upgrade unauthenticated encryption or plaintext transmission into authenticated, downgrade-resistant encrypted transmission. DANE requires DNSSEC [RFC4033] for authentication; the mechanism described here instead relies on certification authorities (CAs) and does not require DNSSEC, at a cost of risking malicious downgrades. There’s no dispute about any of this, so it’s not clear why you continue to make false and misleading statements about these technologies, regardless of your opinions about them. You know the old saying: you’re entitled to your own opinion but not your own facts. [1]: https://stats.dnssec-tools.org/#dnssec https://stats.dnssec-tools.org/#dnssec [2]: https://tools.ietf.org/html/rfc8461#section-2 https://tools.ietf.org/html/rfc8461#section-2 A more complete description I posted previously: https://news.ycombinator.com/item?id=22338742 https://news.ycombinator.com/item?id=22338742

panny 7y ago

>An evil CA can of course generate fake certificates for any hostname they like, but those people already exist [citation needed] If that were true, I'd expect browser/OS makers to promptly revoke trusted CA status for them.

ohyeshedid 7y ago
Promptly meaning as soon as they find out, which is likely nearly instant these days for large services. Comodo issued bogus certs, so did MCS. It's happened a few times over the years.
hawkice 7y ago
Only if they abused it. If it's a government CA, and they use it only to trap pedophiles and ISIL, I don't see them doing anything.
- comex 7y ago
  I’m pretty sure browsers will de-trust CAs that intentionally sign forged certificates regardless of what they’re used for.
- tracker1 7y ago
  Only pedophiles and ISIL need encryption, so what are you worried about... just do all your banking etc. over plain HTTP... I'm sure no foreign governments are listening on ANY compromised devices in the middle, or have any motivations you disagree with.
Thorrez 7y ago
>promptly It takes a very long time to revoke trust if you don't want to break the web. Symantec was discovered to have misissued a bunch of certs in 2015[1] (including for google.com). No one removed trust for them. Then in Jan 2017 it was discovered they misissued a bunch more[2]. I believe it was the end of 2018 before browsers finally removed trust for them. [1] https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html https://security.googleblog.com/2015/10/sustaining-digital-c... [2] https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html https://security.googleblog.com/2017/09/chromes-plan-to-dist...