3 ms·

"It's trivial for large providers to get root certs so that they can MITM any TLS traffic on their network" Seriously? Just like that? You can pretend that you

"It's trivial for large providers to get root certs so that they can MITM any TLS traffic on their network" Seriously? Just like that? You can pretend that you are a random site.com and get a SSL lock icon in 2023 if you are big enough?

blueflow 3y ago
Its already worse than that. Any provider sitting between you and LetsEncrypt could pass the HTTP challenge on your behalf and get themselves certified as your server.
- rootusrootus 3y ago
  I'd love to hear how exactly they'd pull that off.
  - blueflow 3y ago
    In Linux, you can do a dstaddr/dstport based redirect in the iptables FORWARD chain to your own http server and serve the ACME challenge/response things from there. This is basically a transparent proxy setup.
    - rootusrootus 3y ago
      What does that buy you? The challenge is merely an authorization, intercepting it does not get you a certificate.
      - blueflow 3y ago
        What else would i need to request the certificate?
- 3np 3y ago
  The ambition is that this will be addressed by supporting RFC8657[0], which would allow domain owners to restrict HTTP-01 issuance by declaring an issuance policy through DNS records. It's been live at staging for years and still waiting to make it to prod[1]. DNS-01 attacks are by default similarly vulnerable to MitM between the issuer and your DNS server, which can be mitigated by setting up DNSSEC. [0]: https://datatracker.ietf.org/doc/html/rfc8657 https://datatracker.ietf.org/doc/html/rfc8657 [1]: https://community.letsencrypt.org/t/prod-support-for-rfc8657-caa-constraints-for-accounturi-and-validationmethods/181584/2 https://community.letsencrypt.org/t/prod-support-for-rfc8657...
regecks 3y ago
No, it isn’t. Browser root programs have certificate transparency (SCT embedding) requirements which would immediately reveal to the world if an ISP started to use a trusted root to MITM its users.
rjh29 3y ago
Basically no. You would have to be forced to install an extra root certificate that allows the ISP to MITM your traffic, or have a CA turn rogue and start issuing certificates for other people (e.g. DigiNotar). Both of these attacks would be detected by the Certificate Transparency system, so everyone would know. And for very big domains (google/facebook) browsers pre-bundle the certs they expect to see and refuse to honour any other cert, this is known as static key pinning. Nation states would be more likely to just tap up Cloudflare to spy on the traffic since a huge % of the internet goes directly to them and is unencrypted at that point.
michaelt 3y ago
No, it's not true. You can tell it's not true, because if MITM certs signed by trusted root CAs were being issued, they'd appear in Certificate Transparency logs. Although mis-issued certificates have happened [1] it is very rare, and convincing a root CA to intentionally issue you such a certificate would be very, very far from trivial. [1] https://www.computerworld.com/article/2714719/rogue-google-ssl-certificate-not-used-for-dishonest-purposes--turktrust-says.html https://www.computerworld.com/article/2714719/rogue-google-s...

blueflow 3y ago

Its already worse than that. Any provider sitting between you and LetsEncrypt could pass the HTTP challenge on your behalf and get themselves certified as your server.

rootusrootus 3y ago
I'd love to hear how exactly they'd pull that off.
- blueflow 3y ago
  In Linux, you can do a dstaddr/dstport based redirect in the iptables FORWARD chain to your own http server and serve the ACME challenge/response things from there. This is basically a transparent proxy setup.
  - rootusrootus 3y ago
    What does that buy you? The challenge is merely an authorization, intercepting it does not get you a certificate.
    - blueflow 3y ago
      What else would i need to request the certificate?
3np 3y ago
The ambition is that this will be addressed by supporting RFC8657[0], which would allow domain owners to restrict HTTP-01 issuance by declaring an issuance policy through DNS records. It's been live at staging for years and still waiting to make it to prod[1]. DNS-01 attacks are by default similarly vulnerable to MitM between the issuer and your DNS server, which can be mitigated by setting up DNSSEC. [0]: https://datatracker.ietf.org/doc/html/rfc8657 https://datatracker.ietf.org/doc/html/rfc8657 [1]: https://community.letsencrypt.org/t/prod-support-for-rfc8657-caa-constraints-for-accounturi-and-validationmethods/181584/2 https://community.letsencrypt.org/t/prod-support-for-rfc8657...

regecks 3y ago

No, it isn’t. Browser root programs have certificate transparency (SCT embedding) requirements which would immediately reveal to the world if an ISP started to use a trusted root to MITM its users.

rjh29 3y ago

Basically no. You would have to be forced to install an extra root certificate that allows the ISP to MITM your traffic, or have a CA turn rogue and start issuing certificates for other people (e.g. DigiNotar). Both of these attacks would be detected by the Certificate Transparency system, so everyone would know. And for very big domains (google/facebook) browsers pre-bundle the certs they expect to see and refuse to honour any other cert, this is known as static key pinning. Nation states would be more likely to just tap up Cloudflare to spy on the traffic since a huge % of the internet goes directly to them and is unencrypted at that point.

michaelt 3y ago

No, it's not true. You can tell it's not true, because if MITM certs signed by trusted root CAs were being issued, they'd appear in Certificate Transparency logs. Although mis-issued certificates have happened [1] it is very rare, and convincing a root CA to intentionally issue you such a certificate would be very, very far from trivial. [1] https://www.computerworld.com/article/2714719/rogue-google-ssl-certificate-not-used-for-dishonest-purposes--turktrust-says.html https://www.computerworld.com/article/2714719/rogue-google-s...