On Tue, 2014-03-25 at 18:58 +0100, Bas Wijnen wrote: > No, the point is that an attacker is detectable. Why should he be? And even if he was... if I already sent my valuable data, then it's too late.
> Do you think the NSA > does MITM attacks on all connections? I seriously thought that they > might. Well the question is less whether they actually try it with any connection... which is of course unlikely since people would notice that far to easy... the question is rather whether they could do it with all connections... and I guess that might be the case... the only thing they need to do is to hijack only such connections for which they know no verification will be made. > If the NSA starts doing this, someone will catch them. That will be big > news and everyone will start checking their keys. I doubt that... and how should it work anyway? How can I check the public key of my e.g. bank? Right now, only by trusting Verisign&friends... which again are all under the control of NSA&friends. > Well, not exactly, of course. It is still very likely that they are > trying to (and also that they succeeded to) put back doors into the > encryption protocols, or at least their implementations. Sure but that's another field... > Depending on what you mean by "sitting on the line". They can always > read, but to tamper they need to sit "in" the line, not just on it. > They have to make sure the original packets don't reach their > destination. I take it that's what you mean. > > (Note that this is a much smaller group of machines; for example, I can > read all traffic on the subnet of my block of houses, but I can't > effectively tamper with it.) Well if one has to assume that they sit "in" the big internet exchange points... this already gives them a lot... > But if they start to doubt, they can check if they have been attacked, > by comparing their keys through an independent channel. Well but that simply doesn't happen, does it? At least since Snowden, all world should really know: NSA&friends spy _everything_ ... I mean most of use expected it for sure before... but now there is no way to not know. And what changed? Well we still have the broken X.509 strict hierarchical trust model,... and it won't go away very soon. Of course the NSA won't issue forged certs (by forcing verisign&friends) at large (because that would be rather easily noticed) but they will do so for targets worth it. So people must have your "doubts" by know, but nothing really changes. Actually the contrary... like e.g. Debian who puts its own certificates under some commercial CA now, instead of using its own, which people could really trust (well at least as much as they can trust Debian itself). > If any of them is found to be under > attack, more checks will be done; if many of those will fail, all hell > will break loose. You can be sure that they do all this... and no hell broke loose. > to convince people that > not encrypting is better than encrypting with unchecked keys. Well that's not what I said... I rather say the later is simply not enough. > You're claiming that having an evil CA in the list means that my > communication is in danger of being eavesdropped. I'm saying that this > is nonsense, because: > > > > An evil CA cannot read your traffic (unless they are in > > > the path of your communication). > > You are saying that the NSA has control over evil CAs, and also is in > the path of communication. So they can eavesdrop. Technically this is > true. But there are two things to consider: > > 1. Due to the fact that they would be detected if they tried this on a > large scale, they won't actually do this. Well first... why is an attack only a problem if it's done at large scale? If the NSA does this only for the Snowdens, Applebaums, etc. ... then this is enough for them... Secondly,... "being detected" in that case means, that someone trustworthy regularly scans for forged certificates... (in the sense of having a different fingerprint, than the ones from the same CA, which are however known to be in the possession of their rightful owner). - This is difficult by the mass of certificates... even for single companies like google you have gazillions of domains and even more certs... This is the reason why programs like certificate patrol are only little helpful in practise. - It would need to mean, that this someone is not under the control of such government (also, not necessarily the case). - It would need to mean, that that someone does actually know the correct cert (if he only ever saw the forged one, he will never notice it). - And it would need to mean that the rightful owner is not evil... or not forced to be evil (by law)... which we again know is the case at least in the US. So you may be "lucky" to notice such forgery... but there is no guarantee. Anyway... the topic of that bug was rather the CAcert certificate... and I think Debian is doing very bad if it tries to give any "guarantee" about trustworthiness of it's shipped certs... It simply cannot (neither can Mozilla or anyone else)... As such, ca-certificates would be better off being a collection of well known certificates, who are known to be "valid" (i.e. the ones they claim to be). I'm not saying that CAcert is secure or trustworthy (actually I wouldn't use it for my own "security critical" services - neither would I use any other CA not under my personal control)... but it's not less secure than any other CA we ship. And right now, the only thing we do is taking away the user's possibility to retrieve root certificates in a secure way. We should not remove certs... we should add more, like CERN CA, TACAR TERENA, etc. Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
