News for hackers. Stuff that matters.
Re:Cloudflare, Mozilla, Fastly, and Apple Working on Encrypt... by kristofferR on Monday July 16, 2018 @04:58AM (#17539741)
Forcing the installation of a root CA isn't a viable option for all but the largest authoritarian governments (China and Russia).

Kazakhstan attempted [1], but abandoned the idea, likely since it was unrealistic to expect widespread adoption of the certificate.

[1] https://news.ycombinator.com/item?id=10663843

Re:Cloudflare, Mozilla, Fastly, and Apple Working on Encrypt... by jopsen on Monday July 16, 2018 @08:01AM (#17540587)
Indeed raising the bar for what it takes to make these kinds of installations are going to prevent a lot of small countries from doing it.

And eventually, it'll probably make it infeasible in China/Russia. Especially, as the population becomes more technology literate.

Re:Cloudflare, Mozilla, Fastly, and Apple Working on Encrypt... by exikyut on Monday July 16, 2018 @06:09AM (#17540037)
Well, you could make a proxy that only allows HTTPS traffic through if it's signed by your root cert, then MITM-resign all upstream certs.

...ah, and that would break anything using cert pinning.

HTTPS feels so utterly clunky.

Re:Cloudflare, Mozilla, Fastly, and Apple Working on Encrypt... by peterwwillis on Monday July 16, 2018 @07:05AM (#17540302)
A much easier solution is for the government to circumvent PKI entirely. Basically you issue a National Security Letter to some cert provider and require them to give you their keys. Now you can generate valid certs as that provider. You use this in combination with a MITM tool to auto-generate certs for any requested domain, and those certs are implicitly trusted by all clients because they trust that CA's keys. So the state can now MITM and listen to all secured connections, and the only giveaway is that the cert is not in the certificate transparency log, or if the CA used does not match the domain's CAA record (when it exists).
Re:Cloudflare, Mozilla, Fastly, and Apple Working on Encrypt... by cesarb on Monday July 16, 2018 @07:38AM (#17540458)
> So the state can now MITM and listen to all secured connections, and the only giveaway is that the cert is not in the certificate transparency log, or if the CA used does not match the domain's CAA record (when it exists).

Or when the domain uses HPKP to pin its certificate to a different CA. When the MITM CA has been added manually to the browser's root key store, most browsers allow HPKP bypass by that CA unless configured otherwise; but if the MITM is done by compromising one of the browser's default CAs, the browser won't allow a bypass.

Or if the certificate was supposed to be an EV certificate, which can only be issued by a limited number of CAs, and the compromised CA is not one of these. And even if an EV CA is compromised, AFAIK some browsers require the certificate to be in a Certificate Transparency log, and they also require that the certificate carry proof of its submission to the CT logs.

Re:Cloudflare, Mozilla, Fastly, and Apple Working on Encrypt... by peterwwillis on Monday July 16, 2018 @08:05AM (#17540608)
1) HPKP is dead, Chrome 67 removes support. 2) No client will flag an error if the new cert is non-EV. EV is completely useless as a security feature. 3) AFAIK no browser checks the cert transparency log.
Re:Cloudflare, Mozilla, Fastly, and Apple Working on Encrypt... by gsich on Monday July 16, 2018 @06:55AM (#17540250)
And how does that "forcing" work? You just install it voluntarily because you get annoyed by certificate errors on every other site?