We have created a Mozilla extension that creates a secure, Trusted Logo and Credentials Area, which displays logos and other credentials of the site. We believe this helps protect web users, even naive users, against spoofing and phishing attacks. We are still playing with the code but hope to begin providing it to others soon; in the meanwhile, if you are interested, we'll love to hear your comments. 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
Ian Grigg forwarded an earlier message of yours to n.p.m.crypto and n.p.m.security several days ago, and I took the opportunity to read your paper then; unfortunately I haven't yet had time to post detailed comments. I did find the paper very interesting, and so I wanted to post 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.
First, thank you all for doing this work. This is a very nice example of using FireFox as a base for potential innovations, and illustrates (at least to some degree) what people have been advocating re "branding" of web sites to give users a better indication of the site's security measures. (IIRC Ian Grigg had suggested that the branding be associated with CAs, e.g., "Verified by VeriSign" or some such, whereas you are proposing branding the site itself, possibly including some third party logos as well, like Visa.)
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.
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.
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. 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
(In the latter case we would cache the logo for subsequent use, just as the browser caches images in general.)
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.
The above proposal avoids the complexities of your cert-based scheme, works in the non-SSL case as well as the SSL case, and arguably has roughly the same level of overall security as your proposal, 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.)
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).
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) or one can improve detection of fraudulent transactions on the back end, while leaving the existing endpoint mechanisms in place. The goal of this alternative approach would not be to try to provide a ironclad guarantee against phishing attacks for any particular user, rather it would be to attempt to reduce the overall incidence of phishing attacks as measured across the entire base of Mozilla users, and to ensure that new phishing attacks are detected and responded to as fast as possible.
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
-- Frank Hecker [EMAIL PROTECTED] _______________________________________________ Mozilla-security mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-security
