Re: [hybi] #1: HTTP Compliance

[Willy Tarreau <[e-mail]>]

On Sun, Aug 15, 2010 at 06:53:11AM -0400, Shelby Moore wrote:
> > On Sun, Aug 15, 2010 at 05:10:09AM -0400, Shelby Moore wrote:
> >> An HTTP proxy that is compatible with draft/proposal #76 (the
> >> contentious
> >> one that passes 8 extra characters after the HTTP header without a
> >> Content-Length header), would need a specific code path for the
> >> WebSocket
> >> upgrade request in order to pass 8, and only 8, extra characters
> >> (concensus is that passing an arbitrary content length would be a
> >> security
> >> hole).
> >>
> >> Isn't it the antithesis of the 80/20 rule and interoperability to
> >> require
> >> every HTTP proxy in the world to have specific code path for every
> >> possible future HTTP Upgrade protocol that comes along?
> >
> > it's even worse than that, it means that such a reverse-proxy, when shared
> > between HTTP and Websocket, will have to accept to blindly forward those 8
> > bytes everytime someones *pretends* to talk websocket, without the
> > server's
> > consent.
> 
> I had read that point in past discussion.  I would be tempted to assume 8
> characters is relatively harmless security hole (as compared to passing an
> arbitrarily unexpected content length, which is what would be required to
> have one code path for all proxies for all possible Upgrade extensions
> that expect such special treatment), but I will grant you that even 1
> unexpected bit is a potential security hole.

Yes, even one byte is enough because it can be used to change the second
request's method. For instance, let's say you have a reverse-proxy somewhere
which analyses POST requests to validate the body, but which ignores all
other methods. You could send it a first request with Upgrade: Websocket,
with /key3/ being "\r\n\r\n\r\nPO", then a second request with a method
called "ST" which it would ignore. The end server would then ignore the
Upgrade request because it doesn't speak WebSocket, then would skip the
empty lines and get a perfectly valid POST request which has not been
checked by the reverse-proxy. This issue causes an infinite amount of
similar class of problems. This is closely related to HTTP request
smuggling.

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.

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

> Let me confess that I have only been studying the entire issue of Comet,
> BOSH, WebSocket, and this mailing list, for a several hours.  I came to
> this from Wikipedia, because I need to choose an architecture strategy for
> a social network I am developing.  So take my comments as one perspective
> of an outsider (but an outsider with considerable experience in web
> development and successful commercial software both pre-internet and
> post).  I am not a networking expert, but I do think a lot about
> interoperability in the real world and also in terms of programming
> language design.

You're welcome, anyone with experience or strong in-field requirements can
share some knowledge and help improve the design.

Regards,
Willy