Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Why is Kazakhstan's cert any different than the hundreds of "trusted" root certificates that came preinstalled on my mac?

Looking at my mac's cert keychain, there are 185 trusted root certs. I don't know what any of them are or who has the private key to them.

My ISP could MITM my traffic whenever it wants to, if it has the private key of one of the hundreds of trusted root certs on my device.



Those hundreds of trusted root certificates are, at least to some extent, held to operational and security standards. If your ISP used one of those certificates to MitM your traffic, there is a very real possibility of that certificate being blacklisted by browsers.

Further, unlike the Kazakhstan certificate, those root certificates cannot bypass HTTPS public key pinning (HPKP).


Thanks for the info! I didn't know some of this. Two questions:

1:

> there is a very real possibility of that certificate being blacklisted by browsers

Why would a browser blacklist a certificate? Is it possible for a browser to detect a MITM attack when the SSL traffic is all signed by the private key of a trusted root certificate?

2:

> Further, unlike the Kazakhstan certificate, those root certificates cannot bypass HTTPS public key pinning (HPKP).

You are saying that pre-installed root certificates behave differently than user-installed root certificates? Wouldn't that behavior be system-dependent? I was under the impression that no root certificates can bypass public key pinning... isn't that sort of the point of pinning? That it allows traffic encryption outside of the normal trust hierarchy? What makes the Kazakhstan cert special that allows it to break pinning?


1: A server using HPKP with the reporting feature turned on will receive reports from browsers when the certificate does not match what was expected (provided HPKP is being honored).

2: Browsers ignore HPKP when the server certificate is trusted through a user or administrator installed root CA. All mainstream browsers on all platforms behave in this way. This is by design specifically to allow enterprises to do the sort of traffic interception that Kazakhstan is implementing. The rationale is that if an attacker is able to get as far as installing their own CA on your system, you're screwed anyway.


These CAs have to follow specific rules and have external audit. MITM is prohibited by these rules: certificate authorities that participate or enable MITM are removed from root stores (example: https://en.wikipedia.org/wiki/DigiNotar).


DigiNotar was used for MITM after getting hacked. If talking about CAs caught intentionally issuing intermediates for MITM purposes, we should at least mention TrustWave (SecureTrust CA): https://en.wikipedia.org/wiki/Trustwave_Holdings#Unrestricte...


The rules and audits don't seem very effective: it's not just Diginotar that has been caught issuing rogue *.google.com certificates, but to my knowledge it's the only one that got removed from root stores.


And sometimes the CAs might receive National Security Letters insisting on National Securtiy Certificates.


A National Security Letter will not prevent the certificate authority from being blacklisted when detected, and there are at least some legal precedents for warrants (though not necessarily for NSLs) that could challenge a warrant if complying with it would effectively destroy the business (given that the business itself is not the subject of the warrant). If that isn't the definition of an "unreasonable burden", nothing is.


"A National Security Letter will not prevent the certificate authority from being blacklisted " Sure it will, just send another NSL to the blacklisting instance.

And I do not understand that going to jail instantly is a smaller burden for you than living with the small risk getting caught.

Do you really believe the NSA or any of those other patriots do not have a few of the private keys for the certificates you trust?


> Sure it will, just send another NSL to the blacklisting instance.

Instances, plural, including both browsers and various cross-check mechanisms (pinning, certificate transparency, etc). Likely too many people required for operational security.

Not saying it couldn't be done, but it certainly couldn't be done lightly or often, and even then it would produce significant risk of exposure. It certainly couldn't be effectively used for widespread traffic interception.

> And I do not understand that going to jail instantly is a smaller burden for you than living with the small risk getting caught.

As mentioned, there exists legal precedent that a warrant/subpoena for information from a third party can't compel that third-party to provide arbitrarily large amounts of aid or to impose an undue burden. Findings of "undue burden" have been upheld for burdens far smaller than "this has a risk of destroying the entire business".


warrant/subpoena != NSL


Yes, as I said in my original response, "not necessarily for NSLs".


If you don't trust them, turn them off. That's what I do, at least. I've disabled the vast majority of those roots in Keychain Assistant.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: