Re: Hello from Mozilla

Ian Hickson wrote:
> On Thu, 16 Jul 2009, Ian Hickson wrote:
>> On Thu, 16 Jul 2009, Mark Nottingham wrote:
>>> If you don't already, it would be good to explain the risks of using
>>> it over port 80 in the document, and perhaps do something stronger to
>>> discourage such use. Likewise, a note about the dual protocol port not
>>> being a preferred setup would be helpful, if only in making it go down
>>> a bit smoother in the IETF.
>> I've tried to do this. Please let me know if you think the wording
>> should be stronger; I wasn't exactly sure how much hand-holding was
>> appropriate. (The text is in the new "Establishing a connection"
>> section.)
>
> Actually I'm getting an error message from the upload tool (something
> about the tool being disabled for a few days or something?), so in the
> meantime you can see the text here:
>
> http://www.whatwg.org/specs/web-apps/current-work/.ietf-websocket-protocol/draft-hixie-thewebsocketprotocol-23
>

Um, okay. Have a read of this alternate Spec and see if you can stil
find the security hole you are woried about:

Small alteration to 3.1.3:

"

3.1.3 If the user agent is configured to use a proxy
        and the dedicated socket connection specified in 3.1.1
        and 3.1.2 has failed. The WebSocket client MAY then use the
        proxy to initiate tunneled WebSocket connections as specified
        by 3.1.4 and 3.1.5

3.1.4 HTTP CONNECT tunnel

        If the WebSocket client is unable to open a dedicated port as
        specified in 3.1.1 and 3.1.2. It may attempt to open a connection
        via HTTP CONNECT mechanism instead.

3.1.4.1
         Connect to the proxy and ask it to open a TCP/IP connection to
         the host given by /host/ and the port given by /port/.

            EXAMPLE: For example, if the user agent uses an HTTP proxy
            for all traffic, then if it was to try to connect to port 80
            on server example.com, it might send the following lines to
            the proxy server:

               CONNECT example.com:81 HTTP/1.1
               Host: example.com

            If there was a password, the connection might look like:

               CONNECT example.com:80 HTTP/1.1
               Host: example.com
               Proxy-authorization: Basic ZWRuYW1vZGU6bm9jYXBlcyE=

         Otherwise, if the user agent is not configured to use a proxy,
         then open a TCP/IP connection to the host given by /host/ and
         the port given by /port/.

         NOTE: Implementations that do not expose explicit UI for
         selecting a proxy for Web Socket connections separate from other
         proxies are encouraged to use a SOCKS proxy for Web Socket
         connections, if available, or failing that, to prefer an HTTPS
         proxy over an HTTP proxy.

3.1.4.2
         A successful CONNECT from 3.1.4.1 is a working WebSocket and the
         bytes transfered through it follow the protocol format specified
         from section 3.2.

3.1.5 HTTP Upgrade tunnelling

        If the WebSocket client is unable to open a dedicated port as
        specified in 3.1.1 and 3.1.2 and the /port/ specified is 80.
        It may attempt to open a connection via HTTP Upgrade mechanism
        instead.

3.1.5.1
        Connect to the server given by /host/ on port 80 and ask it to
        upgrade from HTTP to WebSockets.

        The client must send only the following lines:

            GET /thepath/ HTTP/1.1
            Host: /host/
            Upgrade: WebSockets
            Connection: Upgrade

        terminated by two CRLF as per HTTP specification.

3.1.5.2
        A server receiving the request SHOULD ignore any other headers
        received with the request.

        If any data following the headers is received then fail the
        WebSocket connection. The server MUST discard any body data
        received with an Upgrade request. It MAY respond with a 4xx or
        5xx HTTP error code from the HTTP specification.

3.1.5.4
        A server receiving a valid HTTP Upgrade request to WebSockets
        and which does not accept that WebSockets upgrade MUST send back
        a 4xx or 5xx HTTP response as per section 3.1.5.2.

        A server receiving a valid HTTP Upgrade request to WebSockets
        and which is accepts that WebSockets upgrade MUST send back a 101
        HTTP response.

        The server SHOULD send only the following lines:

            HTTP/1.1 101 Web Socket Protocol Handshake
            Upgrade: WebSocket
            Connection: Upgrade

        terminated by two CRLF as per HTTP specification.

3.1.5.5
        A WebSocket client receiving any response status other than that
        specified in section 3.1.5.4 from the server MUST fail the
        WebSocket connection and abort the HTTP link.

3.1.5.6
        A WebSocket client on receiving HTTP 101 response SHOULD discard
        any additional HTTP headers received from the server following
        the status line.

        If any body data is received the client MUST fail the WebSocket
        connection and abort the HTTP connection.

3.1.5.7
        If no body data was received from the server the client should
        switch protocols and send initial WebSocket authentication
        handshake via the protocol format specified in section 3.2
"

Note that all of the above is semantically equivalent to a TCP link
open. The WebSocket authentication handshake is separate and happens
after the link is ready for it.

The initial handshake bits that you want to do to ensure the connection
really is a valid WebSocket link should be in the next section with the
data framing possibly shifted down to other numbers, etc, etc.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE6 or 3.0.STABLE16
   Current Beta Squid 3.1.0.9