Ian Hickson wrote:
> On Fri, 17 Jul 2009, Amos Jeffries wrote:
>> Um, okay. Have a read of this alternate Spec and see if you can stil
>> find the security hole you are woried about:
>
> I don't understand in what way it substantially differs from what the spec
> says today. There are minor differences in wording, but other than that,
> and other than the requirement that two TCP connections be established to
> port 80 when using port 80 instead of just one, it seems equivalent. Could
> you elaborate on what the important difference you had in mind is?
>
Two connections? no. Only one. Two METHODS of possible connection.
1) CONNECT and HTTP Upgrade are optional, and independent. One may be
used or the other. They may be both tried in any order.
2) Specific mention is made that these are for failover use ONLY after
port 81 and 815 have both already been tried and cannot be used.
3) The specific order of bytes is not mentioned _anywhere_ in the new text.
4) The order of headers _received_ is not mentioned past the 101 / 4xx
/5xx line. HTTP varies order in-transit.
5) Specific mention is made to ignore non-understood headers added
randomly by intermediaries.
6) Specific mention is made to drop random extra body data sent with
headers or request and reply and how to handle it. Fixing that
data-feeding issue you worry about.
7) Most importantly. The WebSocket handshake is not involved in this
section. It happens after the Upgrade shift / CONNECT tunnel / port-81
TC link has succeeded. Not mid-way though the HTTP Upgrade processes.
Between them these differences convert your section 3.1 from a detailed
byte-level handshake, very flaky in any non-direct port-80 link, to an
HTTP-level handshake which can be relayed or handled properly by
existing MITM and Surrogates.
HTTP clients and servers need very little change to operate with this as
well and can leverage their broad base of HTTP code to process the
headers properly and safely to the required end.
As Henrik pointed out, there are HTTP things I've overlooked in the
quick re-write. But their addition is minor editing touchups.
HTTP Keep-Alive stuff may also be needed to encourage the WebSocket link
to stay up long-term use for the handshake and data frames.
Amos
-- Please be using Current Stable Squid 2.7.STABLE6 or 3.0.STABLE16 Current Beta Squid 3.1.0.9Received on Fri Jul 17 2009 - 12:20:22 MDT
This archive was generated by hypermail 2.2.0 : Thu Jul 30 2009 - 12:00:09 MDT