Re: [hybi] Handshake was: The WebSocket protocol issues.

[Greg Wilkins <[e-mail]>]

On 11 October 2010 20:34, Maciej Stachowiak <[e-mail]> wrote:

> On Oct 11, 2010, at 2:24 AM, James Graham wrote:
> > I'm not sure I follow this objection. Unless I am misunderstanding Adam's
> proposal, all the information needed to access the Host header is in the
> initial client request; the only additional effort needed is to use the
> client-sent key to decrypt the headers. According to this understanding, one
> doesn't have to maintain state across requests just to determine if one will
> handle the request and, if so, with which back end server.
>
> I agree with this understanding. With Adam's elaborations (not fully
> detailed in the original proposal), all the routing information is available
> in the initial client handshake request.
>
> > Is it just the decryption that you believe represents an unmanagable
> burden?
>
> In the unlikely case that the encryption is an unreasonable burden, I think
> it's possible to use a trivial form of encryption (XOR with one-time pad)
> instead of AES-128-CTR. But I think it's probably both safer and typically
> easier to use a well-known cipher.
>


I think there are things that we can do to restrict "attacker" content in
the handshake short of encryption.

Firstly I don't think we can encrypt the host header, at least not for an
Upgrade handshake. It is part of RFC2616 that a host header should be
included and we have agreed that we must be HTTP compliant before a 101.
While the host value it is "attacker" supplied content, it has been at least
been partially validated by performing a DNS lookup, which I believe will
restrict the content to A-Za-z and a restricted set of punctuation. I think
this significantly limits the usefulness of the host name to an attacker.

Similarly, the subprotocol string is not necessarily free content for an
attacker.  We can impose a very strict token definition for subprotocol
names that will also substantially deny that as a field that can inject
anything useful to an attacker.

That leaves the URI in the handshake.   The requirement to be HTTP compliant
does not mean that we need to allow all legal URIs.  We could also restrict
the URLs to deny usage of many characters that would be needed to make a
meaningful attack.


regards