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
