On Thu, Jan 22, 2009 at 6:05 AM, Ian G <i...@iang.org> wrote: > On 22/1/09 13:54, Kyle Hamilton wrote: >> >> Ian, I'd rather not spell this out, because it's a blueprint that any >> malicious coder could follow. Unfortunately, you seem to insist on >> documentation -- and refuse to accept the word of those who actually >> do know. So. > > > Please.... Are you assuming here that we are the repository of all security > knowledge? Are you saying that the hackers don't know how to do these > spoofing attacks? Are we happy with a security-by-obscurity approach, and > it is too dangerous for people to really know what's going on? I've gotta > trust you? Because I don't know what I'm talking about, I should be scared?
I'd suggest you drop the argumentum ad absurdum. This isn't what I'm stating, and you well know it. (or you should. If you don't, you really shouldn't be taking part in the conversation here.) Except, of course, the last: because you don't know what you're talking about, you SHOULD be scared. If you're really the one who wrote the financialcryptography site, you should know that all of the security is only as good as the primitives in use, and the assumptions inherent in their use. Two of which are: "keypairs are only as good as the entropy used to generate them" and "private keys must remain private". Without these assumptions, the security of the system isn't. The hackers do already know how to do this. That doesn't mean that I have to make it easier for people to do it without spending research time. And no, I'm not stating that we're the repository of all security knowledge. I'm simply stating that those of us who do know how to do it already know that the "clear and present danger" which you demand to know about does, truly, already exist. > It's an MITM, right? Is there any more to say about implementation that > changes that? The current thing we know about the MITM is that it can be > done via various spoofing tricks (DNS, BGP) from wherever. Considering that this is THE reason that TLS (along with server certificates, issued by a third party certifier and with private keys that are actually private) exists, I'd say it shows that the assumptions that allow TLS to be considered "secure" are completely violated in the case of use of poorly-generated random numbers as seeds for the RSA prime search. The "clear and present danger" comes in when you think about users who are using public wi-fi access points. The danger of spoofing was much less pronounced when users had to use wired connections, because they'd typically only use wired connections from hotels, workplaces, or their home cable/DSL -- and thus had more trust in the legal protections available because of money changing hands. > So the site's SSL communications can be MITM'd. Is that the conclusion? Not 'the site', but 'any site still using a weakly-generated key'. And not *can be*, but *have been*. (Or have you forgotten the case of the girl who accepted all the bogus certs because she thought that Firefox was screwing up? That wasn't quite as sophisticated an attack as I laid out, but if someone can do the bogus cert thing then they can just as easily extend it to be undetectable.) I respectfully suggest that you go back to auditing. That's really the only useful input that I've seen you make. (As it stands right now, your argument is essentially "since there's no liability, legally, nobody should bother trying to fix or shore up the current system, even when the underlying sanity-checks of the system are violated." The problem is, regardless of whether there's liability, THIS IS THE ONLY THING THAT THE USERS HAVE. If you want to design something better, do so, then propose it to the standards bodies.) -Kyle H -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
