10 ms·

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

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 https://news.ycombinator.com/item?id=10663843

exikyut 8y ago
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.
gsich 8y ago
And how does that "forcing" work? You just install it voluntarily because you get annoyed by certificate errors on every other site?
peterwwillis 8y ago
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).
- cesarb 8y ago
  > 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.
  - peterwwillis 8y ago
    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.
jopsen 8y ago
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.

exikyut 8y ago

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.

gsich 8y ago

And how does that "forcing" work? You just install it voluntarily because you get annoyed by certificate errors on every other site?

peterwwillis 8y ago

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).

cesarb 8y ago
> 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.
- peterwwillis 8y ago
  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.

jopsen 8y ago

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.