Re: [hybi] Extensibility mechanisms?

[Willy Tarreau <[e-mail]>]

On Wed, Jul 21, 2010 at 11:11:58PM -0700, Adam Barth wrote:
> Thanks.  Your email is much more lucid.

Thanks ;-)

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

OK so that was my understanding. I've been using that for some time to
telnet home through proxies from closed enterprise networks ;-)

(...)
> > 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.

Yes indeed. I mean "accidentely" from the user's point of view, in
that it is not the behaviour he would have expected.

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

Indeed, and as such the -76 one is, because the first bytes can be used
to send a second HTTP request to a server through a reverse-proxy while
at this point this should only be WebSocket and not HTTP.

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

That's why I'm trying to reduce the amount of blind emissions during the
handshake.

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

My concern is also that we're becoming too much different from this
stylized subset, by introducing special features that nobody cares
to qualify possible negative impacts nor means of exploitation. I'd
rather stick to something well mastered which shares the same class
of possible vulnerabilities and attacks as the other ones targetting
the same agents, so that when we spot one and fix it, the issue is
fixed for all uses.

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

Yes, indeed ! Remember spammers using FTP with a RETR command to send
a previously uploaded mail from port 20 to another host port 25 ?

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

I agree, but at least we can enumerate the strict requirements for
the client to accept to send data to the server, which reduce the
exposure. Right now with a properly designed HTTP upgrade handshake,
you require a very precise set of criteria in the response that only
a server understanding the protocol could send because a non-WS
server would not have invented them. And one advantage of HTTP upgrade
is that the response MUST start with "HTTP/1.1 101". Anything else
won't match, which considerably limits the ability to inject the
response into the server's mouth. For instance, my SMTP server sends
me a "220 mail.home.local" first, which does not match HTTP/1.1. Some
other protocols will for instance send "Error: GET /xxx unknown command".
In fact, the parts we expect from the response cannot be guessed from
the command by non-WS aware servers. This is what makes it quite robust
already.

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

Agreed. Otherwise it's a lost game. But they can serve as examples to
try to defeat a design however.

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

Yes, but as Scott said it, it was a proposal to work on something with
a constructive approach. Not everyone is perverted enough to think how
a protocol can be abused, and that's why we need a variety of people to
work on the same protocol.

Regards,
Willy