Re: [hybi] A WebSocket handshake

[Willy Tarreau <[e-mail]>]

On Wed, Oct 06, 2010 at 07:24:18AM -0700, Adam Barth wrote:
> On Wed, Oct 6, 2010 at 1:20 AM, Willy Tarreau <[e-mail]> wrote:
> > On Tue, Oct 05, 2010 at 11:57:40PM -0700, Adam Barth wrote:
> >> On Tue, Oct 5, 2010 at 10:34 PM, Willy Tarreau <[e-mail]> wrote:
> >> > Adam, could you please recheck the importance for this handshake to
> >> > have the invalid hostname ? It really is the only blocking issue I
> >> > can think of. If it is absolutely needed, maybe we could use something
> >> > like "<valid-hostname>.websocket.invalid" instead so that at least the
> >> > server-side components can route the request to the proper location ?
> >>
> >> Using an invalid host name is important because we don't want the
> >> attacker to be able to choose any of the bytes in the initial message.
> >
> > OK I understand your point, but this is no different from what the
> > attacker can already do with plain HTTP.
> 
> Please read the document.  If that were true, we could just use the
> initial POST strawman.

Adam, please, I took 30 minutes this morning to read it carefully. All
I saw against the POST was the risk of using it to post a second request
after the first one, and I explained that that's precisely why the
"Connection: close" statement must be used.



> 
> >> Of course, virtual hosting is important.  We'll probably want to
> >> include the real Host header in the encrypted "additional information"
> >> sent with the initial handshake message so that the WebSocket server
> >> can dispatch the connection to the appropriate virtual host.
> >
> > Except that right now the virtual hosting it handled at the boundary
> > and the websocket will be handled at the internals. That said, the
> > host part of a URL must at least respect the limited charset of the
> > DNS system. We don't have the %-encoding of the plain URLs.
> 
> Please read the document.  That's true and intentional.  We want the
> server to understand that it's talking WebSockets before it dispatches
> the request to a particular virtual host.  That prevents a single
> virtual host from opting into a WebSocket connection on behalf of the
> entire host.  If the real host doesn't understand what's going on, it
> could get confused and let the attacker do nasty things.

I don't agree, at worst it would forward the request as-is, exactly
as any intermediary will do, and it will either reach a real WS server
or a normal HTTP server. And since your proposal protects against
cross-protocol attacks, the attacker won't be able to do nasty things.

Willy