Re: [hybi] Web sockets and existing HTTP stacks

[Roberto Peon <fenix at google.com>]

On Wed, Feb 3, 2010 at 12:23 AM, Maciej Stachowiak <mjs at apple.com> wrote:

On Feb 3, 2010, at 12:07 AM, Julian Reschke wrote:

> Roberto Peon wrote:
>> On Tue, Feb 2, 2010 at 5:25 PM, Maciej Stachowiak <mjs at apple.com <mailto:mjs at apple.com>> wrote:
>>    On Feb 1, 2010, at 11:43 PM, Roberto Peon wrote:
>>>    Simple-- the proxy won't know that the response from the server is
>>>    websocket specific, and may reorder things.
>>>    You should not assume that the termination point (the "host") is a
>>>    server. It could be a reverse proxy. In such cases, the proxy
>>>    needs to treat the response as HTTP until it has been fully read
>>>    and interpreted.
>>>
>>>    This response IS HTTP, so HTTP rules apply. It isn't a some random
>>>    more-restrictive subset of the response rules. It is still HTTP at
>>>    that point. That means that you don't get to add additional
>>>    restrictions on that request. If you do, then you're creating
>>>    headaches for everyone.
>>    OK, just to clarify, are you saying that it's specifically the
>>    constraint on header ordering that is a problem? I'm trying to
>>    figure out which specific requirements are problematic and why. For
>>    example, is the requirement to have some special text in the status
>>    line acceptable?
>> Having some required header ordering is a problem.
>> As for special text in the status line, I'd have to examine the spec again to be sure-- if proxies have the ability to drop the status text (the third part of the first line of the HTTP response, which I'm assuming we're talking about here), then it shouldn't be relied upon.
>> ...
>
> I don't think HTTP specifies this. As Status-Phrase is just informational, I wouldn't surprised when it happened, or when it was rewritten. I'm pretty sure that there are server frameworks where it can't easily be set.

I am pretty sure a lot of popular servers do let modules/extensions/scripts running inside them set it, so I don't think this is a huge practical problem.

>
> Anyway: if another line of defense is added (and that's how I understand Maciej's proposal), is there still a point to insist on the exact Status-Phrase?

According to a security expert I asked, the strongest defense against cross-protocol attacks is in the first few bytes. So I think removing all requirements on the status-phrase would make the protocol less robust against cross-protocol attacks.

How exactly does the random bit of text in the first line help?

You still have to frame the HTTP response, which means that any errors in that framing are going to be causing problems.

In other words, the response will always be as insecure as HTTP. No way around that while still using HTTP. And, as we've already covered, not using HTTP isn't a terribly good option while on port 80 until the upgrade has finished.

-=R

 

Regards,
Maciej