Re: [hybi] #1: HTTP Compliance

["Shelby Moore" <[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.

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

For as long as servers are free to have variable
interpretations/implementations of HTTP (within the broad constrainsts of
the spec), then HTTP request smuggling will exist.  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.  A *transparent* proxy should never be used for
mission critical functions, instead only to achieve optional benefits such
as increases in performance due to caching.  An opaque proxy (e.g. the
Apache server handling my server code or the upstream proxy I configure
into my browser) is theoretically deterministic and thus can be configured
to be reliable with respect to the end implementation.

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.

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

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

[snip]