Re: [hybi] workability (or otherwise) of HTTP upgrade

[Bjoern Hoehrmann <[e-mail]>]

* Mark Nottingham wrote:
>WebSockets, of course, does allow an untrusted script to touch the bytes
>on the wire, and that's the problem. Adam has proposed one way of
>dealing with this -- by using a non-routable hostname in the
>request-line, he's hoping to jam any intercepting proxies so that
>they'll fail early (13% of traffic, in his tests). As he points out,
>though, this doesn't offer good security in all circumstances, and I
>suspect there are probably a few other attacks that could leak through
>this approach.

(This isn't entirely accurate. There are three hosts involved here, one
on the CONNECT line, one in the Host header of the handshake, and one in
the attacker-controlled client->server traffic if the attacker can make
client->server Websocket traffic look like HTTP traffic. If the server
does not understand "CONNECT" and the attacker can control what goes
over the wire, non-routable hostnames are no help. And there are some
other problems.)

>I'd suggest that if HYBI doesn't want to use another port (still the
>most obvious and safest solution), you could explore in a number of
>strategies for mitigating these flaws, while still using HTTP Upgrade.
>For example:

I think the working group has heard all the notable techniques, as you
say if ultimately the browser controls all the bytes, then there is no
risk; if the attacker cannot control bytes that are critical for any
reasonable exploit, such as white space characters, then there is no
plausible risk either; if we do not use ports commonly used for HTTP,
and make initial communication look much unlike HTTP, there is also no
plausible problem. If we never actually leave the HTTP realm, such as
by using chunked encoding with two essentially infinite streams, then
there is also no plausible risk; finally there are the "talisman" pro-
posals, where you send something odd and hope for the best (Ian's "76"
draft has a "send malformed HTTP message" approach, Adam et al. have
the "CONNECT" approach, Dave Cridland suggests sending something that
looks like a CONNECT request but really isn't, and there are some ping
pong hello and goodbye proposals I haven't kept track of; there is a
plausible risk to all of those, but it's far fetched and evidence does
not support that there is a grave concern.

What the Working Group does not have is a framework in which this can
be resolved. If you want sendfile() client->server and server->client
to work and want (within reason) perfect security, then there is no
alternative to a dedicated port. If you want to use port 80 and want
perfect security, then you can only use infinite chunks (although it
is not entirely clear how secure that would be) or escaping/encryption.
And so on. At the moment it seems the working group needs an overview
of the many options that have been offered, or at least a straw poll
to put some metrics behind how important it is to protect against the
various attacks, or accomodate performance or compatibility require-
ments. (Ideally we'd have some numbers along the lines of "If you do
this, then the success rate is that" and so on, but there seem to be
few takers to aid in that.)
-- 
Björn Höhrmann · mailto:[e-mail] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: [phone] · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/