Frank Hecker wrote: > Amir Herzberg wrote: > >> We have created a Mozilla extension that creates a secure, Trusted >> Logo and Credentials Area, which displays logos and other credentials >> The proposal is described at: >> Protecting (even) Na�ve Web Users, or: Preventing Spoofing and >> Establishing Credentials of Web Sites, by Amir Herzberg and Ahmad Gbara >> PDF at http://eprint.iacr.org/2004/155/ >> HTML via http://AmirHerzberg.com, or directly from >> http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/spoofing.htm ... > at least some brief comments. I'm cross-posting my response to > n.p.m.security because I think this is really a general Mozilla security > issue (i.e., how to protect against phishing attacks) rather than just a > crypto issue. Ok, I'll do the same, but cross posting is not desirable; I suggest the list owner/moderator will decide and let us know which is the appropriate list, posting a message on the other list so that people can follow the discussion if they wish. > > First, thank you all for doing this work. This is a very nice example of Thanks you! ... > However I do have a comment about the particular strategy you've chosen. > It seems that with things like the proposed Logo Certification Authority > (or whatever you called it) that you are in some respects proposing > creation of a parallel structure to today's regular CAs, probably with > many of the same issues. (For example, we'd now have to worry about > including LCA certs in browsers, evaluating LCAs prior to such > inclusion, having users potentially accept new logos and LCA certs > through some sort of security dialog, and so on.) Also, introducing a > brand-new SSL-like protocol further increases the complexity of your > proposal. I don't quite agree. First, our proposed `SSL-light` is completely optional, only designed to solve an efficiency problem we may have if we try to extend SSL protection to many more pages - so, we could always use existing SSL or not protect cryptographically at all some pages (as we do today). Second, I definitely expect some of the existing CAs to begin to certify logos i.e. become LCA (Logo certifying authority). Third, we believe it is preferable that the trust in a particular LCA is a user decision rather than a browser decision. It is very problematic for browser vendors to make a trust decision for their users, and this is particularly obvious for browsers developed in an open process by non-profit organizations like Mozilla (I believe it is non-profit...). So: no need for Mozilla or other browser vendors to include LCAs in the browser. In fact, the `bootstrap` process can be initiated using the existing CA certificates, since when we ask the user to approve a logo (for a LCA or for a site), it is quite reasonable to use the name (from a regular certificate) and not critical to use a logo (from a logo certificate), this being a rare, unusual event. The principle here is: you must get users attention by a strong interrupting clue (different graphics, sound) to cause them to notice a different (i.e. spoofing) environment; it is Ok to use textual information when the user is focused on your (unusual) message. > > Please allow me to play devil's advocate and propose an alternative > approach: Rather than relying on the site itself or on third parties > like LCAs to provide site branding information, why not just build this > branding into the browser, and rely on the browser vendor (e.g., the > Mozilla Foundation) to maintain the collection of logos? For example, > one could imagine a FireFox extension that works roughly as follows: > > 1. Determine the site the user is surfing to. For the non-SSL case take > this directly from the URL; for the SSL case cross-check this against > the information in the server certificate. In the non-SSL case, this is insecure (against many adversaries; granted, it is Ok for the relatively weak `spoofing` adversaries). In the SSL case, this builds on the very problematic existing practice of certificate authorities as used in browsers (see Ian's notes...). > > 2. Map the site URL to a logo for the site. For some reasonable set of > web sites commonly subject to phishing attacks (e.g., Ebay, PayPal, > major banks, etc.) distribute the logos with the browser binaries, as a > sort of pre-loaded cache. This would work, sort of, but creates a nightmare management - and security - problem, with substantial costs involved (liability!) - who will pay Mozilla for this? Or are you proposing that Mozilla (and other browsers) will charge sites for this? The Logo CA solution is much more efficient and simpler in the business sense, by using (fairly basic) crypto.
> For web sites whose logos are not in the > cache, do a background lookup from a site maintained by the browser > vendor, e.g., using a URL like: > > http://logos.mozilla.org/get-logo?site=example.com Of course this is insecure... you event didn't specify the use of SSL (https://...) - and also it involves the same expenses as the previous solution (preloading in the binary). > > (In the latter case we would cache the logo for subsequent use, just as > the browser caches images in general.) This of course is a good idea, that we also do. > > 3. If we find a logo in step 2, display the logo in a dedicated chrome > area, per your suggestion. Otherwise display a warning message similar > to what you suggest. So here we agree - except that your proposal is much more expensive and less secure. > > The above proposal avoids the complexities of your cert-based scheme, Which complexities? Technology (crypto) may be a bit complex to understand, but if deployed well (as I believe we do), it can help a lot to reduce expenses and simplify the use, management and business process. > works in the non-SSL case as well as the SSL case, which results in insecurity. > and arguably has > roughly the same level of overall security as your proposal, I'll say that's definitely arguable... > especially > when you factor in potential security holes due to users blindly > accepting new site logos or LCAs. (This is similar to the problem today > of people blindly accepting new CAs and/or site certs.) I don't think this is the same problem. The current CA mechanisms is beyond users understanding and control in the first place; how many users know that their browser trusts, on their behalf, ABA.ECOM Inc.? Do you? (Actually you may, as ABA here stands for the American Banking Association - but there are many less well-known owners of CAs...) And yet this is the first in the long list of default CA in Mozilla 1.7. So if the browser already trust ABA.ECOM and Saunalahden without knowing them, why shouldn't the user allow others? And indeed, the warning messages are, accordingly, very mild. We believe (and plan) very different interaction in the (very rare) event of specifying the browser can trust a new Logo Certification Authority. In fact, we expect most users to only specify one or two LCA's and other LCAs will need certificate from these (i.e. expect cross certification among cooperating, trustworthy LCAs). > > One more meta-comment: both your proposal and the counter-proposal above > take the approach that users should trust only "securely-branded" sites, > and should be on their guard when a site is not thus branded; basically > the user has to keep looking at the "branding bar" and exercise special > caution when they don't see a logo. This is similar to the traditional > SSL/CA model: look for the lock icon, and beware if you don't see it. > > Another possibility would be to take the opposite approach: let the user > surf in peace, not worrying about checking each and every site, until > and unless there's potentially something to worry about (as determined > by the browser itself). I don't want to speak for him, but this seems to > be the approach Blake Ross is proposing to take for his summer research > project: use machine learning techniques to flag potential phishing > attacks as the user encounters them, analogous to using Bayesian > techniques to flag spam. Also taking a leaf from anti-spam techniques, > the browser might silently check sites against a net-hosted blacklist of > potentially malicious sites, or might use heuristics like "beware of > URLs using IP addresses" (or more sophisticated versions thereof). I think these approaches won't work against any serious phisher/spoofer. In particular the spoofers can fine-tune their sites, using the same filter as the honest users do, to make sure their site is not suspicious. I actually prefer also to use crypto against spam, see in my other paper at my homepage http://AmirHerzberg.com... > > To me at least this seems to be analogous to the various approaches to > reducing credit card fraud: one can attempt to improve the security of > the endpoints to strengthen the guarantee of "authenticity" of > transactions (like what SET attempted to do, for those who remember SET) I definitely do... with some pains, too... But I don't see the parallel. > That's all the comments I have time for now. Again, thanks for doing the > work embodied in this paper, and thanks for providing us the opportunity > to read and comment on it.
Frank, thanks, your comments were very interesting and enlightening.
-- Best regards,
Amir Herzberg Associate Professor, Computer Science Dept., Bar Ilan University http://amirherzberg.com (information and lectures in cryptography & security)
_______________________________________________ Mozilla-security mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-security
