Re: [hybi] Extensibility mechanisms?

[Adam Barth <[e-mail]>]

Thanks.  Your email is much more lucid.

On Wed, Jul 21, 2010 at 10:54 PM, Willy Tarreau <[e-mail]> wrote:
> On Wed, Jul 21, 2010 at 09:40:00PM -0700, Adam Barth wrote:
>> The more I read on this list, the more I think that folks here don't
>> understand the requirements on the protocol, especially the security
>> requirements.  That's understandable if you haven't worked extensively
>> with the browser security model.  Fortunately, Ian is an expert on
>> these topics and has more time to reply to this list than I do.
>
> Unfortunately, if neither of you two can take some time to give concrete
> examples of what you're trying to protect against, you will constantly
> see proposals that don't fit your requirements.

A cross-protocol vulnerability is a very general class of
vulnerability in which the client believes it's speaking one protocol
and the server believes it's speaking another protocol.  The ensuing
confusion leads to a miscommunication that an attacker can exploit to
do something undesirable.

> My understanding of cross-protocol attacks (please correct me if I'm
> wrong) is the fact that a browser can be tricked into sending specially
> crafted data to an IP:port which it believes is one protocol while it's
> another one,

It's not a matter of being tricked.  It's a deliberate ability the
browser grants to guest code (the merits of which aren't really up for
discussion in this forum).

> the typical example being a form designed to send a POST
> to an SMTP server, which will ignore all the HTTP part it does not
> understand and will happily apply the body's data as SMTP commands.

Yes.  HTTP => SMTP has a particularly bad cross-protocol
vulnerability.  The "solution" to the vulnerability is that browsers
forbid HTTP connections to port 25, which is deeply unsatisfying but
effective in practice.

> It's easy to put web sites on the net that build such forms so that browsers
> which get there are accidentely used to perform that attack.

Again, there's no accident involved.  It's entirely reasonable for
users to visit hostile web sites.  It's also entirely reasonable for
those hostile web sites to use these APIs.  It's the browsers job to
make sure the user isn't sad because of this arrangement.

> If this is indeed the issue you're talking about, then I don't see why
> the HTTP-based handshake could be a problem there.

Well, it certainly *could* be a problem if improperly designed.  As a
community, we don't have a good science of cross-protocol
vulnerabilities.  We certainly can't understand all possible
interactions between all protocols.  We have to reason about these
attacks indirectly, for example by reduction.  It's possible to reason
about the security of an HTTP-based handshake by reduction to already
existing abilities the attacker has, provided the protocol is designed
with that sort of reasoning in mind.  Blithely hoping "HTTP likeness"
will avoid all issues isn't sufficient.

> It's not more than any other common HTTP request,

Keep in mind that attacker can only generate a very stylized subset of
HTTP requests in browsers today.  Stepping outside that subset
requires careful consideration.

> it's even better in that no data should
> flow until the server has correctly replied indicating proper support
> for the protocol.

That's also a useful property.  However, we need to be careful when
thinking about what "proper" means in this context.  In many
protocols, the attacker can put words in the server's mouth, so to
speak.  For example, in DNS, the attacker can request TXT records from
domains he control, or in NNTP, the attacker can request posts he
authored.  That's why the server's proof of understanding the client's
hello message is convoluted in current protocol.

> Basically we should get this :
>
>  - the client sends an HTTP handshake (headers only)
>  - the server responds with its HTTP handshake
>  - the client checks the response and only then forwards
>    data.
>
> This standard scheme protects against cross-protocol attacks (as I
> understand them) as the client does not send anything unless the
> server proves its ability to understand the client protocol. Also,
> the request and response are different HTTP messages, so a simple
> echo server can't return the valid handshake by accident.

We're worried about more complex servers than just an echo server.
That's why the proof of understanding is more complex.  Certainly an
identical client -> server and server -> client message would be a
poor design.  However, just because they're not identical doesn't mean
we're out of the woods.

> So with this, I'm sorry I don't see what class of cross-protocol
> attacks remain and which ones we should actively protect against,
> so if you have good examples, it would be nice if you could take
> some time to share them.

Designing a secure protocol doesn't mean enumerating all attacks and
making sure we avoid them all.  We're not smart enough to envision all
attacks.  Instead, we need to convince ourselves that no attacks are
possible, which is much the opposite problem.  I don't have a pile of
attacks in my back pocket.  Instead, I can tell you that the protocol
presented earlier in this thread is unlikely to be free of
cross-protocol vulnerabilities because it lacks a number of defenses
and mitigations, some of which you've listed in your message.

Adam