Re:Cloudflare, Mozilla, Fastly, and Apple Working on Encrypt...
by peterwwillis on Monday July 16, 2018 @07:10AM
(#17540323)
You're right, there's ways to detect it, though I don't think browsers today actually check the cert transparency log or CAA record when making requests. Without these two checks, valid certs created by a MITM tool using a CA's keys should pass without flagging any validation errors.
Re:Cloudflare, Mozilla, Fastly, and Apple Working on Encrypt...
by cesarb on Monday July 16, 2018 @07:27AM
(#17540405)
Even if most browsers don't check, it takes just one single person to expose the whole operation. This provides a strong incentive to use compromised cert vendors only for the most important operations, instead of indiscriminately against everyone: each use of a counterfeit certificate risks "burning" the whole cert vendor.
And as you say, browsers today might not check these things (and checking CAA doesn't make much sense for a browser, it's intended to be checked by certificate issuers). But future browsers, browsers customized with some third-party extensions, or non-browsers might check.
Re:Cloudflare, Mozilla, Fastly, and Apple Working on Encrypt...
by Ajedi32 on Monday July 16, 2018 @09:38AM
(#17541160)
Chrome does check that all certs (at least [the ones issued after April 30][1]) are recorded in a Certificate Transparency log. Or rather, it checks that multiple logs have promised to include the certificate (via a signed certificate timestamp); the code that actually queries the CT monitors to verify that the certificate was included [isn't finished yet][2].
Browsers don't and can't check CAA records, because that's not how CAA is supposed to work. CAA is only enforced at the time of issuance. If you temporarily switch your CAA records to allow issuance for an hour, issue a cert, then switch them back to block all issuance from all CAs, the cert you issued remains valid.
[1]: https://groups.google.com/a/chromium.org/forum/#!msg/ct-poli...
[2]: https://bugs.chromium.org/p/chromium/issues/detail?id=506227
There's no "quiet" in this approach. The cert vendors do not have the certificate's private keys; all the server operators send to the cert vendors is the certificate's public keys. Therefore, the only way to listen on the secured connections through a cert vendor is to use the cert vendor's private keys to sign a counterfeit certificate, which is presented to the browser. And at this point, the browser has everything it needs to prove that the cert vendor was compromised.
There are also several other gotchas: Certificate Transparency can force them to publish their counterfeit certificates to the whole world; Extended Validation is allowed only from some cert vendors (and requires Certificate Transparency); and last but not least, this (like all MITM) breaks client authentication (client certificates).
Finally, this only applies to cert vendors under the USA jurisdiction. A NSL has no power over other countries.