Graham, Nelson, Eddy, you all make good points. I'll take your word for it that it's impossible to detect MITM attacks with 100% reliability, as I said I'm not a security expert.
How about an MITM detection service that gives no false positives, but might give false negatives? If you positively identify an MITM attack, you can present users with a much more definite UI saying "this *is* an MITM attack" and giving advice about what to do in the event of an MITM. I'm not talking about fixing all the problems for all the users, just a real improvement for a proportion of users. For example, can one give site owners a way of specifying that their domain must not be accessed if it presents a self-signed certificate. Paypal.com would no doubt take this option, as would any large bank. If the method is made easy enough, so might other sites like facebook. Two possible methods that don't require a detection service (mitm.mozilla.org) might be a DNS record (doesn't work if the attacker has compromised DNS) or a subdomain naming convention (i.e. secure.example.com requires a valid certificate - presents adoption issues for existing sites). This would likely have stopped the original bug poster from revealing her password. > If you could implement a perfect MITM detection service, that would be > of some value. But an imperfect MITM detection service simply becomes > the favorite new target of attackers. > > A perfect MITM detection service is useful in that if it detects an MITM > then that might be a basis upon which to stop the client cold. But in > the absence of such detection, there is still no proof that the cert > accurately identifies the party it claims to identify. Trouble is, > users will learn to treat the absence of a definitive MITM detection as > if it WAS proof of the server's identity. I can see how there are philosophical reasons to avoid any MITM detection even if it gave no false positives, because a false negative would be interpreted as an "all clear". However, if the user who filed the bug report is anything to go by, people are already misinterpreting real MITM attacks as false positives. Making the error screen scarier for all errors won't fix this because users will just learn that the new scarier screen is what false positives now look like. Introducing a new screen that has a far lower rate of false positives seems a reasonable thing to try. > I know you brought it up somewhere on Bugzilla....go ahead and implement it. Implement what? There's no proposal yet, I'm just trying to start a constructive discussion. If there is interest in implementing something resembling my suggestions, I'll pitch in as much as my schedule and ability allow. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
