[cryptography] SSL is not "broken by design"

Nico Williams nico at cryptonector.com
Mon Sep 19 15:16:18 EDT 2011

On Mon, Sep 19, 2011 at 10:53 AM, Andy Steingruebl <andy at steingruebl.com> wrote:
> On Sun, Sep 18, 2011 at 2:01 PM, James A. Donald <jamesd at echeque.com> 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

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 at 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


More information about the cryptography mailing list