Nelson B Bolyard wrote: > Ian G wrote, On 2008-10-19 05:09: >> Ian G wrote: >>> Nelson B Bolyard wrote: >>>> KCM would not have helped. >>> I agree, KCM would not have helped. In both cases, the warnings are >>> delivered, and the user is given the responsibility for the overrides. >> I was thinking about this, and actually, KCM would have helped here. > > No, it couldn't have. In fact, it could have been hurtful. > >> If you look at the two cert viewers side by side, then there is a >> clear difference: >> >> https://bugzilla.mozilla.org/attachment.cgi?id=343662 >> https://bugzilla.mozilla.org/attachment.cgi?id=343663 >> >> Now, this info and the difference is available to the browser, which >> operating in KCM mode. It would be an easy thing to display the two >> certs, and the differences highlighted, perhaps in red or somesuch. > > This was a brand new installation. Formatted hard drive, reinstalled OS, > installed browser. FIRST contact with every https site produced the > self-signed cert warning. There simply were no other certs with which > to compare.
Lol... Yes, you are right, I missed that completely. KCM can not use the user's original validation if there was none before. (I commented on the bug about where our views diverge so I won't repeat that here.) > KCM would have accepted those certs without any complaint. Ahhh, not exactly! With KCM, it is not up to it to accept any certs any time: unfamiliar certs are passed up to the user for validation. If the user does not validate, then she has done a bad thing. Yes, KCM would be at its weakest at that point, but no software tool is perfect; at some stage we have to ask the user, and then by definition the software is weak, dependent on the user. > THEN, later, if and when she came upon the REAL server certs from the > real server, KCM would have warned her away! It would have said > "Wait, don't trust this new cert!" Right, that too ! Although, what I suggested above is a little better than disaster in this scenario. It would have presented her both certificates. If she had marked the self-signed one as "good" and then noticed that the new CA-signed "bad" one is superior because it has a brand name sig on it, this better info displayed would still have given her enough to deal with her "upgrade" attack. > And don't forget the Debian key generator. It showed us that a serious > flaw in KCM is the complete lack of any revocation mechanism. Not sure about that one? Do you mean all the SSH servers that were exposed to compromise because of the Debian OpenSSL random snafu? http://xkcd.com/424/ Sure, but the comparison is of chalk and cheese. In practice, the SSH community takes what it is given for free, and wouldn't trade that for all the revocation in the world. Even the nice low $$$ cost of a Startcom cert -- free! -- isn't going to wrest them away from their precious KCM, and for good reason: for that particular application, revocation isn't worth the costs that it would add to the solution. (Funnily enough, I used telnet with SSL support for a year or so back in 1995 :) > I want to drive a stake through the heart of something, too. > Can you guess what it is? This one I can guess [1] :) However, bear in mind that KCM still requires: the user has to validate the first time. If the user does not validate, then we have a potential problem. Compare and contrast: CA-signed models ask the user to validate when the certificates don't make sense to the algorithms. If the user does not validate, or validates badly, then the world will eventually drift to failures. Assuming that there is a requirement to validate, built into the system, then no tool can protect against a failure to validate. It's part of the system. iang [1] but I couldn't guess the one in your essay!
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
