Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocketprotocol-01.txt

[Hector Santos <[e-mail]>]

Willy Tarreau wrote:

> Well, this is precisely a consequence of the problem I talked about. POST
> has never been part of the SMTP protocol, and it's because the SMTP
> protocol is prone to such attacks that these checks have been added in
> implementations. Maybe some updates to the protocol have since been emitted
> to suggest this, but I always had the feeling that these protections were
> just good implementers' choices in face of a real threat.

Since this  behavior is no different that a client batching its 
commands with disregard for server responses (not intentional 
pipelining), this has long been mitigated in good MTAs.

The same will be true with websockets - the server always need to be 
control or it will be open to all sorts of issues.

The main thing here is that we are talking about hosting servers and 
whatever protocol is put together, we need to make sure that we don't 
make it hard to resolve the known formulas for threat entry points.

For example, one way to authenticate the WS client is to use IP such 
as it done with POP3-B4-SMTP methods where a POP3 host records an IP 
for another SMTP host to open a time window for SMTP IP-based allow 
relay.

For Websockets, it may work pretty well based on the fact most 
applications will mostly start with a browser client and ws client 
from the same IP. The same idea can be applied here:

    C1: HTTP request (possibly start HTTP or Cookie AUTH login)
    S2: HTTP page is served. IP recorded (optional TTL)
    C3: WS Client begin WS open and handshake
    S4: WS Server authenticates recorded IP, continues with handshake

S2 MAY opens a limited time window (TTL) for the 2nd session to 
appear.   It helps resolve the unsolicited WS client request issue for 
servers that expect WS clients to begin with an HTTP server prepared 
client.

Lets keep in mind something here folks - the mindset has changed to 
even allowing a TCP socket connection to be part of the browser (and 
many of the HTML5 aspect with LOCAL I/O).

Its taken a long time to even view this as "acceptable" but that 
should not be a taken lightly or become a reason to relax with all the 
security concerns.  Its too easy to fall trap in this open generation 
of meshed connections.

If we fail with that, WEBSOCKETS will be turned off which is something 
a QA conscious browser will probably soon need to add to its user 
setup interface in the same way Javacript can be still be turned off. 
  If not done right, expect the NoWebSocket plug-ins to appear.


-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com