On Mon, Sep 19, 2011 at 10:53 AM, Andy Steingruebl <[email protected]> wrote: > On Sun, Sep 18, 2011 at 2:01 PM, James A. Donald <[email protected]> wrote: >> >> SSL fails at low security stuff in that it allows phishing, > > <snark> > You know what else fails at fighting phishing? > > - The locks on my car door > - The fence surrounding my house > - The full disk encryption on my laptop > > </snark>
This is silly. Off-line phishing happens too -- phishing is really just a con-job. But in the on-line world we have made mistakes that make these con-jobs much too easy. We can't prevent all con-jobs, but we *can* prevent *some* important attack vectors. > SSL wasn't designed to stop phishing, if sites don't deploy it with > mutual-auth it can't possibly do so. Saying it is a failure because > it doesn't stop that ignores the problem it is designed to solve, or > at least some it could credibly claim to solve. There are ways to avoid some phishing attacks (namely credentials and cookie theft) without mutual auth. See below. > SSH doesn't solve phishing either. Is it a total failure also? I > don't think so. > > SSL is used for a lot more than HTTPS. Any proposal to "fix" it > *must* take that into account. Yes, of course. Non-HTTP TLS apps often have an option to use SASL, in which case SASL w/ channel binding is generally a sufficient solution. Phishing is about: - credentials that can be stolen (usernames and passwords); - weak session binding credentials that can be stolen (cookies!); - theft of other personal information by server impersonation (so even if the credentials can't be stolen, if there's any way to convince the user that the site they're on is legit then the attacker might convince the user to give up sensitive information, such as recovery credentials); - out-of-band phishing (via e-mail spam). The first one can't be addressed by TLS as it is without using user certificates (which are generally not portable without SACRED-like solutions, which is the reason for Mozilla's browserid concept). The second requires various improvements to the web code stack. One of the best recent ideas for this is Dirk Balfanz' "channel bound cookies" with ephemeral, per-session@server user certificates, though it's hardly the only proposed solution (see also the OAuth MAC idea). For more on Dirk's proposal search the TLS WG list for "TLS-OBC". The third type of phishing simply can't be protected against in any system where authentication of the user and the service to each other is completely decoupled (as it is in today's web). This attack is not very common now, but if we fixed the other two attack vectors then it'd become more common. To fix this will require authentication mechanisms that provided fairly tightly coupled mutual authentication such that mutual authentication cannot succeed with parties that the user does not have established relationships with (and the UI has to make the mutual authentication state utterly clear to the user too). As for out-of-band phishing, well, that's the hardest to protect against for the simple reason that some phishing e-mail is always bound to get through and prey on the elderly and naive. I'm not sure what we can really do about this -- con-jobs work because people are too trusting and naive, and this is ultimately not something we can handle entirely via technology. But the first three vectors listed above *can* be addressed with technology (so I assert); we should. Incidentally, much has been written about these topics. See http://tools.ietf.org/html/draft-hartman-webauth-phishing-09 for example. Nico -- _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
