Hi, Am 15.10.2013 um 15:42 schrieb Jan Schejbal <[email protected]>:
> Hi, > what I found interesting is that the leaks showed that the NSA attempts > to obtain the private keys for the real certificates. This means they > probably don't really like to use CA-signed separate certificates. I > think there are several reasons for that: > I'm talking about getting the valid private key from a valid root certificate and that they can create their own certificates for any domain available and sign those with the private key from the root ca that is trusted by the browsers/OSes around. > - Using a different certificate can be detected (CertPatrol etc.), and > the NSA has been said to be *very* careful about not getting caught (I > think that was mentioned in an article by Bruce Schneier about how the > NSA infects its victims - computer-savvy people either get the worthless > publicly known exploits or not attacked at all due to the risk of detection) > This is the point. Creating certificates that are absolutely valid is exactly what the NSA needs and gets by having those private keys. And the common user is not running tons of utilities to detect certificate changes. Some people might do that, but a common user trusts the system that he doesn't even really understand and thinks that everything is fine as long as the url bar shows a green icon. > - Using fake certs requires an active attack. Unless a PFS ciphersuite > is used, the original key allows passive decryption - which is > attractive both because it can be done after capture, and because the > NSA might not have the ability to MitM everywhere. > Yeah, but at the locations they can do it, they will do it… > - Getting caught could have immense consequences for the CA and trust > in US companies, worse than what has happened so far. Unfortunately, > since many past CA compromise incidents had insufficient consequences, > I'm not sure if this would actually happen. This doubt is something we > need to fix, IMHO. > We can't fix that. How can you fix the doubt in something where even the owners of the companies (CAs) aren't allowed to talk about because they'd else face crimes against the american people and other stuff (lavabit). > Any *demonstrated* collaboration of a CA should mean immediate yanking > of the root. Moreover, since such an event would likely be covered up, > I'd say that any misissued certificate where there is a *suspicion* of > collaboration by the CA should mean yanking the root. There should not > be need to prove collaboration as long as the misconduct itself is > proven. This would also motivate CAs to take their security seriously. > Question is how to prove it? By comparing the hashes/digests of the certs? Should there be something in e.g. Firefox that remembers the hashes/digests and the valid dates of the certs and checks every time the website is visited? > I think that preventively distrusting US CAs without any evidence is > pointless. I think it makes more sense to instill fear of inevitable > consequences in the CAs, motivating them not to cooperate with the NSA. > The problem is the so called "law" … There isn't any motivation that can be done to let people take the Guantanamo-trip instead of the lots-of-money-own-business-trip when the question comes up... > This also means that if a CA gets caught, e.g. due to coming Snowden > leaks, off with its root(s), with no further discussion, just 24 hours > of warning for web site admins to change certificates. This should be a > pre-agreed policy so it can be implemented quickly. This includes cases > where there is proof that *all* CAs collaborate (in which case, yank > them all). > > Should concrete evidence surface that shows US CAs collaborating with > the NSA, without being able to pin it to a specific CA, *then* we should > talk about some massive root removal. > > Kind regards, > Jan > KR, Oliver > -- > Please avoid sending mails, use the group instead. > If you really need to send me an e-mail, mention "FROM NG" > in the subject line, otherwise my spam filter will delete your mail. > Sorry for the inconvenience, thank the spammers... > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
