Re: [hybi] #1: HTTP Compliance

[Willy Tarreau <[e-mail]>]

On Sun, Aug 15, 2010 at 09:06:56AM -0400, Shelby Moore wrote:
> I felt compelled to add my (what I feel is a more convincing) point to the
> mix, because the security argument against the extra 8 bytes appears to be
> weaker, because HTTP request smuggling already exists.
> 
> http://www.owasp.org/index.php/HTTP_Request_Smuggling

It only exists when servers are not cautious enough with dangerous
inputs (eg: conflicting content-lengths). And it is a problem when
two implementations decide differently how to interprete the request
because the spec makes it ambiguous or does not cover the case. That's
been addressed in http-bis, and now that there is some guidance so that
everyone tries to do the same thing, we should not try to bring the
issue back with WebSocket !

> And since I understand
> that variable interpretationsinterpretations/implementations is critical
> to HTTP robustness, then I conclude that "security" at the *transparent*
> proxy is an oxymoron.

I don't agree. First we're not talking about "transparent proxies" but
reverse-proxies, that act as the server when seen by the client. There
are many of them around you without you ever noticing. That makes them
"transparent". They're generally quite robust, and most often they bring
the security themselves because their HTTP stack is well polished and
strict enough to protect the servers from issues that could result from
poor implementation in the application.

> A *transparent* proxy should never be used for
> mission critical functions,

It's quite the opposite. The more mission critical, the more of them you
find because they bring protocol validation, security, filtering, load
balancing, surge protection, content switching, etc... basically things
you don't need to show your photos to your family, but that are needed
everywhere applications are setup to serve tens to hundreds of thousands
of concurrent clients.

In fact, the unreliable components are mainly those which work on string
matching in packets. Those do not rely on proxies and don't have a very
robust state machine. They can easily be fooled in many ways with hand
crafted requests. Some of them will already not be able to process the
protocol upgrade and will likely hang or reset the connection.

> Thus I don't think the security argument against proposal 76 is as
> convincing.  Feel free to correct me, as I am only using deductive logic
> of what I have read today, and am not speaking as an expert in the field.

It's not the security argument against draft 76. It's that draft 76 is
not HTTP compliant and breaks with HTTP-compliant reverse proxies. The
only dirty hack that could be imagined to make those reverse-proxies
support it would not be acceptable in those reverse proxies because it's
incompatible with HTTP and it would break their security.

> > What is important is that if we make the websocket handshake pass through
> > HTTP components, it must comply with the protocol. HTTP is clear on that:
> > the protocol has switched *only once* the 101 has been seen. So a reverse
> > proxy must not pass those 8 bytes before seeing the 101.
>
> Otherwise we defacto change HTTP for every HTTP Upgrade protocal
> extension.  We know we are changing HTTP, because the implementing server
> or proxy has to implement a new code path for our Upgrade protocal
> extension.

No, as explained above, we must not do that because it opens a new can
of holes. HTTP requires too much interoperability, it must not to be
cross-dressed for every protocol pretending to rely on it.

> >> It would be an exponentially increasing cost problem of interoperability
> >> if every Upgrade protocol requires a new code path in the proxies.
> >
> > And it would not make sense at all since this would not be HTTP anymore.
> 
> Agreed.  Ditto I wrote above.

I think we agree, it's just that you seem to be dismissing the security
impacts of changing the way the HTTP Upgrade mechanism works, and I'd like
to ensure that the issues are clear.

Regards,
Willy